[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tags and branches are NOT the same

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2006-03-20 20:15:16 CET

On 3/20/06, Vincent Starre <vstarre@comcast.net> wrote:
> The only example I've heard is that of "I want to move a couple of files
> back to the state of the tag"
> Currently this is done with:
> svn merge -rBASE /path/to/origin/of/wc /path/to/tag/desired ./filename
>
> This has the downsides of:
> - tending to be a lot to type
> - unlike an update, you are not given an error when you try to commit
> without "un-merging"
> - there is no "memory" of the merge so that it can be un-done easily
> (an update would let you just say "update" with no
> revision specified to get back the latest- though the latest still
> probably isnt what is wanted, what you really want is what
> -rBASE was before the last update- an alias which does not currently
> exist.. so either way would probably have a problem.
> With the current implementation, you need to manually reverse the merge)

Subversion's model does require more typing, because there isn't a
natural default for comparisons the way there is in CVS. We've talked
about ways to address that, but the topic got dropped; I'd like to
pick it up again some time.

As far as the other things are concerned, how does CVS handle that
situation better? I'm not sure exactly which CVS commands you have in
mind; I can't think of any that behave in the way you'd like.

But I'd also specifically like to hear from John Calcote, too. John,
what are you trying to do with Subversion at the moment that
Subversion's tags handle poorly, but that symbolic names for revisions
would do well?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 20:15:41 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.