Imagine you have three teams of developers, alpha, beta, and gamma. We're in the process of switching from CVS to Subversion (after which, Ovid will be seen skipping around the office singing "Ding, dong, the Witch is dead"). We have several layouts we're considering. The first is "group code" (note that the projects expect to share a bit of testing infrastructure code, but other than that, no code sharing is currently done):
svn://svn.example.com/trunk/alpha/module svn://svn.example.com/trunk/beta/module svn://svn.example.com/trunk/gamma/module svn://svn.example.com/branches/alpha/module ... etc. ...
(Where 'module' is the name of each module we currently have in CVS)
Or we could group things like this:
svn://svn.example.com/alpha/module/trunk svn://svn.example.com/beta/module/trunk svn://svn.example.com/gamma/module/trunk svn://svn.example.com/alpha/module/branches ... etc. ...
Without going into our debate, can anyone describe pros and cons of each? There's actually a third we're considering which is like alpha/{trunk,branches,tag}/module.
Re:Why alpha/beta/gamma?
Ovid on 2007-03-21T10:52:04
The concern is that the various code bases are wildly divergent, but with extremely similar names (e.g., ControlPanel), that it would be confusing. The long term goal is to merge what we can.
Re:Why alpha/beta/gamma?
Adrian on 2007-03-21T11:07:58
Ah. Okay.
In that case I think it depends on whether you think you're going to be tagging/branching all of a teams work (in which case you want your first layout) or tagging/branching on a per-module bass (in which case you want the second).
The first layout also allows you to checkout an entire teams modules in one go, where with the second you would have to check out each trunk individually. I guess you could use svn:externals to get over that.
Since you're planning to merge I'd probably go for the second, since you're aiming for a flat namespace.
In fact since your target is to remove team distinctions you might want to kill a level of that hierarchy now and have:
svn://svn.example.com/alpha-module/trunk|branches|tags
svn://svn.example.com/beta-module/trunk|branches|tags
svn://svn.example.com/gama-module/trunk|branches|tags
Re:Why alpha/beta/gamma?
Ovid on 2007-03-21T11:21:32
Well, I don't the target is to completely eliminate those distinctions. It's to have common infrastructure code that we can all share, but we'd be keeping our overall code bases separate.
Re:Why alpha/beta/gamma?
ziggy on 2007-03-21T12:19:23
If you want to keep you alpha/beta/gamma codebases separate, then consider:It allows each team to check out their entire repo, which is a good thing. It's also equivalent to the situation where you're not three teams under the same roof, but three teams in three different organizations periodically sharing code amongst yourselves:svn://svn.example.com/alpha/trunk/...
svn://svn.example.com/beta/trunk/...
svn ://svn.example.com/gamma/trunk/... If you do periodic merges of common code, do periodic merges of common code. Don't confuse your repo layout with your working arrangement. Don't expect svn to be a replacement for developer-to-developer and team-to-team communication.svn://alpha.example.com/trunk/...
svn://beta.example.com/trunk/...
svn://gamma .example.com/trunk/...
While it's a different situation, when I was setting up my CPAN repository on googlecode, what I thought about was how I (or others) would use SVK to work with the code. What parts of the repository would I mirror locally?
Putting the trunk too high up would mean I'd be mirroring everything or else having to separately mirror a trunk, tags, and branches if I only wanted to work on a single module.
/svn/trunk/{module-A|module-B|...}
/svn/tags/{module-A|module-B|...}
/svn/branches/{module-A|module-B|...}
So, better for me was a module-first layout
/svn/module-A/{trunk|tags|branches}
/svn/module-B/{trunk|tags|branches}
...
Given your description, the lowest pain structure for your teams is probably team centric, but with the possibility of merging to a common point over time.
/svn/alpha/{trunk|tags|branches}
/svn/beta/{trunk|tags|branches}
/svn/gamma/{trunk|tags|branches}
/svn/common/{trunk|tags|branches}
I also like the suggestion above to be module-centric but disambiguate by team name.
/svn/Module-Foo-alpha/{trunk|tags|branches}
/svn/Module-Foo-beta/{trunk|tags|branches}
/svn/Module-Bar-gamma/{trunk|tags|branches}
...
As modules are renamed to be uniquely named, that's easy to change. (Hooray for Subversion directory renames).
-- xdg
2nd or 3rd Option, depends...
polettix on 2007-03-30T23:47:16
I agree, one should be able to rapidly find what one is looking for, and if I'm working on Module::One I would not be happy to look for its tags among those of Module::Two, etc.I usually go for the 2nd option, but mainly because I write few modules for very separated projects. One comment above points out that 3rd option can be useful to check out the complete bunch of stuff for one's group, that could be cool. OTOH, I'd still stick to a solution in which the module name comes before its variants:
So, it basically depends on what one is willing to call a "module", in the sense of a "unified and possibly coherent set of code to provide a given functionality", at whatever abstraction level and granularity one feels comfortable to think.{alpha,beta,gamma}/{module1,module2,moduleN}/{trunk,tags,branches}If you prefer to think to the work of any group as a whole, then you have only one "module" (which you can ignore in the path specification) and your "modules" just fall back to become directories in which you're organising your work. So, IMHO it does not make sense to speak of:
but rather:{alpha,beta,gamma}/{trunk,tags,branches}/{module1,module2,moduleN}This is because the semantic I usually assign to "trunk" is that it represents the main trunk of that particular piece of work that I consider a project. Any subdirectory I create is only... a subdirectory, and does not enter in my way of thinking about the version control.{alpha,beta,gamma}/{trunk,tags,branches}/If you prefer to consider each module as a unit (possibly assigned to some specific person in the work group), then you should probably go for solution #2, and put the module name before {trunk,tags,branches}.
Just my (verbose) 2c.
