Re: Major cvs surgery, need suggestions

[Eric Siegerman]

On Fri, Mar 01, 2002 at 11:29:53PM +0000, David A. Desrosiers wrote:
>       What I have found which works, but is very tedious to do is:
> 
> (in repository directly)
> cp old,v new,v
> 
> (in local working copy)
> rm old
> cvs remove old
> cvs commit old
> cvs update new
> cvs log new      <-- remember all tags here, I have about 50 cvs tag -d
> tag1
> cvs tag -d tag2
> ...
> 
>       Once I do that, the new file has the full history _AND_ revision (when
> committed with -r 1.47 for example on this one file), and I can properly
> make sure that the NEW files do not show up on OLD tags and branches.

Ok, I've been sitting on this far too long.  Time to get off my
butt and release it :-)

Here's a script called "cvsmv" that does essentially what you've
described, except that it's a bit smarter about tag deletion:
  - It doesn't delete the tags physically, just logically by
    renaming them
  - It (logically) deletes revision tags from the new file, as
    you've said, but it deletes branch tags from the *old* file
    (so that "cvs update -rBRANCH" gives you the new file)

Please read -- and understand -- the documentation first.  All of
it, including the part about what the script actually does, and
the long "Bugs" section.

Above and beyond the many warnings given there, here's another.
If you use cvsmv for a major restructuring of the sort you're
considering, you might find the results at least as bad as the
other approaches you've considered.  Trust me, after a bunch of
files have been renamed two or three times each, it can get
mindbending to figure out what-all happened.

In fact, for such a major restructuring, I'd be sorely tempted to
just abandon the old repo and start a new one, keeping the old
one around read-only for historical browsing.  In my experience,
cvsmv is better used for renaming the occasional individual file
than for big things like this.

Part of the problem is that you *don't* get to type a log message
into the new file, just the old one.  I've been meaning to fix
this for ages; doing so would, I hope, drastically reduce the
confusion.  This limitation is the main reason I haven't released
the thing before now.

I'd *STRONGLY* recommend that you fix it before using cvsmv for
something as drastic as you propose (hint:  see "cvs commit -f").

Ideal would be to try cvsmv out on a less-essential code base
first.  E.g. if you actively work on some open-source project,
check that in locally, and restructure it using cvsmv.  Then WORK
WITH IT for a while to see how much of a pain it is -- this
paranoia isn't about whether cvsmv works (if it doesn't, I hope
you'll know that fairly quickly), but about whether your users
will mutiny over the results :-)

Good luck!

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
        - Anonymous

cvsmv.gz
Description: cvsmv.gz