On Fri, Apr 9, 2010 at 10:13, Vadim Chekan <kot.bege...@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
