On Mon, Nov 20, 2006 at 07:30:09PM -0000, Nikki Locke wrote:
> Phyrefly wrote:
> > > I speak from a position of some ignorance here, but which subversion
> > > commands will accept a revision number (or, in the proposal, a
> > > label) will NOT accept a tag in the same place in the command
> > > line, to mean the same thing?
> > Please scan the thread's history for the explanation of complexity for
> > non-technical users who get used to changing one parameter and now
> > have to change another to something completely unrelated.
> > (and I think the answer to your question is: all of them. A tag is
> > not a revision, so -r[URL] will never work)
> I have been following this thread since it started. But my question
> was completely wrong. I'll try to rephrase it...
> What commands can you do with a label/revision no (using -r<label>)
> that you can't do with a tag (using the tag url)?
> If there are none, then it comes down to saying "My users are used
> to the CVS command line, and can't cope with doing things a slightly
> different way". If it does come down to that, then your case is very
> But I suspect there are things you just can't do with a tag - I just
> want to know what they are.
How about cherry pick multiple files at different revisions without
going crazy? See any of my prior emails/use cases on the issue.
The problem with SVN's tags as I see it is that it defies common
understandings of space/time. Space is branches - different lines of
development, different files in a tree etc. It is the "name" or
location of the object you are working on. All can be handled by a
Versions/revisions always occur along the time axis not the space
axis. SVN even recognizes this by allowing date or revision numbers as
the parameter to the -r flag. SVN just doesn't follow through on it
preferring to use space (a tag) to define a point in time (release of
a portion of a tree) rather then supplying a true time only based
mechanism for identifying revisions of a given file or compatible
revisions of a set of files.
That is IMHO the crux of the issue and will continue to be until some
more natural/orthoginal mechanism for identifying revisions of files
that should be treated as a single entity is devised.
603-643-9300 x 111
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Nov 20 21:19:00 2006