Subject: Re: mono experience cutting to subversion
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
Date: 02/11/2005 02:22:47
[ On Friday, February 11, 2005 at 00:27:52 (-0500), David Maxwell wrote: ]
> Subject: Re: mono experience cutting to subversion
> On Thu, 10 Feb 2005, Herb Peyerl wrote:
> > Looks to me like a bunch of stubborn developers who don't want to
> > change their ways to take better advantage of a new tool... Not so much
> > subversion problems...
> > I rarely run 'cvs annotate' myself.
> I run it quite a bit.
Me too -- which makes me especially happy that I can copy the entire
NetBSD CVS repository to my own local systems for quick and reliable
access even when my ISP is scrambling their routing tables.
> I think it depends on whether you're working on
> parts of the code that you know well, or are called to look at parts
> that you don't know well.
Indeed. It also depends a great deal on what you're doing, or trying to
do, with the source -- i.e. the reasons why you need to look at the code.
For some of those purposes it dosen't matter how well you know the code,
but instead it matters more how many other developers have been working
Overall I find "cvs ann" at least as valuable as "cvs log". Although
it's extremely rare that I run "cvs ann" without viewing the log, I do
frequently look at the log without annotating the code. However that
doesn't change the fact that I find "cvs ann" more _valuable_ as a tool
than the log alone.
About the only other sub-command that's equally valuable for code
maintenance is "cvs diff". However it's a hell of a lot easier to view
the annotated listing than it is to run a whole sequence of diffs to
find exactly which revision a given change was contained in.
For example if you're doing maintenance and you think you've spotted (by
way of reading code, for example) a fix on head of the trunk that you
need on a production branch then you need to know what revision that
change was made in so that you can extract all the relevant changes
together (i.e. so that you can formulate the correct "cvs diff"
options). Of course you also need to see the log message to see if the
explantion might match, and to find any possible matching commits in
other files.... :-)
Even if you're only working on new changes it's often invaluable to see
who did what, when, before you -- it's one very good way to make a bit
more sense of the commit log and to understand what parts of the commit
log are now irrelevant (e.g. because the code changes some parts refer
to have since been replaced with yet newer changes)
I would strongly suggest that those who don't run "cvs ann" frequently,
and who don't find the output useful, either haven't used it yet enough
to appreciate it, or else know some secret magic that I wish they'd let
the rest of us in on! Of course the Occam's Razor principle suggests
that it's "cvs ann" which is the secret we should be letting them in on! ;-)
I just wish I had time to fix up the font-face and colour selections
used by PCL-CVS so that I could actually read annotations in emacs on my
(I also long for the ability to do equivalent annotations of my old SCCS
archives, or at least I do every time I have to use them -- some day I
may even take the time to write something to do it. I suppose I could
try to convert them to CVS, even if just as read-only archive, but that
doesn't seem like a very elegant way to approach the problem, and it
would lose in a big way if I couldn't translate the branch structures
W.r.t. switching to something else instead of CVS, well I'd say don't
try to fix what aint broken, and the mutterings that started this and
related threads certainly did not give any valid justification for
believing anything was broken per se.
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>