Enrique Benedicto <enriqueb...@gmail.com> writes: > I'm relatively new to git and I've been struggling to come up with a > directory/repo structure for our setup at work. So here's the current > directory structure and characteristics: > > Common to all *MainProjects* defined below. These files don't change > very often. > > - .\Common\Bin > - .\Common\Lib > - .\Common\Include > - .\Common\Source Files... > > Below, *MainProject1* contains entirely different code than > *MainProject2*. HOWEVER, I must be able to tweak the names of the > *MainProject* folders to account for different revisions... So, for > instance, *MainProject1_ver1*, *MainProject1_ver2*, etc... > > - .\MainProject1 > - .\MainProject2 > > So typically, I would create a separate repo for the .\Common files. > Then, I'd create two separate repos for the *MainProjects* and simply > rename their container to match whatever revision they contained. > However, the *MainProjects* are tied to a specific version of the > .\Common files. And the .\Common files, which don't change often, > would be "outside" of the *MainProjects* repos.
What you're describing here sounds more like configuration management to me, i.e. you want to record what combinations of repos that make sense (a configuration) somewhere. However, git is a version control system (VCS), so it isn't a good tool for doing that (though it has some simplistic CMS features like submodules). > This almost sounds like I should have 2 superprojects, with .\Common & > .\MainProject1 in one superproject... and .\Common & .\MainProject2 in > the other superproject. But the problem with superprojects is that it > *seems* I won't be able to customise the *MainProject* names to > reflect their revision. I believe tools like `git-repo` (https://code.google.com/p/git-repo/) support this. > What's more... I don't want to recompile the .\Common binaries on all > instances of MainProjects. I simply want direct access to the binaries. In > this case, should I create 2 different repos for the .\Common files; one > which contains the source files and another which contains the generated > binaries only? If so, I'd create the above-mentioned superprojects out of > the "binary" version of the .\Common files? I'd start with looking at the possibility of using a (shared) build cache for .\Common :) Otherwise see if you can get your CMS tool of choice to share a local .\Common between all locally checked out configurations. > This really is biting me... Just can't think of a good way of doing this... > Any help would be greatly appreciated. Hopefully this helps somewhat. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus "Sendmail" and "make" are two well known programs that are pretty widely regarded as being debugged into existence. That's why their command languages are so poorly thought out and difficult to learn. It's not just you — everyone finds them troublesome. — Peter van der Linden, Expert C Programming, p. 220 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
