On Fri, 2006-10-20 at 11:48 -0700, Linus Torvalds wrote:
> Here's a real-life schenario that we hit several times with BK over the
> years:
>
> - take a real repository, and a patch that gets discussed that adds a new
> file.
> - take two different people applying that patch to their trees (or, do
> the equivalent thing, which is to just create the same filename
> independently, because the solution is obvious - and the same - to
> both developers).
> - now, have somebody merge both of those two peoples trees (eg me)
> - have the two people continue to use their trees, modifying it, and
> getting merged.
>
> Trust me, this isn't even _unlikely_. It happens. And it's a serious
> problem for a file-ID case. Why? Because you have two different file ID's
> for the same pathname.
I tried this to see what bzr would do. Here's the critical point where
the first merges are done ("a" is mainline, "b" and "c" are external
branches being merged into "a").
---
jeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../b
All changes applied successfully.
1 revision(s) pulled.
jeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../c
bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
jeff@lsblap:~/tmp/linus-file-id/a$ bzr merge ../c
Conflict adding file file2. Moved existing file to file2.moved.
1 conflicts encountered.
jeff@lsblap:~/tmp/linus-file-id/a$ bzr status
added:
file2
renamed:
file2 => file2.moved
conflicts:
Conflict adding file file2. Moved existing file to file2.moved.
pending merges:
Jeff Licquia 2006-10-20 commit c of file2
---
file2 and file2.moved have identical contents at this point. I fixed it
by deleting file2.moved, "bzr resolve file2", and committing.
After this conflict is resolved, merging from b causes conflicts, while
merging from c appears to work fine. This continues until b merges from
a (and resolves a conflict in a similar manner to a), at which time
merging/pulling works as you'd expect between the branches. Whenever b
is marked as conflicting before it merges from a, bzr preserves b's
changes by moving b's modified file.
All in all, not ideal, but it seems bzr handles this better than bk.
Certainly, bzr doesn't silently drop anyone's changes, at least. I
suspect that bzr could improve its handling of this use case, but not,
I'm sure, to Linus's specifications; some of the fun and games does seem
to come from the use of file IDs.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html