On 25/10/06, Carl Worth <cworth@xxxxxxxxxx> wrote:
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.
Can you really just rely on equal revision IDs meaning you have the
same code though?
Lets say that I clone your git repository, and then we both merge the
same diverged branch. Will our head revision IDs match? From a quick
look at the logs of cairo, it seems that the commits generated for
such a merge include the date and author, so the two commits would
have different SHA1 sums (and hence different revision IDs).
So I'd have a revision you don't have and vice versa, even though the
trees are identical.
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).
Or run "bzr missing". If the sole missing revision is a merge (and
not the revisions introduced by the merge), you could assume that you
have the same tree state.
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.)
Why does it matter if they create a new revision? They can still tell
if they've got all the history you had.
James.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html