[development] bzr battle plan

[Karoly Negyesi]

bzr and Drupal.

We now have a bzr mirror of the core. It's easier for a group of people
to work on a bigger change in their own branch and submit a final diff.
(hint. bzr diff --diff-options -F^f) Eventually, Dries may use a bzr  
branch,
too and then instead of patches we may submit a link to a bzr branch  
instead
of a patch file but this is not so important.

We will provide and advertise a readonly bzr mirror for all contrib
directories. If the module maintainer decides that he he does not want to
deal with CVS but uses bzr instead, he will have a checkbox in project
module to indicate that (or if we do not want project change, just text  
that).

If it's a bzr maintained module then you can contribute two ways:
a) send in patches (like now)
b) from the bzr mirror, create your branch and submit a link to the
maintainer.

When the maintainer wants to commit changes back to the repo, he merges
changes and pushes that to a private branch. When this push happens, a
simple script is run, which commits these changes back to cvs, and from
there we mirror to bzr and the cycle is complete. The problem is -- how we
avoid conflicts? Simply, if a module is bzr maintained, then we make it  
clear
that you should not commit into the CVS repository dir by the means of
CVS. Either submit a patch (as you do now) or use bzr but do not commit
into that dir.

Ideally, cvs.drupal.org rejects this kind of commit by the means of a
pre-commit script. Lacking that, the bzr to cvs script will take care of
it. Then this script needs to track of the revision of the cvs revision of
the files in the readonly bzr mirror (first ancestor):

# check out the first ancestor
cvs co foo -r$known_revision
# make sure the cvs is in that state
cvs commit
# bring in the new/changed files
bzr pull $maintainers_private_branch
# make sure CVS knows about new files
cvs add *
# put the log into an obscure named file
bzr log $maintainers_private_branch -r -1 >__bzr__log
# reuse that for cvs log message
cvs com -F __bzr__log

Yes, that's the actual script. Advanced versions will be able to branch
for Drupal versions. Even that should not be too hard, because the bzr
mirrors (including the maintainers_private_branch) will have directories
modules/eventrepeat/4.6 -- one dir for every Drupal major version.

Updating the readonly bzr mirror is easy:

cvs up -dP
bzr commit

Probably the scripts will be written in PHP and linked through the
database -- after all, you need store somehwere the known_revision and
maintainers_private_branch. The __bzr__log also should be saved and reused
when commit in the readonly space. Or to maintain simplicity maybe we
could get away even with some bash scripts which store info in text files.
Caveat: I am no expert of that. (note. file additions and removals needs to
handled. Maybe tailor will be used here.)

If the module is a CVS maintained one, then those that are on the bright
side  can _still_ use the readonly bzr mirror only they are not submitting
bzr branch links but patches.

Let's see some benefits:

The necessary scripts are simple.

If someone wants to run cvs update -- (s)he can do that.

If a module/theme/translator maintainer is sick of cvs -- there is bzr.
Also, a web upload interface is coming for bzr.

If a module/theme/translator maintainer wants to use cvs -- (s)he does
not need to face bzr yet his/her contributors can use that and submit
patches.

What's lost?

If a module is bzr maintained then you can't just walk in and do an update
of the module. The maintainers' responsibility is bigger. Solution?
Multiple maintainers with a $maintainers_private_branch for each
maintainer. You still can't just walk in, but there always will be someone
who can commit your change. Note that this is pretty rare, as most module
maintainers do not like if you commit into their directory in the current
situation.

One more thing: there should be another privilege level, they can commit
against any module.

Note that we do not need to change _anything_ in the modules currently
used Drupal.org! Still CVS is the common denominator

This is a plan which needs time. Also, bzr itself needs some time. I do not
plan on posting the whole Drupal community through drupal.org until bzr 2.0
is out next spring.