|
Message
From: Richard Tierney<rt-opencores@c...>
Date: Tue Apr 18 10:32:49 CEST 2006
Subject: [oc] kindly convert opencores cvs repository to subversion (svn)
Wesley J. Landaker wrote:
> On Friday 14 April 2006 10:30, Richard Tierney wrote:
>>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.
This is great for me as a developer, and I use it all the time, but what
use is it to an Opencores user? Users aren't going to be allowed to move
files and directories.
>>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.
I've used CVS for years, and the only properties I've ever had a need
for are Id, Revision, RCSfile, and Date, and that's covered sourcesfiles
in VHDL, Verilog, C, and C++. I can't immediately see the need for any
more properties. svn may handle binary files because of properties, but
that's comparing apples and oranges; it's not an advantage of
properties. I haven't personally had a problem with -kb but, of course,
others have. I believe that some CVS clients (tortoise, at least?) do
handle this automatically.
>>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.
Why would you want to work with a tag? I might tag my code, for example,
if it was the version that went to customer X. An opencores contributor
might tag the 'release 1' revision of the code. You don't mess with tags
after creating them; they're useless if you do.
> 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.
I'm still finding my way here. The manual says that we have two options:
1 - "make sure all users know how to treat the directories that they
copy in there"; in other words, manual agreement not to screw up. Dumb,
but it's what we currently use.
2 - Use a server access script, as you suggest. The only problem is that
svn doesn't have a server. It can work with anything, which currently
means Apache or svnserve. In other words, "we don't know how to/can't
handle this problem in our own software. However, you should be able to
handle it in your server; here's a plugin that sould work for you". Or
have I misunderstood?
>>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. =)
Yes, Guenter pointed out to me offline that I could configure to use an
external diff program. I would rather integrate into emacs, which has a
lot of advantages (copy/paste, changing between horiz/vert compare,
on-the-fly WS ignore, keeping a buffer with the old revision in, and so
on), but I would certainly like to find out how to get some sense out of
svn diff.
Can anyone give me a 1-minute-idiots-guide to this? What external diff
do you use?
> 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.
The CVS integration is excellent and transparent in xemacs. I've never
had to install anything on any version of [x]emacs I've ever used. Just
go to tools->compare->FileWithRevision, and it's trivial to compare any
two revisions of any file. As an aside, svn's global revision number
system would make this difficult.
>>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:
> <snip>
> 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)."
Maybe, but:
1 - how do you compare 2 revisions of the same file? You first have to
find out what the svn revision numbers of those files are. Tedious and
error prone. If I compare 1.20 and 1.21 on CVS, for example, I *know*
that these two files differ by one commit. I have no such guarantee in svn.
2 - "They're talking about a particular tree" means the tree of the
whole repository, not *my* project. I'm currently on revison ~25,000,
even though I've only done about 100 commits on my project, and I'm the
only person on the project.
It seems to me that this feature may be nice for the svn developers, and
less so for svn users.
> 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.
CVS has commit locks to simulate atomic commits, and I've never had
problems with that. But then again, my view is that this is an
architectural limitation of CVS, which means that it's not suitable for
commercial work.
>>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.
This happens to me every couple of weeks on svn. A commit fails, I
scratch my head for a while, I do an svn update on something for which
svn status shows no problems and, voila, the commit suddenly works.
>>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).
Yes, Guenter pointed out the locking feature as well, which I haven't
looked at yet. 'copy-modify-merge' is an article of faith in the CVS
world, and the svn manual essentially repeats this. Both the CVS and svn
manuals go out of their way to trash the 'lock-modify-unlock' paradigm.
It'll be interesting to see how they justified this new feature.
Bottom line: what is the killer advantage of svn that makes anyone think
it's worth the effort of switching lots of existing CVS projects over to
svn? I can't see it; it would just be busywork. Now, if someone was
suggesting that new projects should go on svn, there might be a case for
that. My personal opinion is that it might be worthwhile if there was a
nicely-integrated emacs diff, but not otherwise.
My own view? I'll probably go back to CVS after this project. The
file/directory move is great, but not so great that it outweighs the
advantages of emacs diff'ing.
RT
|
 |
Browse
