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

Re: Subversion Vision and Roadmap Proposal

From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Fri, 9 Apr 2010 20:31:48 +0200

On Fri, Apr 9, 2010 at 10:13, Vadim Chekan <kot.begemot_at_gmail.com> wrote:
> P.S. Pleeeease, introduce true tags, no more "lets pretend this copy is a tag".

What's a "true" tag? What's it good for? How would it behave?

Subversion and the DVCs mean more or less the same thing when they say
"tag", modulo the fact that an Subversion repository can hold more
than one project. In all of these systems a tag is effectively 'very
much like to a branch, but never changed after creation'.

Subversion implements these as cheap copies, but they could just as
well be implemented as a file of path+revision. (Akin to how Mercurial
implements tags).

CVS, on the other hand implemented tags in a fashion that was very
different. Tags were effectively like labels that you could apply to
particular versions of particular files. You can tag incrementally,
marking files as they became "ready". This approach is file-centric
and doesn't mesh well with the atomic, whole-tree model of versioning
presented by Svn, Hg, Git, Bzr.

I suppose you could simulate some of the tags-as-labels use cases with
properties or by copying files from one place in the repository to
another as they become ready. Neither of these approaches fully
simulates what CVS means by "tag", however.

This isn't the first time this topic has come up on this list. The
discussions always seem to end in exhortations to model the solution
to your issue in a fashion compatible with what Subversion offers,
rather than fighting against it.

What I still don't know is this: how would "true tags" behave, if
Subversion had them? What problems would that enable me to solve more
conveniently than I can now?

// Ben
Received on 2010-04-09 20:32:16 CEST

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