On Mon, Jun 18, 2007 at 12:26:50AM -0500, Rene Rivera wrote:
The abstract structure that is equivalent is something like:
/trunk /project1 /project2 /branches /project1 /one (branch copy here) /two (branch copy here) /project2 /breaking_changes /int_to_double (branch copy here) /nonbreaking_changes /int_to_long (branch copy here) /tags /project1 /1_0 /1_1 /project2 /prerelease /0_1 /0_2 /release /1_0
[various snips]
The proposed structure facilitates such fundamental operations as:
* renaming a project (all the branches come with you) * deleting a project (same) * finding out what branches exist for a project (they're right there) * controlling commit access to individual projects (it's only one directory) * giving descriptive names to branches (there are separate branch namespaces) ** you can easily see what projects exist ** you can easily locate all the branches of a project ** you can easily rename/delete a project and all of its branches. ** you have more namespace for your own pet branch, so you can give your branches more succint and descriptive names.
Oh man. I was trying to interpret noise the whole time? Egh. Ok so looking at the above I agree, of course they're essentially the same thing. This arrangement also does not preclude the use of externals or other piecewise-checkout mechanism, and it is easy to change should there be a need. End.
And as I've mentioned before the disadvantage to bottom-up:
You don't have a single directory you can check out to see the current set of projects. If you check out the root you get every version of every library filling up your drive with stuff most people don't care about.
Ah, so the 'common use case' is that you want to check out the entire sandbox. Of course you're right, you can't do this when tags/branches/trunk are together. So what happens when somebody checks a garbage project in to /sandbox/trunk/garbage? Does this ruin your day, or do you have some way to mark it as unwanted? -t