[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS Update Behaviour

From: Greg A. Woods
Subject: Re: CVS Update Behaviour
Date: Fri, 22 Feb 2002 17:49:48 -0500 (EST)

[ On Friday, February 22, 2002 at 14:45:32 (-0600), Steve Greenland wrote: ]
> Subject: Re: CVS Update Behaviour
> On Fri, Feb 22, 2002 at 02:14:21PM -0500, Greg A. Woods wrote:
> > [ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: ]
> > > On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote:
> > > > It's hardly even noticably
> > > > more difficult to track the history across multiple files.  
> > > 
> > > Greg, *that* statement is complete and utter crap. Or, please post the
> > > single *cvs* command that will display the full history (equivalent
> > > of 'cvs log') of an entity *accross* renames/moves.
> > 
> > No, you're full of crap too if you think that's a necessary feature.
> You've failed to read what I wrote. I didn't claim it was necessary.

No, I didn't fail to read what you wrote.  As you can see above in your
quoted sentence you have clearly implied that the only way you see fit
to do this is with a "single *cvs* command".  There's no need to read
between the lines to interpret your implied requirement (only to
interpret your emphasis markings).  I repeat:  That is not a necessary

> I didn't claim it was common. I, in fact, wrote that I was generally
> satisfied with CVS.

I didn't say you did, did I?  :-)

> What I *wrote* was *your* claime that tracking
> history across renames was an effort that was "hardly even noticably
> more difficult" was crap.

And you're wrong.  Following history, or indeed doing diffs, across file
renames is truly and literally "hardly even noticably more difficult".

Perhaps what I can now do intuitively is hard for someone else, but if I
learned to do it intuitively then pretty much anyone can learn it too.
I'm no superman and I don't believe I have a photographic memory or
anything fancy like that either.

Perhaps someone who doesn't understand the basics of what's going on
with version control might have more trouble, but they're basically lost
on even the most simple commands until they get some fundamental
understanding anyway.  Once they get the basics under control then
tracking history across renames is only a tiny step, not anything

> Since I can read the history of a single file
> (non-renamed) with one cvs command, I wanted to know how to do it when
> the file (entity, if you prefer) *had* been renamed, or moved to another
> directory. Reading the change log of the current file to (hopefully)
> find the comment about what the name of the file *used* to be and then
> reading its changelog, etc. etc. is *not* hardly more difficult.

It seems perfectly simple and very quick when I do it.  Perhaps you
should try it:

        cvs log newfile.c | less

        [[ read along until you get to the end and see: - moved
        oldfile.c to newfile.c]]

        cvs log oldfile.c | less

        [[ and so on.... ]] 

Maybe someone with difficulty typing commands would find this
"difficult" because of the extra typing, but they would presumably find
using any part of the command-line interface to be similarly "difficult"
and should probably be using a mouse-driven front-end or some such.

(yes it might also be more difficult if your front-end prevents you from
reading the log of an arbitrary removed file, but that's not CVS' fault!)

> The
> only place the rename info is stored is in the changelog, and if the
> person who made the change didn't get the right comment in there, it's
> lost. Should the comment be there? Of course. But people make mistakes.

So automate the process with a wrapper that doesn't make mistakes!!!!!!

Said wrapper is already quoted below!

> If being able to deal transparently with file renames and moves is
> important to one, then CVS is not the proper tool. 

Well we do agree on that for sure -- but I assert it's never going to be
a terribly important requirement in any usage domain where CVS is
otherwise the proper tool.

> > I've posted the basic starter wrapper I wrote to do this several times.
> > In fact I wrote the damn wrapper separately each time. 
> That's actually kind of sad. Why don't you put the script(s) in the
> contrib directory, and point people at it when the topic comes up,
> rather than expending the effort arguing and re-writing the script?

Because they're too simple and too lame to ever worry about remembering!  

> Hmmm, searching in, the only thing I could find
> is 
>       cp $1 $2
>       cvs rm -f $1
>       cvs add $2
>       cvs commit -m "moved $1 to $2" $1 $2
> from January 2000. If that's the script you rewrite every time, well,
> yeah, that's easy.

Yup, that's pretty much it.  It sure is easy isn't it!  You need some
more mechanism around it if you want to use it as a general wrapper
(i.e. to enforce its usage), and of course there are the other bits that
should be self obvious if you want "log" and "diff" and such to work
across renames.  Such a feature could trivially be built into the many
front-ends too (which are usually literally "wrappers"), such as PCL-CVS
(which is the one I use), or WinCVS, etc.

> I was hoping that you meant you'd written scripts
> for logging, and/or diffing and merging a branch when files have been
> moved/renamed.

I've showed a number of times how they would be designed, but that
should be quite self-obvious given the starter above anyway.

I've never actually written a script to do it because it's brain-dead
easy and obvious how to do it manually, and like I said I can only
remember having to do a diff manually across a rename once in 8 yrs!

I did think briefly of writing rename support for PCL-CVS, but it's just
too infrequently used to be worth the effort.

If/when someone goes to the effort of produceing working code regardless
of how needed it is then perhaps it'll be added to the appropriate
public shared version of wherever it best fits (eg. a script in contrib
or a new lisp function in PCL-CVS, or whatever).  Until that time the
manual way is trivial, and quick, and it works 100%.

                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]