[SOLVED!] RE: help, doing a CVS import messed up my working dir!?!?!

[Dave Korn]

----Original Message----
>From: Dave Korn
>Sent: 22 August 2005 19:23

  I think I finally sorted my mess out!

> ----Original Message----
>> From: Mark D. Baushke
>> Sent: 22 August 2005 19:06

>> Dave Korn writes:

>>>   So I guess what I really want (in order to make the whole procedure
>>> work the way I was previously expecting it to) is to use "cvs ci -f"
>>> after my very first import; that way, all the files will have the
>>> "branch" tag
>> 
>> s/"branch" tag/RCS default branch/

>> Well, any new file that is added via 'cvs import' will have the same
>> problem as you move forward.

>   I'm not sure; isn't what I want for my purposes just a quick hack to the
> server so that the "branch 1.1.1" directive is just never ever added to
> the RCS file by an import (subject to a commandline option being
> specified)? Couldn't I just let the r1.1 that you mentioned that was a
> copy of r1.1.1.1 be the base of the main trunk?

  OK, so my problem so far has been that I wanted to be working on mainline,
but there was no way to checkout a set of mainline files, because the import
command had moved some-but-not-all of the HEAD tags over to the vendor
branch.

  "cvs update -j" isn't going to help any in this situation, because
whatever kind of checkout command you run to get started, you end up with
some files from 1.x and some files from 1.1.1.x, and so whatever commits you
make attempting to resolve conflicts, some will be committed to mainline,
and some to the branch, and you still won't have a set of tags across the
mainline.  Nor is there any easy way to set a tag based on timestamps,
because unless the timestamp was that of the original import, then some of
the files would have been modified (hence HEAD would point to 1.x), and
others not.

  What I really wanted was to have all the default branches pointed back to
1.x, so that I could check out an entirely 1.x-based working directory and
either merge my updates and conflict fixes into it, or merge back to an
earlier working version (based on a timestamp).  I just wanted to
disentangle the branch from the trunk, but there was no way to refer to the
trunk any more.

  Well, rather than having to use sed to chop all the "branch:" lines out of
the repository ,v files (dangerous!), or writing a script to get the cvs log
information from each file, one-by-one, and update it back to the highest
1.x revision, the answer turns out to be much easier.

  "cvs admin -b" does exactly what I wanted: it just removes the default
branches and leaves me with a separate trunk and vendor branch.  The
documentation (at least with cvs 1.11.17) does point out that the REV
argument to the "admin -b" command is optional, but doesn't mention what
happens if you do so: the answer is that you get the most recent revision
from the trunk.  (As opposed to, for instance, the most recent revision
overall).

  Anyway, that did the trick.  After using "admin -b", I can finally check
out a working directory in which all the files have a 1.x series revision
rather than a mixture of 1.x and 1.1.1.x revisions.  From that point, I can
'-j' merge whatever changes I want across from the vendor branch - or not,
as the case may be, and I finally have two separate branches again.

  Thanks to everyone who helped me understand this problem!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....