>>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.
>
Another thought, that I'm betting you laugh at me for even suggesting :)
Don't insert the data N times. Give the user the option to say that one
or more changesets are actually the same one. In filesystem speak,
unlink a file B which is a user-confirmed duplicate of file A, and
re-create file B as a symlink to file A. Or just unlink file B without
the symlink, whichever metaphor suits you better. :)
Yes it is "altering history"... but... OTOH the user has just told
BitKeeper, in no uncertain terms, that he is altering history only to
make it more correct.
From a user interface perspective, the user would pick one of N
changeset comments to be considered the "real" one.
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/