Larry McVoy wrote:
>>I think a fair question would be, is this scenario going to occur often?
>> I don't know. But I'll bet you -will- see it come up again in kernel
>>development. Why? We are exercising the distributed nature of the
>>BitKeeper system. The system currently punishes Joe in Alaska and
>>Mikhail in Russia if they independently apply the same GNU patch, and
>>then later on wind up attempting to converge trees.
>>
>
>Indeed. So speak in file systems, because a BK package is basically a file
>system, with multiple distributed instances, all of which may be out of
>sync. The problems show up when the same patch is applied N times and
>then comes together. The inodes collide. Right now, you think that's
>the problem, and want BK to fix it. We can fix that. But that's not
>the real problem. The real problem is N sets of diffs being applied
>and then merged. The revision history ends up with the data inserted N
>times.
>
>I'm not sure what to do about it. I can handle the duplicate inode case
>more gracefully but it's a heavy duty rewack.
>
Hence my suggestion for a short term solution that's immediately useful
-- allowing some way to answer "local changes take precedence 100% of
the time" or "remote changes ..." with a single command. That was my
hack solution that I thought would people might find useful when stuck
with the duplicate-patch situation.
In the command line merge tool, when merging a file-create, "rla" would
cause the current file conflict, and all future file-create conflicts,
to be "won" by the remote side -- essentially creating the effect of
typing "rl" 300 times.
Apply similar logic to the file-rename merge case. I think the merge
command I used in 100% of the cases, during that merge, was 'r'.
If you are stuck with the duplicate patch case, as happened here, I just
want to see the pain eased a bit :) IMO you can put off the hard
problem if you make the UI a bit better.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:12 EST