On Tue, 24 Oct 2006, Matthew D. Fuller wrote:
On Tue, Oct 24, 2006 at 11:03:20AM -0700 I heard the voice of
David Lang, and lo! it spake thus:
it sounded like you were saying that the way to get the slices of
the DAG was to use branches in bzr. [...]
I'm not entirely sure I understand what you mean here, but I think
you're saying "Nobody's written the code in bzr to show arbitrary
slices of the DAG", which is true TTBOMK.
I think we are talking past each other here.
what I think was said was
G 'one feature of git is that you can view arbatrary slices trivially'
B 'bzr can do this too, you just use branches to define the slices'
G 'but this limits you becouse branches are defined as code is developed, git
lets you define slices at viewing time'
by the way, I think it's more then just saying 'well, the code could be written
to do this in $VCS' some decisions and standard ways of doing things can impact
how hard it is to implement a feature, and some decisions can make it
impossible (without doing unexpected things).
everyone agrees that bzr supports the Star topology. Most people
(including bzr people) seem to agree that currently bzr does not
support the Distributed topology.
I think this statement arouses so much grumbling because (a) bzr does
support such a lot better than often seems implied, (b) where it
doesn't, the changes needed to do so are relatively minor (often
merely cosmetic), and (c) disagreement over whether some of the
qualifications included for 'distributed' are really fundamental.
it's just fine for bzr to not support all possible topologies,
I think there's a real intent for bzr TO support at least all common
topologies. I'll buy that current development has focused more on
[relatively] simple topologies than the more wildly complex ones. I
look forward to more addressing of the less common cases as the tool
matures, and I think a lot of this thread will be good material to
work with as that happens. It's just the suggestion that providing
fruit for simple topologies _necessarily_ prejudices against complex
ones that I find so onerous.
one concern that the git people are voicing is that the things that work for
simple topologies (revno's) can't be used with the more complex ones (where you
need the refid's). especially the fact that users need to do things
significantly different when there are fairly subtle changes to the topology.
the scenerio that came up elsewhere today where you have
Master
/ \
dev1 dev2
and then dev1 and dev2 both start working on the same thing (without knowing
it), then discover they are working on the same thing. they now have threeB
options
1. merge their stuff up to the master so that they can both pull it down.
but this puts broken, experimental stuff up in the master
2. declare one of the dev trees to be the master
this changes the topology to
Master--dev1--dev2
3. pull from each other frequently to keep in sync.
this changes the topology to
Master
/ \
dev1--dev2
if they do this with bzr then the revno's break, they each get extra commits
showing up (so they can never show the same history).
in git this is a non-issue, they can pull back and forth and the only new
history to show up will be changes.
this is the situation that the kernel developers are in frequently. it sounds as
if you haven't needed to do this yet, so you haven't encountered the problems.
David Lang
-
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