question on difference between bazaar and subversion

[Jordan Mantha]

{snipage}
> What has always concerned me about bzr is the idea (which may easily be
> erroneous) that a decentralised system requires specific individuals to
> review and merge changes from other team members.

Here is a snippet from a conversation on #bzr:

< neuralis> in the distributed model, there's commonly one release
branch, and whoever owns it (usually the project administrator) is the
one in charge of merging from contributor branches into his branch.
< neuralis> you can automate this by having a PQM bot, which can take
gpg-signed patches and commit them into a branch without human
involvement, after access verification.

> This wouldn't be a problem if the project had 2
> contributors, but where there are 20, all working on the same thing, it
> might get complicated: if specific individuals have to take
> responsibility for merging people's branches on specific documents, then
> the consequence will be fragmentation, which would potentially harm the
> project.

This could be, I'm just not sure.

> If bzr has the tools to fit *our* workflow, then I am certainly prepared
> to consider moving seriously. However, if moving to bzr means that we
> have to adapt our workflow to fit *it*, then I worry that we will have a
> problem.

It might be adapting ourselves to fit a better workflow. Bug again, I
don't know that we will know until we try it.

> = New contributors =
>
> Is bzr going to facilitate contribution, or the reverse? Specifically:
>
> 1. Is bzr easier to learn than svn for newcomers?

probably depends on if you have a "central repo" mindset or
"distributed" mindset going into it. I started learning both at the
same time. I found them basically equally easy to learn/use. The only
thing that might be in svn's favor is that, at this point, more people
know svn than bzr and there is more documentation on svn out there.
However, I'm not sure people really need a lot of documentation for
the stuff we are doing.

> 2. Does bzr impose more or fewer requirements on newcomers (in
> particular, do they need to run a service like sshd or httpd)

At this point you need access to webspace or sftp (ssh). Note that the
webspace doesn't mean you have to be running httpd, you just need a
place hold your repo. If people don't have webspace or sftp then they
would have to send diffs, as now. If we were to move to bzr I would
suggest giving an account on doc.ubuntu.com to all doc team members so
the at least have webspace and there is also the potential (good or
bad, I'm not sure)  of people grabbing specific branches ("I'd like to
see what jjesse is up to", for instance).

> = Our workload =
>
> Is bzr going to facilitate our workload? Specifically:
>
> 1. Can we push easily and immediately to a central server (bearing in
> mind that lots of people frequently contribute small things)

I think so, see above. One person would be the admin, but commits are
done automatically.

> 2. Does it make reviewing other people's contributions easier or more
> difficult?

This I'm just not sure of. You can merge from someone else's branch
and then look at the changes with bzr diff. One advantage is that this
can be done without sending an email attachment, you could collect
diffs from several people and commit (or revert) them locally before
pushing them to the "central repo".

> 3. Does it merge docbook xml nicely?

Have no idea, I would imagine so, but we would have to test it.

> 4. Is a decentralised version control system going to suit our workload,
> bearing in mind what I said above about the large number-volunteer based
> contributor-base?

I think it might. I'm certainly no bzr (or svn for that matter)
expert, but I think we can basically get the best of both worlds
(central repo, and distributed) with bzr. I imagine doc team members
interacting with the main branch in a "central repo" way while
interacting with contributors (and contributors interacting with each
other) in a more distributed way. I think the current workflow is a
bit difficult for non-docteam members. I think that allowing
contributors to interact with each other more and with doc team leads
might make the workflow more efficient and inclusive. But at this
point, it is only my imagination. Maybe nobody would like it. It might
require a little more work on part of the doc leads, but I was doing
this anyway for the packaging guide via email and diffs that may or
may not merge correctly. I think if I had had bzr it may have gone
smoother and I might have had more contributions, but perhaps it is
just me. :-)

> This last question is what troubles me the most. If I'm right and our
> workload essentially requires a _centralised_ system, even if bzr can
> support that, what actually is the point in moving? Launchpad
> integration may be one reason, I suppose. But we definitely need
> concrete reasons (apart from "oh, everyone in Ubuntu uses it, it must be
> cool!"), IMO.

I agree. I would hate for us to move just because it is the Ubuntu
"fad". However, it seems to me that bzr is being used very
successfully in the dev community and perhaps it had advantages for
us. [1] I'm going to create a test bzr repo so we can try to test
whether bzr is right for us.

Just my $.10

-Jordan

[1] http://bazaar-vcs.org/BzrFeatures