1

I am looking at moving a large codebase to Git. There are many groups working on the codebase and multiple release builds are in [staggered] production. Some people will be working on ReleaseBuild A and ReleaseBuild B at the same time and will need the ability to switch between the build repositories while using the same folder. Many of the files and folders will be different and many the same in each release build repository. Each repository should follow its own branching model like the one seen here: http://nvie.com/posts/a-successful-git-branching-model/ .

The reason users need to use the same folder to build files is due to the way the build scripts are setup and "security". Changing the paths would not be ideal. I have considered making separate subtrees in a single module, but that sounds messy. Submodules also sound interesting, but I am unsure if they would work if I want to use one over the other and both submodules share the same folder.

TLDR: Does anyone know of a good way of managing multiple baselines that have concurrent work being done on them using the same local folder for each?

Swan
  • 13
  • 3
  • 1
    I belive you make things more complicated as they should be. What's wrong with copying and pasting the scripts to a new directory? Why do releases have to be submodules, can't they be just branches? – Jezor Jun 23 '16 at 22:37
  • Your belief may be correct. The scripts are old/inherited and run on absolute filepaths. Files need to be in a certain spot for "security". Would you manage multiple subtrees in the same repo? The starting points for each build is unclear, so they wouldn't really be tied together until we did a merge. – Swan Jun 23 '16 at 23:16

2 Answers2

0

On windows you can use junctions to switch the current repository. See junction in sysinternals (microsoft) https://technet.microsoft.com/pl-pl/en-en/sysinternals/bb896768.aspx.

Assume your repos are in c:\repos\a, c:\repos\b and c:\repos\c and your build works only with c:\myrepo. Instead of renaming around you can create a junction like

junction c:\myrepo c:\repos\b

now build b from c:\myrepo

junction /D c:\myrepo
junction c:\myrepo c:\repos\a

now build a from c:\myrepo

Don't delete c:\myrepo in explorer, it will delete the original contents.

Note: Junction requires elevation (runas admin).

On Linux take a look on symbolic (soft) or hard links, but I never used those.

Jezor
  • 3,253
  • 2
  • 19
  • 43
lexx9999
  • 736
  • 3
  • 9
  • [Here](http://stackoverflow.com/a/185903/5922757) you can read about the difference between hard and symbolic link. It shouldn't matter which one @Swan will use in this case (files can't be moved anyway, so he might make that limitation on the repos as well). Let's say repos are located in $HOME/repos, to make a symlink to it you can use `ln -s ~/repos/a ~/myrepo`. – Jezor Jun 25 '16 at 00:41
0

From this comment I can guess you are taking care of some enterprise™ application... ugh. Just throw a bunch of branches at it and call them appropriately, like ReleaseA, ReleaseB (or ReleaseX_environment if you need to separate environments) and so on. Force your colleagues to keep the naming convention while working on features, for instance if you're using JIRA let branches be named ReleaseX_TICKET-000.

If there is no main release version, you can delete the master branch.

GIT tree for your project might look like this

If they don't know GIT, teaching them how to switch between branches will be way easier than teaching how to switch between sub modules and sub trees, not to mention merging that mess together.

And if some day your company decides that there's a need to force code reviews, the person responsible for moving it all to gerrit will thank you.

Community
  • 1
  • 1
Jezor
  • 3,253
  • 2
  • 19
  • 43
  • Someone that understands what I'm trying to get at! I was hoping there was another simple method, but the approach you've shown is probably the one with the lowest probability of errors. I'll have to see what some other developers here think. We're already setup to use smartbear collaborator actually, though gerrit looks interesting. – Swan Jun 24 '16 at 15:32
  • Why would you need another simple method if there's one already? Don't try to reinvent the wheel (; – Jezor Jun 24 '16 at 15:49
  • Also, [submodules](https://git-scm.com/docs/git-submodule) are definately not what you are looking for. `A submodule allows you to keep another Git repository in a subdirectory of your repository.`, so you won't be able to keep your scripts absolute filepaths. – Jezor Jun 24 '16 at 15:49
  • I started with the mindset that I needed to keep these different baselines in separate working repositories, so perhaps that led me wrong. It's certainly not standard to use multiple "master" type branches. The option lexx9999 brings up is interesting too. I sort of figured submodules would not work. Thanks for confirming though. – Swan Jun 24 '16 at 20:39