troy d straszheim wrote:
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.
Yea, the discussions can get confusing around here sometimes :-)
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.
Indeed, externals are a separate question. But reducing the need for them is also a goal since using them is more work for developers. With your mention of attaching the version number to the external itself I think we can use them in that form (assuming we fix the http vs https issue). So for externals we want: * To always use version specific externals (-rNNN). Unless we have some special uses, and are very careful. * Only use them for historical collections.
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?
So you mean if someone checks in a project that has tags/branches below it? Or the general someone checks in a project that I'm not interested in? The former is what I'm trying to avoid, and the latter is by definition not applicable. If I'm checking out the sandbox root, I'm interested in all sandbox projects. If I wasn't interested in the whole sandbox I would check out only parts of it. As for ignoring, I tried using the svn:ignore facility but that doesn't work for directories, only for files. So there's no way to ignore something at any one level of check out. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo