[lsb-discuss] bzr vs. git (was Re: Unofficial LSB conference call minutes (2012-04-18, 11 to noon))

[Wichmann, Mats D]

On Thu, Apr 19, 2012 at 10:24 AM, Jeff Licquia
<licquia at linuxfoundation.org>wrote:

> On 04/18/2012 05:56 PM, Craig Scott wrote:
> > Using bzr instead of svn or git was definitely a negative for me that
> > discouraged me from exploring any further. If you aren't using a tool
> > used by the majority, then the majority won't be inclined to get
> > involved. ;)  Just my $0.02
>
> It's worth noting that, at the time the decision was made, bzr looked a
> lot more mature than git.  There was even a data-corruption bug in git
> around 2006 or so.
>
> Of course, times change.  Converting between any of the distributed VCS
> systems is basically tedious: convert the repos, publish the repos,
> update our infrastructure to use the new repos, that sort of thing.
> They all ultimately have the same data model underneath.
>
> The other thing that makes me hesitate, though, is that bzr is
> considered a lot easier to use than git.  Maybe that's not a factor
> anymore, since everyone's doing git.



complaining is not the same as demanding a lot of effort be put in
to switch things over!


it's supposed to be possible to have a certain amount of
coexistence, although I note that the bzr-git plugin actually
shows off one of the really irritating things about bzr: it has
a plugin architecture, but plugin versioning is dicey, so unless
everything is distro-packaged, it's likely to fail.  The bzr-git
plugin I can only check out from the repository, and that gets
me a version too-new / possibly-incompatible-with my bzr
(and thus, refuses to run)


usability: the fact that git is so widespread now means there
are some really good tutorials; books even (some of which
you have to pay for), while bzr continues to have some pretty
obscure aspects which may be documented in design notes
written in future-tense, and turning over more rocks may lead
to a response like "this isn't fully integrated, so we didn't
want to document it"... usually these features are ones grafted
on to respond what git users are already used to, that don't
fit well onto the bzr design. That's not entirely bzr's fault, but
reflective of life as "not the #1 dvcs now".


it's awfully easy to do simple stuff with bzr, granted.
git wants one more step for the easy stuff (the transition
changed -> staged -> committed vs changed -> committed).
the problem is when it gets complex, bzr has a lot of flexibility
but just doesn't seem very easy to use any longer.  the model
seems to be, whatever your workflow, bzr can handle it, but
there's a cost in supporting 2^37 different workflows... (just
my jaded opinions)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120419/e42fda22/attachment.html>