Re: VCS comparison table
- From
James Henstridge <james@jamesh.id.au>
- Date
- Oct 26, 2006, 08:52 UTC
- Message-ID
- <a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com>
- In-Reply-To
- <87slhcz8zh.wl%cworth@cworth.org>
On 25/10/06, Carl Worth <cworth@cworth.org> wrote:
Show 12 quoted lines
> 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.
Show 12 quoted lines
> 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.