|
Message
From: Wesley J. Landaker<wjl@i...>
Date: Tue Apr 18 14:55:26 CEST 2006
Subject: [oc] kindly convert opencores cvs repository to subversion (svn)
On Tuesday 18 April 2006 02:32, Richard Tierney wrote:
> > 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.
As I mentioned above, this also benefits users who have working copies
checked out if the developers do moves or renames.
> > 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.
You're misinterpreting "work with". I said "working with tags and branches".
Often I want to "work with" a tag by, e.g. compiling/simulating it, perhaps
comparing files from it against other branches, etc. Obviously if I want to
commit to it, I'll make a branch. =)
> > 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.
> 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?
SVN has two official servers. One is svnserve, the other is an apache
module. Both are part of the official distribution. Both support built-in
per-user, per-directory, fine-grained access control, configured with a
simple config file. If you want to do something odd, SVN provides hooks to
allow you to customize the way your server behaves. This isn't matter
of "we don't know how", but "we are giving you flexibility".
(For instance, I personally *never* want to make my /tags directory
write-only. Often there is a reason that tags need to be adjusted. The same
is true of CVS tags, which is why there is "cvs tag -F". Obviously it needs
to be used carefully, but the situation is better with SVN. If in CVS you
move a tag, you loose any possibility of restoring that tag to where it
used to be; with SVN, all you'd have to do is revert the change, so you
would never loose data even if someone made a mistake.)
> 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.
"svn log" on a file will show what revisions it actually changed at.
> 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.
You can set up a repository per-project if you want, a lot of people do
this. In general, there is not usually a reason that it matters what the
global revision is, since you can get detailed info about the files or
directories you are interested in by doing a "svn log".
> It seems to me that this feature may be nice for the svn developers, and
> less so for svn users.
I've actually loved it as a user, since it means real atomic changesets, as
opposed to non-correlated per-file revisions in CVS.
>
> >>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.
Actually, that sounds pretty normal, not an failure at all. You can't commit
if the directory is out of date, so the client will force you to do a "svn
update" first.
> 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.
There are plenty of justifications, it's useful in a few different
scenerios. But the bottom line is, you wanted it, you've got it. =)
> 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.
Well, sounds like the emacs support is the big selling point for you. Maybe
you'll like SVN better if the emacs gets better. =)
--
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
