On Mon, Jun 18, 2007 at 09:34:40AM -0500, Rene Rivera wrote:
Oh man. I was trying to interpret noise the whole time? Egh.
Yea, the discussions can get confusing around here sometimes :-)
Yeah. Sorry. :)
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
The issue is if the overall net benefit offsets this additional work... my experience says that it does, by a lot. In practice it has been a few people (release manager types) that deal with the externals.
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.
The http vs. https thing is solvable (just allow anonymous https, there may be other ways), but I don't follow here... why would externals be useful for historical collections only? At what point in the process would externals be introduced?
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,
Right.
and the latter is by definition not applicable. [snip]
Ok, that makes sense. Thanks. -t