[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Problems using new Linux-2.4 bitkeeper repository.
    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
    >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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.023 / U:7.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site