<br><br><div class="gmail_quote">On Thu, Apr 19, 2012 at 10:24 AM, Jeff Licquia <span dir="ltr"><<a href="mailto:licquia@linuxfoundation.org" target="_blank">licquia@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/18/2012 05:56 PM, Craig Scott wrote:<br>
> Using bzr instead of svn or git was definitely a negative for me that<br>
> discouraged me from exploring any further. If you aren't using a tool<br>
> used by the majority, then the majority won't be inclined to get<br>
> involved. ;) Just my $0.02<br>
<br>
It's worth noting that, at the time the decision was made, bzr looked a<br>
lot more mature than git. There was even a data-corruption bug in git<br>
around 2006 or so.<br>
<br>
Of course, times change. Converting between any of the distributed VCS<br>
systems is basically tedious: convert the repos, publish the repos,<br>
update our infrastructure to use the new repos, that sort of thing.<br>
They all ultimately have the same data model underneath.<br>
<br>
The other thing that makes me hesitate, though, is that bzr is<br>
considered a lot easier to use than git. Maybe that's not a factor<br>
anymore, since everyone's doing git.</blockquote><div><br></div><div><br></div><div>complaining is not the same as demanding a lot of effort be put in</div><div>to switch things over!</div><div><br></div><div><br></div>
<div>it's supposed to be possible to have a certain amount of</div><div>coexistence, although I note that the bzr-git plugin actually</div><div>shows off one of the really irritating things about bzr: it has</div><div>
a plugin architecture, but plugin versioning is dicey, so unless</div><div>everything is distro-packaged, it's likely to fail. The bzr-git</div><div>plugin I can only check out from the repository, and that gets</div>
<div>me a version too-new / possibly-incompatible-with my bzr</div><div>(and thus, refuses to run)</div><div><br></div><div><br></div><div>usability: the fact that git is so widespread now means there</div><div>are some really good tutorials; books even (some of which</div>
<div>you have to pay for), while bzr continues to have some pretty</div><div>obscure aspects which may be documented in design notes</div><div>written in future-tense, and turning over more rocks may lead</div><div>to a response like "this isn't fully integrated, so we didn't</div>
<div>want to document it"... usually these features are ones grafted</div><div>on to respond what git users are already used to, that don't</div><div>fit well onto the bzr design. That's not entirely bzr's fault, but </div>
<div>reflective of life as "not the #1 dvcs now".</div><div><br></div><div><br></div><div>it's awfully easy to do simple stuff with bzr, granted.</div><div>git wants one more step for the easy stuff (the transition</div>
<div>changed -> staged -> committed vs changed -> committed).</div><div>the problem is when it gets complex, bzr has a lot of flexibility</div><div>but just doesn't seem very easy to use any longer. the model</div>
<div>seems to be, whatever your workflow, bzr can handle it, but</div><div>there's a cost in supporting 2^37 different workflows... (just</div><div>my jaded opinions)</div><div><br></div><div><br></div>
</div>