|
Message
From: Jeremy Fillingim<jfilling@g...>
Date: Sat Apr 15 20:59:08 CEST 2006
Subject: [oc] kindly convert opencores cvs repository to subversion (svn)
I have to agree with Wesley's points on Subversion here, I can only add to
the section about locking. I understand that we are walking on thin ice with
this discussion, and that everyone has their preferred work flow.
Concurrent development is not a flaw. Version control tools are not a
substitute for communicating with your peers.
Locking people out of files on a consistent basis is problematic (I remember
the RCS days and I'm not anxious for them again). I've found that locking is
rarely "required" and I've worked on fairly large projects with dozens of
engineers and programmers poking around in the same code. Only communication
can "save" you from the "merge" problem.
Locking people out of working on a particular file simply puts the merge
burden on the person that commits last. Screw them, they were too slow,
right?. Why should I talk to someone else, I've got the file locked?. These
are things that I've actually heard form developers. The right answer in
this situation is to speak with your team about the changes and to work
together to find an agreeable solution.
Merge early, merge often. Incremental pain is preferable to finding out that
significant effort is going to waste because I or my peers are
unwilling/unable to communicate.
On 4/15/06, Wesley J. Landaker <attachment.htm> wrote:
>
> 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.htm>
>
> "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.htm>
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
>
>
> _______________________________________________
> attachment.htm
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: attachment.htm
|
 |
Browse
