* Thomas Hauk <tom@xxxxxxxxxxxxxx> wrote: > Back when I worked at a large games company, we used Perforce, and > our repo structure looked a little something like this: > > /branches > /alpha > /beta > /mainline > /packages > /external > /foolib > /1.0 > /1.1 > /2.0 > /internal > /barlib > /dev > /1.0 > /2.0 > /bazlib > /2.34 > /2.35 > /qux > /dev Ah, you're conditioned by a VCS that mixes up directory copies and branches, just like SVN or TFS - those folks (VCS developers as well as their userbase) still don't get the idea that these are orthogonal concepts ;-o Needless to say that this makes working w/ branches quite hard (compared to git ;-p), not even to mention things like remote tracking, rebase, etc. (guess what: M$ itself recommends against branches or at least very beaurocratic planning and processes in their own official TFS papers ;-p) Just forget about that all, forget the whole idea of having dozens of packages in one fat tree. Develop and track each package saparately and use an separate dist build tool (eg. Briegel) to put things together. It'll take some time to get your head around this ideology, but it'll pay out if you do it consequently. (I've already been through this some years ago). > At the package level, we would split up packages/libraries into two groups > based on if they were developed at the company or not (external/internal), Why exactly that split ? Why not having each package separately, independent on the supplier ? Each package should stand completely on its own (assuming dependencies resolved), or it isn't really a package but just a bunch of files. > and inside each one, we might have multiple versions. In the example above, > the repo is for the "qux" game, which uses an internal "bazlib" library > developed by another group, and the "barlib" library which was developed > for use on "qux" and may be used simultaneously on other projects. That qualifies an _separate_ (generic) package, which should be developed and deployed separately. If you need to tweak it for (potentially) each project (so, have per-project branches of it), you'll most likely have some serious architectural flaw. > I've successfully used this repo structure with several other projects > over the years at other companies (who were mostly using Subversion). My current customer also used such a model (previously in PVCS, not TFS), and they discuss hours over hours about how and when to branch and whether certain things could be merged back at all, instead of just doing the actual work. For the product I'm currently working on (imagine that: an embedded linux project that gets tracked via TFS ;-o) they always tried to do the projects (each on essentially the same codebase, but each job/project has some customer-specific changes) sequentially (and even mixed up with standard feature development), so they could lie to themselves that they would never need branches. In the end they had two completely separate incompatible codebasis which now have to be "merged" together manually, consuming several man-month. (now I'm there to clean up the mess ;-o). > Now I'm trying to get into the Git swing of things, but it seems to be > that Git only offers project-level branching, and doesn't allow for the > kind of package-level branching I'm describing here. On sourcetree-, not project-level. Projects and sourcetrees are completely different concepts. Another important point that many folks (especially IDE designers) never really understood. > Am I incorrect or is there a way to accomplish with Git what I was > doing before with P4 and SVN? Not really. Rethink your project organization and workflows. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@xxxxxxxx mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- 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