Re: Adding directory and files when parent directory has stick tag.

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Pream <address@hidden> writes:

> Somebody just called on me to clean up a situation involving a branch
> from a trunk that didn't exist.  The scenario was that he had checked
> out a tagged version of a project, he then proceeded to add/commit a new
> directory and several files.  It looks like CVS created a branch but put
> it in the Attic, presumably because there was no main trunk to branch
> from.

Yup, this is the way it is supposed to work.

With cvs 1.12.x you can also get a similar result by doing a vendor-only
branch import using 'cvs import -X' as the import command. There is a
1.1 revision and a 1.1.1.1 revision just like a normal import of a new
file, but there is also a dead 1.2 revision and the ,v file is in the
Attic. (This is done for NetBSD development all the time.)

This is a very useful feature to allow independent development to be
carried out in a branch and only to merge to the trunk when your checked
out tree is working as you want it to work.

> To clean this up I went to the repo and blew away the new directory and
> its files.  Then I manually removed the Entries line pertaining to the
> new directory.

This is just a bad idea. Doing it lost a lot of work. Generally, checked
out trees that have CVS/Entries with an entry for a directory that has
gone missing just gives CVS clients a very hard time.

If you really must do something like this in future, you are better off
leaving the directories in place and only removing the ,v files. At
that, I would probably have moved them out of the way if there was some
reason you felt you had to have an active revsion 1.1 for some unknown
reason.

> CVS still didn't do what I wanted, but after some messing around with
> updates and manual hacks (yes things had gotten out of control at this
> point), I managed to get it where I wanted it.

If you say so, it must be true. I bet it was a lot of work.

> My question:  What is the PROPER way to clean up the above mess,

First, it was not a 'mess' that needed to be cleaned up at all. It was
just a way of doing concurrent development that you had not used
previously.

> resulting in the new directory and files being on the trunk instead of
> this mystery branch in the Attic and version 1.1 being in the users
> sandbox next to the rest of the project which still retains the original
> tag?

I am sorry you were confused, but had you done a

    cvs checkout -r<branch> modulename

other users would have had access to the same files that your user had
committed in their own checked out tree. This is how things are supposed
to work.

That said, if you have someone who developed sources on a branch that
had no revisions on the main trunk, someone would typically merge those
files to the main trunk using this basic approach...

  Assumption: branchtag1 is the tag used, myproj is the top-level module
              under which new directories were created...

Something like these steps were probably taken to get the tree in the
state you saw

  cvs rtag -b branchtag1 myproj
  cvs checkout -rbranchtag1 myproj
  cd myproj
  mkdir foodir && cvs add foodir && cd foodir
  echo hello > hello.txt
  cvs add hello.txt && cvs commit -m'new file on branch only' hello.txt
  ... add other files as desired ...

Now, if they have completed their development and are happy with the
results, all that remains is to merge the branch sources back into the
main trunk...
  
  : now it is time to merge the branchtag1 files into the main trunk
  cvs checkout myproj
  cd myproj
  ... make sure that you do NOT have a -P switch in your ~/.cvsrc file
  cvs update -d -j branchtag1
  ... make sure everything looks good ...
  cvs commit -m'merge branchtag1 back into the main trunk'

At this point, there will still be a dead 1.1 revision, and a living
1.1.0.2 magic branch with 1.1.2.x revisions on it AND revsion 1.2 should
look a lot like revision 1.1.2.x found on mybranch1 for the hello.txt
file.

I hope this answers your questions.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFFsEV4Cg7APGsDnFERAi+VAJ9wlp28WQ9R5tHoO9iEQkitrmZsXgCgxtHm
/MdYj0jboNrXlhtUYMi+EOk=
=/x5n
-----END PGP SIGNATURE-----