Re: VCS comparison table
- From
Andreas Ericsson <ae@op5.se>
- Date
- Oct 26, 2006, 09:50 UTC
- Message-ID
- <454084EE.90006@op5.se>
- In-Reply-To
- <a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com>
James Henstridge wrote:
Show 17 quoted lines
> On 25/10/06, Carl Worth <cworth@cworth.org> 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? >
Yes. Because each commit contains parent revision id's, which in turn contain *their* parent revision id's, which in turn..., you know you have exactly the same revision, code, and history leading up to that revision. You may have other revisions on top or on other branches, but all commits, including merge-points and whatnot, leading to that particular revision id are EXACTLY identical.
Show 9 quoted lines
> 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. >
Merges preserve author and commit info. You may need to create a new branch (a git branch, the cheap kind which is a 41-byte file) and fetch "his" into "yours". This will be very cheap if you both have the same code but not the same history, as everything but a few commit-objects will be shared. A more likely scenario though is this;
Bob writes a feature that doesn't work as per spec. He doesn't know why. He asks Alice to have a look, so he communicates the commits to her by "please pull this branch from here", or by sending patches and telling Alice the branch-point revision to apply them to. Alice creates the "bobs-bugs/nr1232" at the branch-point and fetches Bobs branch into that or applies the patches on top of that (in the fetch scenario she wouldn't need to know the branch point, since git would figure this out for her). She knows this should create a revision named 00123989aaddeddad39, so if it doesn't, she doesn't have the same code.
I imagine this works roughly the same in bazaar, although the original case where tests have already been done and the testers wanted to know if they had the exact same revision Just Works in git.
Show 9 quoted lines
> >> 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. >
"assume" != "know", or was that just sloppy phrasing?
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se