On Friday 27 July 2007 13:49, Johannes Schindelin wrote: > Hi, > > On Fri, 27 Jul 2007, Ray Lehtiniemi wrote: > > On Friday 27 July 2007 13:05, Johannes Schindelin wrote: > > > On Fri, 27 Jul 2007, CPD wrote: > > > > We produce variations based on a (mostly) common codebase. In CVS I > > > > set up "environment" modules for each platform, then when you are > > > > working on that platform, you simply check out the correct > > > > environment and build. Only the needed code and tools are exposed in > > > > that environment (this is important as clients must NOT see each > > > > other's code and most customers have some customization). I do this > > > > by defining and renaming modules in the CVSROOT modules file. > > > > > > I would use branches for that. A base branch with the common code, and > > > the customisations in all the branches, which merge from the base > > > branch. > > > > this would break down if there were client-specific modules in the base > > branch, though... how could those be hidden from the other clients? > > Umm. Don't put the client-specific modules in the base branch, then? The > base branch is the common code, the code that every client may look at. > Nothing else. yes, i don;t think there's any other way to do it with branches (and just be careful not to merge the private branches back! :-) > Maybe I did not get the whole picture... do you want your _clients_ to > access your main repo with Git? not in my case, anyway... although if you define "client" to include "subcontractor", then yes, i'd be interested in going down that road... sometimes there are pieces which they aren't licensed to see, but if we could somehow track their work in a separate repo and then easily merge it back into the fully licensed tree, that would have great value. from the original message, i also keyed on "Only the needed code and tools are exposed in that environment". this is something i'd like to see too... i'm working in a software eco-system with hundreds of standalone components, and would like the ability to pick and choose a small handful of those for any given project, without pulling in reams of history on the stuff i'm not using... thanks ray > > Ciao, > Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
