|
Message
From: Wesley J. Landaker<wjl@i...>
Date: Sat Apr 15 16:07:06 CEST 2006
Subject: [oc] kindly convert opencores cvs repository to subversion (svn)
On Friday 14 April 2006 10:30, Richard Tierney wrote:
> I've been using subversion for a few months now; here's my 2c.
I've been using subversion for years, and CVS for many *many* years. Here's
some comments:
> 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.
Actually, having support for directory moves helps people who do occasional
commits and updates *a lot*. In CVS, if you move files, you either lose all
the history behind them (because you did an delete+add), or you break all
checked out working copies (because you moved a ,v file). In SVN, this
doesn't happen: you just move the file or directory, then when people
update or commit, everything is handled automatically.
> 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.
There are actually a number of wonderful things you can do with properties,
but let's focus on keyword expansion. You can set up a SVN
with 'auto-props' and it will automatically add your preferred set of
keyword expansion parameters to e.g. VHDL and Verilog files. Also, SVN
handles binary files automatically because of properties. Have you ever
been bitten by forgetting CVS's -kb on a binary file? Not a concern in SVN.
> 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.
I'm not sure why you think this is bad; this makes working with tags and
branches *so* much easier than it is in CVS.
Also, this isn't really true: you can set up a simple commit hook (an
example is included with the distribution) to prevent modifications to tag
directories, or you can use simple per-directory authorization that is
supported in both servers architectures to stop anyone but users you choose
from making or modifying a tag. Both of these are very simple to do.
> 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.
No true. svn diff has a --diff-cmd argument, that lets you use an external
diff program, e.g. GNU diff or a graphical diff program. I do this all the
time to get a whitespace-ignoring diff. You can set these up as defaults in
your SVN client, so if it's something you do all the time, you don't have
to type it. =)
I use xemacs almost exclusively as an editor, but I don't use the CVS or SVN
integration, so I can't comment on how good or bad it is.
> 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.
I believe this is a good thing, it's just not what you're used to from CVS:
To quote from: <attachment.pgp>
"In CVS, revision numbers are per-file. This is because CVS stores its data
in RCS files; each file has a corresponding RCS file in the repository, and
the repository is roughly laid out according to the structure of your
project tree.
In Subversion, the repository looks like a single filesystem. Each commit
results in an entirely new filesystem tree; in essence, the repository is
an array of trees. Each of these trees is labeled with a single revision
number. When someone talks about “revision 54”, they're talking about a
particular tree (and indirectly, the way the filesystem looked after the
54th commit)."
> 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.
They may be features that you don't use or care about, but they aren't just
bells and whistles. SVN was architected specifically to get around
limitations of CVS. This applies to limitations CVS has when used in a
large development environment with many concurrent users. CVS lack of
atomic commits can be a nightmare in some situations.
> I've never had a problem with a commit on CVS
> messing up, but I've occasionally had commits fail on svn.
I've had exactly the oppposite experience.
> 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.
This is not true, SVN supports locking as of version 1.2 (been out for quite
a while).
--
Wesley J. Landaker <attachment.pgp>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : attachment.pgp
|
 |
Browse
