[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [PATCH] Re: bazaar bug #385 (Re: Stabilizing Bazaar
From: |
Matthieu Moy |
Subject: |
[Gnu-arch-users] Re: [PATCH] Re: bazaar bug #385 (Re: Stabilizing Bazaar?) |
Date: |
Thu, 07 Jul 2005 00:54:17 +0200 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) |
Robert Widhopf-Fenk <address@hidden> writes:
> Merging from archive A must NOT require access to archive B.
If the common ancestor is in B, then, it could hardly do otherwise.
Perhaps baz has just been too greedy when computing the ancestry. Then
it is a bug, but note that it is due to the migration from tla to
bazaar. For a native baz project, the ancestry is pre-computed.
> While baz might use B to find a better merge point/strategy
> it must not require access to B, since this effectively prevents
> merging from A when B is gone.
Not exactly. It prevents you from using the "merge" command, but you
still have apply-delta and replay.
> Baz should give a warning (about suboptimal merging?), but
> it still should be able to merge from A.
I'm not familiar enough with the merge algorithm to give a firm
answer, but I think "suboptimal" is not the word here: If you don't
have the common ancestor, you can't apply the traditional merge
algorithm.
> Tla is able to do so
last time I checked, tla's star-merge command was only looking at the
current version. If the common ancestor was beyond that, then tla
stopped with a "unrelated trees" or stg like this, so, it was not even
trying to build the common ancestor. So, bazaar may not be able to do
as much as it should, but it does more than tla in this case.
--
Matthieu
[Gnu-arch-users] Re: [PATCH] Re: bazaar bug #385 (Re: Stabilizing Bazaar?), Matthieu Moy, 2005/07/09