Jeeva Sarma <[EMAIL PROTECTED]> wrote:
> I have a file soa.pc, branched out at 1.2, now at
> revision 1.2.4.1 on branch, and 1.2 on trunk. I
> check-out from trunk, then do
> [ ... ]
> cvs update -j 1.2 -j 1.2.4.1 soa.pc
Yes, like that. The command means, merge all changes
that occurred between 1.2 and 1.2.4.1 into the working copy,
which is what you want.
What is confusing you is that there are *three* revisions involved:
the base of the changes to merge, here 1.2, the endpoint of the
changes to merge, here 1.2.4.1, and the working copy, which doesn't
need to be called out by revision because it is the file sitting
in your sandbox at the moment. In your case, the working copy is
identical to the base, but this isn't always true.
> RCS file:
> /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v
> retrieving revision 1.2
> retrieving revision 1.2.4.1
> Merging differences between 1.2 and 1.2.4.1 into
> soa.pc
After which the soa.pc in your sandbox should be identical
to 1.2.4.1, but once again this was a special case because
your starting point was identical to 1.2 .
> cvs update -j HEAD soa.pc
> RCS file:
> /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v
> retrieving revision 1.2
> retrieving revision 1.3
> Merging differences between 1.2 and 1.3 into soa.pc
If you omit the first "-j", it defaults to the most recent
common ancestor of the given "-j" and of the working copy.
Here HEAD means 1.3, because you or someone else committed
changes after you checked out the sandbox with 1.2 .
The common ancestor of 1.3 and 1.2 is 1.2 so once again
you end up with a special case where the base and the
working revision are identical. You are grabbing the
changes from 1.2 to 1.3 and injecting them in 1.2,
the result being identical to 1.3 .
BTW, if you lose track you can always do
rm soa.pc
cvs update soa.pc
to get a clean copy of the HEAD of the moment.
--
pa at panix dot com
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
