From: troy d straszheim (troy_at_[hidden])
Date: 2007-06-18 11:28:20
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
> 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,
> and the latter is by
> definition not applicable.
Ok, that makes sense. Thanks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk