Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
> >
> > The entire discussion is about how to name things in a distributed
> > system.
>
> I think we're getting into scratched-record-mode on this.
>
>
> Git: Revnos aren't globally unique or persistent.
>
> Bzr: Yes, we know.
>
> G: Therefore they're useless.
>
> B: No, they're very useful in [situation] and [situation], and we deal
> with [situation] all the time, and they work great for that.
>
> G: But they fall apart totally in [situation].
G: But revnos force centralized/star-topology development. And even in
[situation] have [disadvantages].
> B: Yes, so use revids there.
>
> G: So use revids everywhere.
>
> B: Revnos are handier tools for [situation] and [situation] for
> [reason] and [reason].
G: Shortened sha1 commit-ids are almost as handy.
> *brrrrrrrrrrrrrrrrip!!!* *skip back to start*
There _are_ terminology conflicts. For example bzr "branch" is roughly
equivalent to one-branch git "repository"; bzr "repository" is just
collection of branches sharing common storage, which is similar to set
of git "repositories" with .git/objects/ linked to common object
repository (storage area) or appropriately set alternates file
(although that is not common usage in git, and for example you would
have to be carefull with running git-prune); bzr "lightweight checkout"
is equivalent to nonexistent "lazy clone"/"remote alternates" discussed
on git mailing list but not implemented because of performance
concerns; bzr "normal checkout" is I think similar to git "shared
clone" (but shared clone is limited to repositories on the same
filesystem); bzr "heavyweight checkout" is roughly equivalent to
one-branch-only "clone" in git or cg (cg = Cogito).
And there are differences in opinion. For example "simple namespace for
revisions" which is important for bzr, is superficially simple for git
(as it works only for centralized approach, and for leaf repositories
you have to have access to central repository to get final revnos); on
the other hand "not simpleness" of git's sha1 identifiers is not that
complicated in everydays work, as one usually use branch and tag names,
<ref>~<n> and <ref1>..<ref2> syntax, sometimes shortened sha1 names and
full sha1 names only rarely. For bzr it is more important to tell from
revno which commit on branch was earlier, for git it is more important
that commitids never ever change; we can use git commands to check
which commit was earlier. For bzr plugins are important, for git it is
important to be easy to add new commands, using scripts for fast
prototyping.
> > It may be that the centralization bias
>
> I think it's more accurately describable as a branch-identity bias.
> The git claim seems to be that the two statements are identical, but I
> have some trouble swallowing that.
When two clones of the same repository (in git terminology), or two
"branches" (in bzr terminology), used by different people, cannot be
totally equivalent that is centralization bias. By equivalent I mean
that "old history" is exactly the same (the same diagram, the same
identifiers - make it usually used identifiers).
The fact that you have two different commands, "merge" vs "pull"
for using in one mother/mainline "branch" vs other "branches" tells
us that there is bias towards centralization.
> > I'm still not sure exactly what a bzr branch is, but it's clearly
> > something different from a git branch,
>
> The term is somewhat overloaded, which is why it's causing you trouble
> (and did me). It refers both to the conceptual entity ("a line of
> development" roughly, much like what 'branch' means in git and VCS in
> general), and to the physical location (directory, URL) where that
> branch is stored, and where it'll often have a working tree. Branches
> are always referred to by location, never by name.
I'd rather use other name then. Perhaps "forks" for physical "branch",
i.e. branch metadata (like revno to revid mapping) + object repository
or pointer to it + optionally working area/working files.
[...]
> > (since pull seems the only way to synch up without infinite new
> > merge commits being added back and forth).
>
> The infinite-merge-commits case doesn't happen in bzr-land because we
> generally don't merge other branches except when the branch owner says
> "Hey, I've got something for you to merge". If you were to setup a
> script to merge two branches back and forth until they were 'equal',
> yes, it'd churn away until you filled up your disk with the N bytes of
> metadata every new revision uses up.
And you say that bzr is not biased towards centralization? In git you
can just pull (fetch) to check if there were any changes, and if there
were not you don't get useless marker-merges.
Take for example two simple git scenarios:
1. Single branch repository. We have two clones of the same repository,
both with only one branch, 'master', both working on this branch, and
both considered equal. If only one person worked on branch, "pull"
would result in fast-forward. If both worked on branch, "pull" would
result in merge. This is the "diamond" example by Pasky, which
explained why git doesn't treat first parent like special - because of
fast forward. Bzr treats first parent/mainline/"the branch" special
therefore it generates superficial merge commits if we preserve revnos;
BTW doesn't "pull" clobber your changes?
2. But the preferred git workflow is to have two branches in each of two
clones. The 'origin' branch where you fetch changes from other
repository (so called "tracking branch") and you don't commit your
changes to (by convention, as git doesn't protect the branch from
commiting to, although it would refuse to fetch in non fast-forward
case unless forced). You put your work in the 'master' branch, and you
merge 'origin' branch into 'master'. This allows for example fetching
changes to 'origin' but _not_ merging them immediately into 'master',
for example if you are in the middle of some larger work byt want to
check what other side did to not to create conflict if not neccessary.
--
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