Greg Hudson <ghudson@MIT.EDU> writes:
> On Mon, 2005-06-27 at 11:52 -0500, sussman@tigris.org wrote:
> > + It seems that in the case of lines of text, our current diff3
> > + ignores text-bases completely, possibly overwriting local mods.
>
> Can you explain how this could result in overwriting local mods?
I think this is what Ben meant.
Let's identify changes with letters. Deep down we all know they refer
to lines of text, but this shorthand should suffice.
The change coming from the Meanwhile, in the working copy,
repository transforms [A] a local modification has changed
to [C]: [Q] to [A]:
[A] [Q]
| |
| |
V V
[C] [A]
Okay, so what happens when you merge the repository change on the left
into the working copy on the right? The working copy already has the
diff [Q->A] present as a local mod. The diff coming from the
repository can do [A->C]. Since it finds [A] in the working file, it
applies the diff, resulting in [C].
So now the working copy has a local mod [Q->C]. Yet if you revert it,
you don't go back to the original local mod, [Q->A]. Instead, you go
back to just [Q]! The original local mod is "lost".
Philip Martin, I believe, pointed out that we depend on this behavior
when merging multi-revision changes from the STATUS file into a
release branch. Each revision usually depends on changes introduced
by merging the previous revisions. Only when all the changes have
been merged do we commit; until then they are local mods -- or rather,
a single local mod that happens to have been produced piece by piece.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 02:39:59 2005