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

Re: CVS/SVN comparison

From: <kfogel_at_collab.net>
Date: 2004-10-13 18:22:05 CEST

Andrew n marshall <amarshal@ISI.EDU> writes:
> 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?

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.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 13 20:11:47 2004

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.