Bound or not bound to Git, this is the question.

[thomasN]

Hi there,

We are in the process of migrating from Visual Source Safe (VSS) to Git. We currently have about 20 main individual Flare projects (10 in English and the 10 same projects in French). We are using Flare 11 32 bits but are willing to migrate to Flare 2019 64 bits. We have a lot of files shared between projects using VSS links and are thinking of using Global Project Linking to keep only one occurence of each of these shared files.

We are considering the 2 following architectures:
1 big Git repository with all our projects, with Flare not bound to Git.
Or
1 Git repository for each project, with Flare bound to Git.

What option would you choose and why ?
If you do not have Flare bound to Git, what Git Shell do you recommend to perform Git commands ?
What is your experience (pros and cons) ?

Thank you for your time

[doloremipsum]

I've had a really hard time with Flare's Git integration, to the extent that I think we shouldn't have bothered in the first place. Especially issues with authentication - it doesn't like the two-factor authentication that our Git provider requires. We basically just use Git Extensions now.

However, I think it's useful to have one repository per project anyway, because it will be easier to keep everyone's work separate.

As for Global project linking: there are conversations about this elsewhere in the forums, but I would advise making sure that there is only one copy of each Global file in the Git repositories. Otherwise there are two ways to get the file instead of one, and you might overwrite your newer version with someone else's older version from a child project! I keep my global files in well-defined folders and have added those folders to the gitignore so that they won't appear in the child repositories (usually - sometimes they pop up if you rename/move them).

[ChoccieMuffin]

We use SVN rather than GIT, but we don't use Flare's interface, and do all our SVN stuff outside of Flare. It works for us.

For GPL, we have a single Globals project and each child project imports from that one project. When saving things in SVN we specifically don't include anything that is imported from any other project.

This is how our Globals project and our child projects are stored in SVN:

Globals project
\Content
...\Resources (Contains all the common stuff, even bits that would normally be at the top level of the Content Explorer)
...\...\Pagelayouts\*.flpgl
...\...\Stylesheets\*.css
...\...\Snippets\*.flsnp
...\...\Images\*.* (Only common images are stored here. Child projects put their images one level up.)
...\...\Common content (Contains all the common topics like copyright, and topics for front page, index topic with a proxy in it, that kind of thing)
etc

\Project
...\Conditional Text\globals.flcts
...\TOCs\ common TOCs like Front cover, Index, etc
...\VariableSets\Global_data.flvar
...\Targets (just a review target, as we don't generate "proper" output from the Globals project)
...\TOCs (just a review TOC to use with the review target)


Child project
\Content
...\Resources THIS FOLDER DOESN'T EXIST, IT'S CREATED WHEN THE GLOBALS.FLIMPFL IS RUN
...\proj_name\*.htm (particularly if the child project is going to be imported into other projects as well)
...\proj_name_images\*.png
...\proj_name_snippets\*.flsnp

\Project
...\Advanced\ *.flali and *.h
...\ConditionTagSets\proj_name.flcts
...\Imports\globals.flimpfl, and any other import files for other projects
...\Targets\*.fltar
...\TOCs\*.fltoc often contain broken links to TOCs that are imported from Globals
...\VariableSets\Local_data.flcts (This has the same name in all child projects, so we can use a variable Local_data.Doc_Name in the front page topic in the Globals project)

[IFU]

Thanks ChoccieMuffin for the detailed explanation. It's very helpful.
Just curious: is there a particular reason you have chosen to use SVN outside of Flare?

[thomasN]

Thanks @ChoccieMuffin for this detailed reply.

I have an extra question for you regarding the GPL import files:
Are your import files excluded from SVN so that each user manages his own import files ?
Or do you handle these files through SVN so that users all have the same import files. I would rather have import files managed through Git (or SVN) so that we all work with the same files and easily benefit from modifications, but I am not sure of the consequences (as imports are handled individually and locally by each user...)

Could we have your insights on this matter ?

[ChoccieMuffin]

Thanks ChoccieMuffin for the detailed explanation. It's very helpful.
Just curious: is there a particular reason you have chosen to use SVN outside of Flare?

A couple of reasons.

1. When my predecessor set things up a good few years ago, the Flare integration of SVN was even more dodgy than it is now, and as we understand the system and it works well for us, I haven't felt the need to change.
2. In our setup the build machine checks stuff out and builds it, so we specifically want to keep "clean" versions of import files because it's easier to keep and eye on things that do need to change.
3. Using this setup we don't keep copies of stuff imported from other projects in our child projects, so it saves disk space (something that has been a bit of an issue here in the past).
4. In monitoring these forums people are still reporting some hiccups with source control integration, so I'd rather not give myself additional headaches if I don't absolutely have to.