Using Global Projects and Source Control

[oceanclub]

The source control method we use is Git and I'm currently migrating a single project to be multiple projects including a global project. This works fine and the expected files are imported from the Global project to my child project.

One thing that I'm unsure about - when I do a Git commit, the "Pending Changes" will include files from my Global project. Do I either (a) summit these in with my child project and later on they are overwritten when required by the same files from the Global project or (b) is there some configuration I can perform to set those files to be ignored when version control submits are performed?


P.

[Dave Lee]

I'd say (a)

If you didn't include these files in source control, then different people could have different local versions of these files.

[oceanclub]

I'd say (a)

If you didn't include these files in source control, then different people could have different local versions of these files.

But the source of the file is from the global project. If I check in the version of the file that is imported into the Local project, that means there's now two copies of the file held in source control which strikes me as also a bad thing to do?

P.

[Dave Lee]

When you build the output from your child project, it's only going to use the files that are in the child project (that have been imported) - it doesn't take files directly from the original global project. So you need to include these files from your child project in source control - they're required to build your output.

If you don't include these files in the child project in source control, then you'll get inconsistent or broken builds because (a) different people can have different local versions of these files, and (b) if you get the project from source control from scratch, the imported files will be completely missing until you run an import.

You'll also have no control over which version of the imported files are used in the child project; e.g. what if you ever want to keep a project on an older version of the imported files?

[oceanclub]

When you build the output from your child project, it's only going to use the files that are in the child project (that have been imported) - it doesn't take files directly from the original global project.

Yup agreed here.

So you need to include these files from your child project in source control - they're required to build your output.

Sorry but I don't get the if-then in this case. Once I kick off the build of the child project, it copies the files it needs from the relevant global project, as specified in the global.flimpfl file. (The "Auto Sync Import" dialog that pops up.) Those files are assumed to be already on the user's machine, but in the Global project, not in the child project.,

If you don't include these files in the child project in source control, then you'll get inconsistent or broken builds because (a) different people can have different local versions of these files

But we deliberately only include files in the global project which don't change very often such as pagelayouts and stylesheets. And it's assumed that the user has the global project checked out and keeps it updated.

EDIT: In fact, thinking about this over the weekend, I would rather the build broke - if the user cannot the latest versions of the files from the Global project - than create a build based on older and possible incorrect files.

You'll also have no control over which version of the imported files are used in the child project; e.g. what if you ever want to keep a project on an older version of the imported files?

Well the result we used a global project is enforce consistency across all projects. As in a project should never be using an older or different files. It sounds like we chose to use global projects fo the wrong reasons. :\

P.

[ChoccieMuffin]

We deal with source control outside of the Flare environment, and our builds are done on a build machine that drags the latest of everything out of SVN before building.

So that we only have ONE version of the files in our Globals project stored in our repository, anything that is imported INTO a project is only stored in the donor project. When our build is run, the steps the build machine uses are:
1. Delete everything from the build location.
2. Perform a clean checkout.
3. Build the projects (which, of course, include import files).
4. Put the outputs in their defined places.

If we want to keep a note of what files were used, say for a specific release, we use the TAG feature in SVN on the entire repository, so we'd always be able to revert to that set of files.

[Dave Lee]

So you need to include these files from your child project in source control - they're required to build your output.

Sorry but I don't get the if-then in this case. Once I kick off the build of the child project, it copies the files it needs from the relevant global project, as specified in the global.flimpfl file. (The "Auto Sync Import" dialog that pops up.) Those files are assumed to be already on the user's machine, but in the Global project, not in the child project.,

What I mean is that Flare requires these files from your global project to build your project. If they're not in source control, then you add a dependency (to use an import with auto sync).

I don't use "Auto sync" in my target, as I need to control when newer imported files are introduced in a project. This means I must include these imported files in source control.
But more importantly, it also means that if I get the project on different PCs, I know the project will be exactly the same on each PC, and will build the same output.

If didn't include imported files in source control and relied on "Auto Sync", then it introduces a few things that I wouldn't be so happy about:

1) It assumes that on each PC, the person has set up the global project in the correct location, otherwise the import will not work.

2) It assumes that on each PC, the local version of the global project is always kept up to date; i.e. the person must ensure they do a "get latest" on the global project, before running a build in the project that imports from that global project. (You can mitigate this by putting the global project in a network folder, rather than a local folder).

3) There's a possibility that the project will not be the same on everyone's PC, as certain files/folders are not in source control.

4) If a user modified an imported file, would it be overwritten by the auto sync import? I know the manual import does not automatically overwrite local project files that are newer than the global project (marked in red), and these usually require investigation as it could mean that the imported files have accidentally been modified. At least when the imported files are in source control, you can't have file variations between one PC and another.