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

Re: Re: Simple Label=RevisionID Discussion

From: Bob Hiestand <bob.hiestand_at_gmail.com>
Date: 2006-12-01 21:23:52 CET

On 12/1/06, Chris.Fouts@qimonda.com <Chris.Fouts@qimonda.com> wrote:

> >Since you know how to reuse tags, please describe how the
> >different implementation in SVN doesn't fit your requirements?
> > For me, the functionality is the same.
> You got me here, sorry for leaving the relevant context.

I'm not trying to get you, I'm trying to understand how tags in SVN
don't do at least as much as tags in CVS. The only issue that I've
personally encountered with respect to the branch model is that it's
easier (faster?) to trace changes made in other branches. This is
something that doesn't come up very often (only when a merge has
issues), and is partly a consequence of the fact that I don't use any
tool other than the command line.

As far as I can tell, the requirements I and my organization have for
tags are met by SVN quite well, and in fact better, than by CVS.
That's why I'm trying to understand the tags use case that SVN doesn't
address that CVS does.

> >On the other hand, CVS doesn't inherently stop you from moving
> >tags, thereby losing history of how they were placed, which
> >SVN doesn't do.

> It's changing the "concept" that I don't prefer (note I said
> "prefer"). Historically, in other revision cotrol systems -
> CVS, clearcase, Perforce(?) - tags/labels are NOT branches,
> but in SVN, they essentially are. I'd rather separate the
> two.

Fair enough. I think it just may be part of the learning curve of SVN
(repository revision vs file revision, and tags and branches as
copies) that frustrates people. I think that both concepts have very
positive results, however.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 1 21:24:28 2006

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

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