SVN vs CVS - subversion tags

Andrew n marshall (amarshal@ISI.EDU) at 13 oct 2004
Searching the web, I came up with this: http://www.pushok.com/soft_svn_vscvs.php but it is undated. Are the comments provided still accurate?

Karl Fogel (kfogel@collab.net) at 13 oct 2004

The statements of fact there are mostly accurate (some of the opinions I disagree with, but that's okay). There are a couple of mistakes, though. I've CC'd PushOk's webmaster here, in case they want to make corrections.

First, the paragraph about SVN tagging:

"The SVN developers assert with pride that they have got rid of 3 measurements by working with tags and branches. In practice it means that they have substituted both concepts for a capability of copying file(s) or directories within the repository with saving the history of changes. That is, both tag creation and branch creation are substituted for copying within the repository. From the SVN developers' viewpoint, this is very elegant decision, which simplifies one's life. However, we think that there is nothing to be proud of. As for branches, everything is not so bad, now branches are nothing but separate folders in the repository, which earlier have had some interconnection. As for tags, everything is much worse. Now you cannot tag a code, this function is simply missing. Certainly, to some extent this is compensated by universal numbering of files in SVN, that is, the whole repository gets the version number, but not each separate file. However, we suppose you will not deny that it is not very convenient to store a four-digit number instead of a symbolic tag."

The assertion "you cannot tag a code, the function is simply missing" is false. I don't know why they think you can't tag code. In Subversion, as in CVS, you can tag a working copy to get a repository structure that represents the exact mixed-version state of that working copy. Or you can tag a state that's already in the repository, again just as with CVS.

I also don't know what the last sentence means. Subversion tags are not four-digit numbers, they are UTF8 strings. Any CVS tag name can use the same name in Subversion.

While Subversion's *representation* of tags is slightly different, Subversion tags do basically the same things as CVS's. Maybe I'm just misunderstanding what PushOk is trying to say above, but the most natural interpretations do seem to be false.

The other mistake is quite understandable, as the FSFS (non-Berkeley) repository was probably not available at the time they wrote this:

"The basis of SVN is a relational database (BerkleyDB). On one hand, this settles many problems (for example, concurrent access through the file share) and enables new functionalities (for example, transactions at operations performance). However, on the other hand, data storage now is not transparent, or at least is not available for user interference. That is why the utilities for 'curing' and 'recovering' of the repository (database) are provided."

Note also that BerkeleyDB is not a "relational database". It's a data storage/retrieval mechanism, without relational capabilities.

Anyway, BerkeleyDB is now one of two options for repository storage.

I'd also like to point out that the locking/reserved-checkouts discussion now under way will soon give us one of the missing features PushOk's page talks about the most: CVS's edit/watch functionality.

Igor Pushkov (igor@pushok.com) at 22 oct 2004

1. TAGS AND BRANCHES

Again, tags and branches replaced in SVN with copy in repository. This is similar like all (I think) backup their code before they know about SCM. For example, I, when was a student, just copy each day entire source tree of my diploma. You make the same but in repository.

With your approach there NO difference between TAG and BRANCH. All that is the COPY. One copy, called TAG we _promise_ do not change. And that's why it is a TAG. But nothing can prevent me from modifying this COPY. So, some "bad" developer CAN change the TAG. How this looks for you? That's why we claim that you system not have the TAGS.

Just for me, TAG, is only TAG - some symbolic label that describes _some_ state of source code (entire rep, or some of its folder, or some file). In SVN such state is _repository revision_. That's why I make analog between TAG and your REP REVISION.

And finally, if you will allow to "mark" or "associate" some symbolic name with your REVISION for me it will be the TAG. In other words I only just one mark r12345 as "rev_1_1".

Why this needed? Very simple. I just want to get difference between my current version and version 1.0 (for example). Right now I need to compare file "_svnserver/tags/version1_0/myfile.c" with "_svnserver/myfile.c" or "r12000" with "r12356". The first is very complex (why to type full path, only because I not remember revision of version1-0). Other (user revision) is simple, but I NOT remember numeric revision of "version1_0". That's why, I think, symbolic labels for numeric revisions (TAGS are needed).

2. No comment about new fs_fs. Any way we will put the information for which version of CVS and SVN this comparison is valid. Since for example right now CVS support client side renames in repository both files and folders :)....

Karl Fogel (kfogel@collab.net) at 23 oct 2004

If the intended audience for your document were just you, all this would make sense. However, since most Subversion apparently think they are getting tag functionality in the way we recommend, your claim that "the function is simply missing" is likely to mislead most readers. It would be better to describe what's actually going on, and let people judge for themselves, I think.

I agree that would be a useful feature, but it would offer *less* functionality than CVS or SVN tags currently do, since it could only tag one revision tree, not a mixed set of paths/revisions.