Linus, > That "individual patches" is one of the keywords, btw. One thing that BK > has been extremely good at, and that a lot of people have come to like > even when they didn't use BK, is how we've been maintaining a much finer- > granularity view of changes. That isn't going to go away.
Are you happy with processing patches + descriptions, one per mail? Do you have it automated to the point where processing emailed patches involves little more overhead than doing a bk pull? If so, then your mailbox (or patch queue) becomes a natural serialization point for the changes, and the need for a tool that can handle a complex graph of changes is much reduced. > In fact, one impact BK ha shad is to very fundamentally make us (and me in > particular) change how we do things. >From my point of view, the benefits that flowed from your using BK were: * Visibility into what you had accepted and committed to your repository * Lower latency of patches going into your repository * Much reduced rate of patches being dropped Those things are what have enabled us PPC developers to move away from having our own trees (with all the synchronization problems that entailed) and work directly with your tree. I don't see that it is the distinctive features of BK (such as the ability to do merges between peer repositories) that are directly responsible for producing those benefits, so I have hope that things can work just as well with some other system. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/