[prog] CVS travails, and strategies

[John Clarke]

Hi Michelle,

I know you wrote this a week ago, but I've only just come across it in
the archives.  I hope I'm not too late to help.

> OK, first the sordid story, at risk of exposing my lameness as a CVS
> user:

Not lameness, at worst it's inexperience, but CVS does make it easy to
make mistakes.  I think everyone who uses CVS has done something really
stupid *at least* once.  *Especially* if playing with branches :-(

> committed the changes before I checked to make sure that they were 
> truly what I wanted. They weren't.

You can undo the last change to a file with:

    cvs update -j latest_rev -j previous_rev file

The only problem is that you need to do this individually for each file
with the appropriate revision numbers (consider it as punishment for
making the mistake ;-)).  What it does is to merge the difference
between latest_rev and previous_rev into file, which just reverses the
change from previous_rev to latest_rev (you can actually use this to
remove any change or series of changes - just substitute the
appropriate revision numbers in the update command).

> anyway. So I made a new head sandbox, and used the command cvs update -j
> branchname -D some_time_ago, which merged my branch features with my
> trunk in the new sandbox. Worked almost perfectly, although it wiped out
> some of the trunk bugfixes. Obviously, I don't grok merging yet - this
> isn't making sense to me. 

You undid some arbitrary number of days of work, which included some
changes you wanted to keep.  You appear to understand merging well
enough, but in this case you just needed a finer level of control over
which changes you reversed.

> Now here's the problem. The changed files all have sticky dates (I guess
> because of the cvs update I'd done earlier).

Whenever you check out with "-r" or "-D", CVS stores the revision or
tag associated with that checkout in the file CVS/Entries, and any
further operations on that file use this "sticky" tag.

> repository. There are still two files that are stubbornly keeping their
> sticky dates, so I can't do the commit. There is no reason I can see why
> they should still have them. 

This is why:

> These are files that were in the branch, but not in the trunk. 

Because they don't exist in the trunk, they need to be merged from the
branch (or added as new files).  Merging from the branch is probably
the better way to do it, and the simplest way to do that is to checkout
a clean copy of the trunk in a temporary directory then merge the new
files across from the branch with:

    cvs update -j branch_tag file
    cvs ci -m "Merged from xxx branch" file

> Now to the philosophy question - Is it better (easier) to use the trunk
> for bugfixes, or the branch? I'm getting the impression that merging

I've always considered the trunk to be unstable and created branches
for bugfixes to releases.  If the trunk is under active development by
several people, I'll usually create a stable branch some time prior to
a release.  Sometimes I'll use a branch for development too, but that's
sort of a "really unstable" version that's not going to see the light
of day for a long time (and then it'll be merged back into the trunk, a
horribly painful exercise).

> files isn't anywhere near as automagically nice as I must have thought,

CVS and merging mostly works, but it can bite you if you're not careful.
I don't usually let CVS do the merge from a branch which is radically
different from the trunk because there's a danger that it'll get it
wrong.  I also make sure to review and build and test the code before
committing the result of a merge.

> Anyway, any comments/help/advice is appreciated.

I wrote a CVS tutorial a while ago as a simple introduction for new
users, which includes a brief discussion of branches and merging.  If
you're interested, you can find it at:

    http://kirriwa.net/john/cvs/tutorial.html


I hope I've helped a little.  Feel free to ask if anything I've said
doesn't make sense or there's anything else I can help with.


Cheers,

John
-- 
whois !JC774-AU at whois.aunic.net
GPG key id: 0xD59C360F
http://kirriwa.net/john/