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].
B: Yes, so use revids there.
G: So use revids everywhere.
B: Revnos are handier tools for [situation] and [situation] for
[reason] and [reason].
*brrrrrrrrrrrrrrrrip!!!* *skip back to start*
I'm not sure there's any unturned stone left along this line, so I'm
not sure how productive it really is to keep walking down it. So, to
make something productive of it, I'm going to put it onto my todo list
to spend some time with bzr trying to use revids for stuff. I'm
fairly certain that, due to the bzr cultural tendancy to use revnos
where possible, there are some rough edges in the UI when using revids
that should be filed down (though I think it much less likely to turn
up underlying model failures that interfere with using revids).
> 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.
> 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.
> (and I'd be interested to see a "corrected" version of the commands
> above to fix the storage inefficiencies).
The 'corrected' step would be:
> mkdir bzrtest; cd bzrtest
bzr init-repo .
> mkdir master; cd master; bzr init
Then all branches stored under that 'bzrtest' dir will use the
bzrtest/.bzr/ dir for storing the revisions, and shared revisions will
only exist once saving the space/time for multiple copies.
Probably, you'd actually want 'init-repo --trees' in this case,
because repos default to being [working]tree-less. In a tree-less
setup, you'd create a [lightweight] checkout of the branch(es) you
wanted to work on elsewhere, giving you a layout much like CVS or SVN
where "my VCS files are THERE, my working tree is HERE".
> (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.
--
Matthew Fuller (MF4839) | fullermd@xxxxxxxxxxxxxxx
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
-
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