[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: merge/diff
From: |
Eric Siegerman |
Subject: |
Re: merge/diff |
Date: |
Fri, 2 Mar 2001 23:14:51 -0500 |
User-agent: |
Mutt/1.2.5i |
On Fri, Mar 02, 2001 at 03:52:03PM -0700, Derek Scherger wrote:
> So I'm sitting here, in merge hell with one particular file that has had
> lots of cosmetic (whitespace) changes since being branched,
Been there!
I'll assume the cosmetic changes were made on the branch; if they
were on the trunk, the following will be kinda backwards, but
should still give you the general idea...
Are the cosmetic changes mechanical in nature? Ie. could you,
without too much trouble, make *exactly* corresponding changes in
the trunk? This would be the case if the file was run through
"indent", for example. If so:
- On the trunk and in your sandbox, back out the merge work
you've done so far on this file (keep a backup of course);
it'll be better if you start fresh
- Get onto the trunk: "cvs update -A"
- Make cosmetic changes on the trunk corresponding to the ones
that were made on the branch
- Use (cvs) diff to check that you got it right, ie. keep at it
until "cvs diff -rbranch" shows no or few gratuitous changes
- Commit this version ON THE TRUNK (it should differ *only*
cosmetically from the version that was there before you
started)
- Try the merge again; it should go cleaner now
Alternatively, if the cosmetic changes were committed separately
from any substantive changes, you might be able to replace the
"make cosmetic changes" step above with something like:
cvs diff -r<branch-rev-before-cosmetic-changes> \
-r<branch-rev-with-cosmetic-changes> \
-u myfile.c |
patch myfile.c
This will get you into the same state as my first recipe.
If the cosmetic changes were committed separately, but the above
doesn't work, try:
- Revert and get onto the trunk, as above
- Merge all changes from the beginning of the branch (or
previous merge point) up to BUT NOT INCLUDING the cosmetic
changes. This should go easily:
cvs diff -r<branch-point> \
-r<branch-rev-before-cosmetic-changes> \
-u myfile.c |
patch myfile.c
- Merge all changes from just after the cosmetic changes up to
the present. This will have to be done by hand, but (especially
if the cosmetic changes were recent), the work will have been reduced:
cvs diff -r<branch-rev-after-cosmetic-changes> \
-r<branch> \
-u myfile.c
apply these diffs the hard way
- now make the cosmetic changes, mechanically or manually, or
decide they were a bonehead idea in the first place and just
abandon them...
Another possibility (which falls somewhere in the middle of the
above in terms of preferability): apply patches the other way --
merge this one file *from* trunk *to* branch. This will work if
there were only a few changes on the trunk; you'll still have to
apply these changes by hand, but there'll be fewer to deal with.
You don't necessarily have to commit the results of this to the
branch; you can commit it to the trunk by:
- make the changes
- mv myfile.c myfile.c-merged
- cvs update -A // will refetch the unmodified version
- mv myfile.c-merged myfile.c // replaces that with your modified one
- cvs commit
Advice for the future: If I'm making cosmetic changes to a file
-- especially big global ones -- I find that a bit of extra
effort at the time can save a *lot* of grief later. I make a
point of isolating such changes as a separate revision, and
being sure to say "no substantive changes" in the log message
(after, of course, verifying that no substantive changes crept in
while I wasn't looking :-). Doing so:
- makes merges like this easier, since I can play games like
the ones described above
- makes "cvs diff"'s easier; instead of
cvs diff -r<old> -r<new>
which will print lots of useless stuff, I can go:
cvs diff -r<old> -r<rev-before-cosmetic-changes>
cvs diff -r<rev-with-cosmetic-changes> -r<new>
to see only the changes that actually changed anything.
(The "no substantive changes" in the log message is what
assures me that the output of:
cvs diff -r<rev-before-cosmetic-changes> \
-r<rev-with-cosmetic-changes>
will be boring.)
Good luck!
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)