VCS comparison table

[David Lang]

On Mon, 23 Oct 2006, Matthew D. Fuller wrote:

> But I don't understand how bzr-the-abstract-data-model makes such
> things impossible, or even significantly different than doing so in
> git.  In git, you're just chopping off one DAG where another one
> intersects it (or similar operations).  To do it in bzr, you'd do...
> exactly the same thing.  The revnos, or the mainline, are completely
> useless in such an operation of course, but they don't hurt it; the
> tool would just just ignore them like it does the SHA-1 of files in
> the revision.

one key difference is that with bzr you have to do this chopping by creating the 
branches at the time changes are done, with git you do this chopping after the 
fact when you are displaying the results.

As such you can chop and compare things in ways that were never contemplated by 
anyone at the time changes are made.

>
>> See? When you visualize multiple branches together, HAVING
>> PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid
>> and interesting operation to do.
>
> I wouldn't be so absolutist about it, but certainly they're of
> extremely limited utility if of any at all in such cases.  And yes, it
> can be an interesting operation.  But what does that have to do with
> using revnos in other cases?  You keep saying "having" where I would
> say "using".

and the bzr tools strongly encourage the use of these numbers

> I care about that first parent line.  Therefore, I require my tool to
> at least _pretend_ to care.  I'm not aware of any way in which the
> fundamental bzr structures care, but the UI is chock full of
> pretending.  A necessary part of that pretending is not changing my
> mainline unless I specifically ask for it, and that means a
> merge-vs-pull distinction needs to be there.  That's a _technical_
> sign that the tool is ready to work with me the way I want to work.  A
> lack of it is a _technical_ sign that it's not suitable.

nobody is saying that the bzr approach is invalid for your workflow.

what people are saying is that it doesn't easily support a truely distributed 
workflow. this is a very different statement.

your workflow isn't truely distributed so you bzr's model works well for you. no 
problem, just don't claim that becouse you haven't run into any problems with 
your workflow that there are no problems with bzr with other workflows.

David Lang