On Mon, Oct 23, 2006 David Clymer wrote:
> On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:
>> David Clymer wrote:
>>> 2. bzr does not support fully distributed development because revnos
>>> "don't work" as stated in #1.
>>
>> Bazaar is biased towards centralized/star-topology development if we
>> want to use revnos. In fully distributed configuration there is no
>> "simple namespace".
>
> So revnos aren't globally meaningful in fully distributed settings. So
> what? I don't see how this translates into bias. There is a lot of
> functionality provided by bazaar that doesn't really apply to my use
> case, but it doesn't mean that it is indicative of some bias in bazaar.
First, bzr is biased towards using revnos: bzr commands uses revnos
by default to provide revision (you have to use revid: prefix/operator
to use revision identifiers), bzr commands outputs revids only when
requested, examples of usage uses revision numbers.
In order to use revnos as _global_ identifiers in distributed development,
you need central "branch", mainline, to provide those revnos. You have
either to have access to this "revno server" and refer to revisions by
"revno server" URL and revision number, or designate one branch as holding
revision numbers ("revno server") and preserve revnos on "revno server"
by using bzr "merge", while copying revnos when fetching by using bzr "pull"
for leaf branches. In short: for revnos to be global identifiers you need
star-topology.
Even if you use revnos only locally, you need to know which revisions are
"yours", i.e. beside branch as DAG of history of given revision you need
"ordered series of revisions" (to quote Bazaar-NG wiki Glossary), or path
through this diagram from given revision to one of the roots (initial,
parentless revisions). Because bzr does that by preserving mentioned path
as first-parent path (treating first parent specially), i.e. storing local
information in a DAG (which is shared), to preserve revnos you need to
use "merge" instead of "pull", which means that you get empty-merge in
clearly fast-forward case. This means "local changes bias", which some
might take as not being fully distributed.
Sidenote 1: Why Bazaar-NG tries to store "branch as ordered series
of revisions"/"branch as path through revisions DAG" in DAG instead
of storing it separately (like reflog stores history of tip of branch,
which is roughly equivalent of "branch as path" in bzr). It needs
some kind of cache of mapping from revno to the revision itself anyway
(unless performance doesn't matter for bzr developers ;-)! All what
left is to propagate this mapping on "pull"...
Sidenote 2: "Fringe" developer using default git configuration of
'origin' branch tracking 'master' branch in cloned (mainline) repo,
and 'master' branch on which he/she does his/her own work, who committed
at least single revision on his/her 'master' branch, and whose changes
are never pulled and if they get into mainline repo it is using "side"
channel like git-enchanced patches sent to project mailing list,
will see the picture similar to the bzr branch which uses "merge".
The whole discussion about validity of revision numbers started
with "simple namespace" feature in SCM comparison matrix on Bazaar-NG
wiki...
--
Jakub Narebski
Poland
-
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