Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik <jgarzik@mandrakesoft.com>]

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.
>

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