|
Message
From: Richard Tierney<rt-opencores@c...>
Date: Fri Apr 14 18:30:49 CEST 2006
Subject: [oc] kindly convert opencores cvs repository to subversion (svn)
I've been using subversion for a few months now; here's my 2c.1 - what it's really good for is moving and renaming directories and
files. This is a real pain in CVS. But, of course, this is only of any
use to the person who creates the repository in the first place; it's of
no use to people who just want to do occasional commits or updates.
2 - getting a browser view into the repository is occasionally helpful.
You can look at old tagged distributions, for example.
3 - versioning of metadata, properties, etc. - this is just pointless
busywork. If you just want to do keyword expansion and setting filenames
to be ignored, then CVS is *much* easier. I can't even think of anything
else I'd like to do with metadata.
4 - svn doesn't do tagging; you implement it as a directory copy. This
is bad, bad, bad. Anybody can come along afterwards and mess up my tag;
you have to agree with other devlopers not to touch it.
5 - retrieving old revisions and comparing them - bad, bad. There's not
even a whitespace-ignore option on 'svn diff'. Actually, I suppose the
real problem here is emacs. With xemacs/CVS, I can easily extract any
two versions and do a graphical/ediff compare. There are 2 svn modes for
emacs, and they're primitive, unless I've missed something. 'svn status'
will let me ediff the head against the current file, but I haven't
been able to do anything else with it. This is the real killer; if I
can't fix this, I'm back to CVS.
6 - svn ups the revision number on the entire repository for each
commit, so individual files may have version numbers which differ by
hundreds. You have to go back and cross-reference the history to do any
comparisons. On reflection, I think this is probably not good; I'd
prefer consecutive numbers on all files.
7 - versioning of symbolic links - sounds good, haven't tried it.
8 - stability/bugginess - not too bad. I've had a couple of problems,
but nothing major.
All the other features are basically just "so whats". It may have a
fancy client/server architecture, and there may be fancy underlying
databases, and commits may be truly atomic, and so on, but this doesn't
do much for me as a user. I've never had a problem with a commit on CVS
messing up, but I've occasionally had commits fail on svn.
And, of course, svn and CVS both have the same flaw of allowing multiple
developers to work on the same file at the same time, relying on merging
to fix things afterwards. I guess this may be Ok for free software work,
but it's no good for professional use.
RT
|
 |
Browse
