Confirm, emeritus
792
edits
Changes
no edit summary
== Dealing with conflicts ==
=== Conflicts when committing to CVS ===
The safest way to ensure that there are no conflicts before committing to CVS is to update your CVS trees immediately before, and do any merging necessary. However, sometimes someone else gets a commit in before you. So, we have:
% cvs commit -m "..." foo
cvs server: Up-to-date check failed for `foo'!
You have two options at this point:
* go back and do a CVS update first:
hg update 255 <i>the rev num before the current one; there's no shorthand yet</i>
Then follow the instructions for updating from CVS, and try committing again.
* manually <tt>cvs update foo</tt> and hope for the best:
% cvs update foo
M foo
% cvs commit -m "new foo" foo
% hg commit -m "cvs sync" foo
Note the final <tt>hg commit</tt> -- you made a change to the working dir that hg doesn't know about yet, so you need to make sure that it's recorded. At this point you should do a full CVS update as well.
=== Conflicts when updating from CVS ===
Ideally you'll never run into this if you're using MQ to manage your patches, because you will always have removed all the patches from your queue before pulling from the CVS repository into your cloned working repository.
However, sometimes you will end up with a situation where you have multiple heads in your working repo, and you need to do something about it. There are a few options; I won't go into too much detail, but here they are:
* <tt>hg merge</tt>, clean up conflicts, <tt>hg commit</tt> and carry on. This works, but the downside is that this potentially leaves your un-CVS-committed patch (your changeset) in a somewhat messy state that will be hard to submit for reviews (because it may not be against the latest CVS code) and will be impossible to modify (because it's already in the revision stream)
* <tt>hg update tip</tt> to jump to the latest tip that you just pulled from the CVS repo, and then use the transplant extension to move your patch(es) over from previous change sets. e.g. <tt>hg transplant 255</tt> to take changeset 255 and apply it to the current working dir. Transplanting in this way is very similar to <tt>hg export 255 > foo.patch</tt> followed by a <tt>patch -p1 < foo.patch</tt>, <tt>hg commit -m "orig commit message"</tt>, except that it will stop and ask you to fix up conflicts.
