[bt-devel] The future of development and DVCS

[Eeli Kaikkonen]

On Sat, 5 Dec 2009, kbs wrote:

> I'm not worried about it because I see it as a feature.   If we don't
> move over to something that is not centralized, we will need more code
> review on what is checked in.  I know this is potentially sensitive,
> especially when there is differing opinion on the quality of the code.
> The good thing with a web of trust is that people can be selective with
> what they merge into their local branches.  The bad thing is that one
> person must be picked to have the branch that is released.

The bad thing isn't necessarily true. Any DVCS supports the old
centralized system where anyone or only one or limited number of people
can commit to a repository or a branch which is called "trunk" or "head"
or something and which is agreed to be the canonical/official version.
Svn just forces things to be like that because there's only one
repository (even though anyone can duplicate/fork it).

A DCVS doesn't force you to do things differently but allows it.
Especially bzr supports many workflows out of the box, see
http://doc.bazaar-vcs.org/latest/en/user-guide/bazaar_workflows.html
(not too long, good basic reading). Naturally it requires more learning
because of the flexibility, which is a con, but there's no free lunch.

>
> Right now, there is no branching and questionable code is being checked
> into the trunk.  When class interfaces are changed in the trunk without
> any discussion, there will be major headaches for the other volunteer
> developers who are already busy as it is.

This describes well the problem which we will face in the future if we
continue to grow, and which we have already.

> Encapsulation is my friend.
> With a distributed system, we can ignore bad code without having to
> reject someone from a commit to the trunk; thus they are not offended.
> Also, the code might just be incompatible due to a drastic refactoring
> or code rewrite.  At least the local code is being version-controlled
> for the sake of the programmer.
>

I think you describe here a fully decentralized workflow with no central
repo. We would continue with an official canonical repo with a
head/trunk, and it doesn't work like in the Linux kernel development
where there are several "official" versions from which e.g. linux
distros pick one change it. In our workflow the central trunk/head
couldn't be ignored; just like it's now with svn. But sharing code would
be easier.

> Maybe Eeli and I can start a bzr repository on SF and used it as a
> testbed (with anyone else who is interested) and we will treat the SVN
> repo (either trunk or a 2.5 branch) as another user.  I confess fear of
> git.
>

One good thing about bzr is that it supports foreign repositories quite
well out of the box (with plugins, but still). Just like bzr-svn, you
can use bzr-git (even though I haven't tested it so I can't say for sure
how well it works). Then if we have a git repo individual developers
could use bzr locally. See
http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-git-projects.html.
I don't know if it would work in the other way round.

But this is only one detail. There are pros and cons for both. We just
have to pick one first and try it, maybe then another. May the first one
be bzr if people want it.

The problem with sf.net support is this: sf.net doesn't support multiple
repositories or advanced directory layouts for bzr. In practice this
means that you can have only one repository and under that branches
directly. You can't have e.g.:

application/trunk     (main development for the app)
application/branches/ (branches for the app)
website/trunk         (main development for the website)
documentation/trunk   (main development for the docs)

or

trunk/application/        (main development for the app)
trunk/website/            (main development for the website)
experimental/application  (includes feature branches for the app)

or

bibletime/user1/feature1 (a feature branch of a user)
bibletime/user1/feature2 (another feature branch of a user)
bibletime/trunk/         (main development)

But you can have only

repo/    (and under that:)
  branch1/ (trunk for main development)
  branch2/ (branch for feature1)
  branch3/ (branch for feature2)
  branch4/ (release branch for version...)

I.e. you can have only one repository and branches directly under it.
With git you can have several repositories, but git itself restricts the
branches so that they are direcly under the repository in one "bunch".
At least this is how I have understood it.

SVN supports checking out subtrees. As far as I know dvcs's don't
support it. This means that you can't create a repo, put several
projects (or subprojects) under it and checkout only one of them. You
will get either all or nothing. We would have only the main app code, so
this wouldn't be a huge problem, but this explains why limited bzr
directory layout is a bad thing.

One stupid thing with bzr is that you can create remote branches with a
bzr command but you can't remove them with bzr commands. They must be
removed manually by deleting the file system directory (because branch
is a directory in bzr). In sf.net only admin can do that. It means that
if a developer creates an experimental branch for featureX but soon
abandons it, it will either stay there forever or the admin must delete
it. And even then it will stay in the repository, because only the
directory has been deleted and isn't visible anymore. I don't even know
what happens if you then try to recreate a branch with the same name.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)