On Wed, 25 Oct 2006 18:08:22 +0800, "James Henstridge" wrote: > If there aren't, or you made the merge by mistake, you can make a call > to "bzr revert" to clean things up without ever having created a new > revision. One result of this approach is that developers of different trees don't necessarily have common revision IDs to compare. Imagine a question like: When you ran that test did you have the same code I've got? In git, the answer would be determined by comparing revision IDs. In bzr, the only answer I'm hearing is attempting a merge to see if it introduces any changes. (I'm deliberately avoiding "pull" since we're talking about distributed cases here). And to comment on something mentioned earlier in the thread, there's no need for "wildly complex" distributed scenarios. All of these issues are present with developers working together as peers, (and each considering their own repository as canonical). A harder question (for bzr) is: Do you have all of the history I've got? (The problem being that when one developer is missing some history and merges it in, she necessarily creates new history, so there's never a stable point for both sides to agree on.) -Carl
Attachment:
pgpVt8zBuBXY2.pgp
Description: PGP signature