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 (firstname.lastname@example.org) 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
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
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 (email@example.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 (firstname.lastname@example.org) 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
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.