Hello Magnus,

"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."

It definitely sounds like that.  However, we're a VERY small group (3 main 
users!!).  And I'm just trying to get us out of the Stone Age from VSS.  So 
I'm not really familiar with CMS.  I've heard of Chef and Puppet, but know 
very little about them. From what I DO know, they sound like overkill 
solutions to our tiny little group and our isolated world. Already imposing 
Git on the other guys will be demanding enough.  So I think I *am* going to 
go with Git Submodules and a SuperProject.  Tools like 
SourceTree/TortoiseGit make handing those Submodules a lot simpler than 
through the command-line (we're on Windows platforms).  I guess I should 
have added some of that info as part of my question, in retrospect... 

I'll look into the google git-repo thing you posted... as well as what 
Phillip has mentioned.

Thanks for your inputs, Magnus!

Enrique


On Thursday, January 12, 2017 at 4:53:03 AM UTC-5, Magnus Therning wrote:
>
>
> Enrique Benedicto <enriq...@gmail.com <javascript:>> 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 <javascript:>   jabber: mag...@therning.org 
> <javascript:> 
> 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.

Reply via email to