VCS comparison table

[James Henstridge]

On 26/10/06, Junio C Hamano <junkio at cox.net> wrote:
> "James Henstridge" <james at jamesh.id.au> writes:
>
> > Can you really just rely on equal revision IDs meaning you have the
> > same code though?
>
> If you two have the same commit that is a guarantee that you two
> have identical trees.  The reverse is not true as logic 101
> would teach ;-).

That was the point I was trying to make.  Carl asserted that in git
you could tell if you had the same tree as someone else based on
revision IDs, which doesn't seem to be the case all the time.

The reverse assertion (that if you have the same revision ID, you have
the same tree) seems to hold equally in git and Bazaar.


> Doing fast-forward instead of doing a "useless" merges helps
> somewhat but not in cases like two people merging the same
> branches the same way or two people applying the same patch on
> top of the same commit.  You need to compare tree object IDs for
> that.

Sure, you can do the same in Bazaar by comparing the inventories for
the two revisions.

>
> >> 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.
>
> Is it "you could assume" or "it is guaranteed"?  If former, what
> kind of corner cases could invalidate that assumption?

The merge revision will also include any manual conflict resolution.
If the other person resolved the conflicts differently.

James.