Steve Bakke wrote:
> Subversion has been billed as the ³successor² to CVS. Granted, there are
> many things such as tags that work in a different way. However, why is it
> that some people take the attitude that the way subversion implements tags
> actually covers the valid use-cases people had under CVS. Tags generally
> are used for two types of things 1) a coherent release of a group of things.
> 2) An attribute or indication of quality on individual files which may or
> may not be coherent as a group.
> Please at least admit the fact that Subversion tags do not really implement
> the use-case of identifying the ³status² of a set of files. You can use
> Subversion tags for this, but it¹s really just an approximation. For
> instance, I would really like subversion to support this use-case:
> * In working on several files at the head of tree, I run through a series of
> quality checks. Upon meeting quality criteria of a given type, I apply a
> status tag to this file.
> * Later, I gather all of the files with a particular status or tag to create
> a release branch or more conventional tag.
> While I understand your point, you wrongly assume that the subversion way is
> appropriate for all cases. Subversion only deals with the second of these
> two cases and ignores the first. Why is it wrong to support this use-case?
> There are many other reasons to switch to subversion aside from tagging.
> Versioning of the directory tree is critical. What a major PIA to do this
> in CVS.
> Why can't we have the current subversion-style tags for some instances while
> supporting the "status" type tag use-case? Call it something different if
> you like. In reality, subversion tags are really just branches, and
> "status" is what in CVS was called a moveable tag.
The short answer is that the current implementation doesn't and cannot
easily allow it.
File properties are associated with a specific (revision,path), and like
file contents, they immutable (once committed they cannot be removed)
and revision properties refer to the whole directory tree starting at
the repository root. Neither serves your purpose.
The main "changeable things" in Subversion are the file and the
directory, so you are currently stuck with those. I think it's best
to simply consider Subversion primarily a versioned filesystem (duh!),
and consider its operations in terms of a (versioned) file system, i.e.
*copy* a directory (cheap and with history) and *not branch or tag*
a directory; and not consider Subversion to be a CVS look-alike
One problem frequently cited w.r.t. CVS tags is that their operations
are not versioned. For instance, if you screw up with your moveable
tag, there is no way to get back (unless you manually maintain your
own "backup tags"). Once your "lose" them, they are gone.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 23 00:36:16 2007