While there is no upside to forcing it all to _always_ happen in one
step, there are good reasons to allow it in particular cases.

The most common is if you work on something from two different computers
(at home and at work or from desktop or notebook or similar cases) and
want to be sure you don't forget to synchronize your changes.

You can always unbind the branch or do a commit --local, which allows
doing a local commit anyway (eg. when disconnected) and then the next

Again, it only is if you want, and opt for, making it so. Eg. people who
often have many terminals with different current directories may use it
to protect themselves from accidentaly running commands in the wrong

In bzr push and pull only work for the fast-forward case. They operate
on branches and actually apply the changes on the target. But that's a
different thing. Bound branches are mainly about not forgetting to

Bzr is meant to be used in both ways, depending on user's choice.
Therefore it comes with that infrastructure and you can choose whether
you want to use it or not.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>
-

[ message continues ]

On Sat, 21 Oct 2006 16:13:28 +0200

From what we've read on this thread, bzr appears to be biased towards
working with a central repo.  That is the model that supports the use of
revnos etc that the bzr folks are so fond of.   However Git is perfectly
capable of being used in any number of models, including centralized.
Git just doesn't make the mistake of training new users into using
features that are only stable in a limited number of those models.

Sean
-

[ message continues ]

This is just plain wrong.

bzr is a fully decentralized VCS. I've read this thread for quite some
time now and I really cannot understand why people come to this
conclusion.

However, if you do want to work centralized, bzr has commands that
fits that workflow really good.


/Erik

-- 
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
-

[ message continues ]

Read carefully: bzr is _biased_ towards work with central repository.
Default workflow (as for example using revnos, as for example using
"merge" for one repository and "pull" for other) of bzr is geared
towards star topology, i.e. some centralized repository.

That to be said, it is supposed to be able to work in fully decentralized
way, using revids. But then for example you don't have "simple rev
namespace" (moreover you have _worse_ namespace than git's sha1 ids).

-- 
Jakub Narebski
Poland
-

[ message continues ]

On Sat, 21 Oct 2006, Erik B
[ message continues ]

Side note: the only reason I think that distinction is worth making at all 
is when comparing git to bzr, and even then this is a fairly subtle 
distinction, and probably not a huge deal in practice.

I obviously think git is a nicer distributed design, but in the end, if 
you compare to something like CVS or SVN that isn't even disconnected, the 
difference between git and bzr in this sense is basically zero. 

So I sound like I care, but at the same time, I realize very well that 
when coming from a totally centralized world, the details we're arguing 
are _so_ not important.

			Linus
-

[ message continues ]

I have to agree. Personally I think both git, bzr and mercurial are
all VERY nice systems.  If they weren't all started about the same
time, I doubt we would have all three.

I am happy to use either, but I have a small preference with bzr
because it suites me. I'm saying this, just as a user, nothing else.

/Erik
-- 
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
-

[ message continues ]

Erik B
[ message continues ]

Yes, bzr predates Mercurial and Git; I remember talking to Martin Pool
about Bazaar-BG at the the 2005 Linux.conf.au, which was before the BK
turnoff.  At the time, I had considered using bzr-ng (which has since
been renamed bzr), but it didn't have branch functionality at that
point if I remember correctly.  Both git and Mercurial started
development at almost the same time right after the Larry McVoy
announced the pending withdrawal of the BitKeeper no-cost license.   

About one month after the announced BK turnoff date, I looked at the
various options for transitioning e2fsprogs, and at that point
Mercurial was **substantially** faster than bzr, and I believe
slightly ahead in features.  I also looked at git, but at that point
Hg was easier to learn how to use, and I figured for a project the
size of e2fsprogs, I didn't need the power of git, so I decided in
favor of Mercurial because it looked like it would be easier for
people to learn how to use it.

I think it's fair to say that the exchange in ideas have profited all
three projects, and that the different projects have different
strengths,   

						- Ted
-

[ message continues ]

> On Sat, 21 Oct 2006, Erik B
[ message continues ]

Actually bzr used to have slightly different numbering scheme not long
ago. There was a revision-history in each branch listing the revisions
in order in which they were commited or merged in. Some time ago it was
changed to numbering along the leftmost parent, which was, IIRC, deemed
simpler and a little more logical. But in the light of these arguments,
maybe the former system was better -- it was more dependent on the
actual location, but on the other hand it allowed (or could allow --
IIRC there was some problem with it) to fast-forward merge while
_locally_ keeping the meaning of old revision numbers. In fact, the
revision-history used to be almost exactly the same as git reflog,
except it only stored the revids, not the times.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>
-

[ message continues ]

Which is very fine if you don't modify the history (amending commits,
rewinding history to earlier point, rebasing the branch, merging branch
in and starting it anew aka. dovetail approach if I remember correctly),
and if you are not concerned with performance when fetching larger
number of commits into branch (as you have to assign number to them).

Which was perhaps why bzr changed from revnolog to leftmost/first parent
as a way to keep branch-as-path/assing revision numbers to revisions.
Which has it's own disadvantages as enumerated multiple times here
on the list.
-- 
Jakub Narebski
Poland
-

[ message continues ]