[development] bzr battle plan

[Angie Byron]

Gerhard Killesreiter wrote:
> Gildas COTOMALE wrote:
> 
>> Suggest: why not add a poll on http://drupal.org to ask people what's
>> their favorite CSM..? We'll have so a good idea how ready future dev'
>> are ready to switch to something else and what..
> 
> It qould be quite pointless as the popular opinion does not matter at
> all as is often the case in software development. 

I agree with Gerhard here. I wouldn't want for us to pick a version control
software based on popular opinion (nor, "hey it works fine for so-and-so" for
that matter), but rather how well it addresses *our* specific needs as
developers for Drupal.

Probably the best place to start this conversation is to establish answers the
following questions (and probably some others), and choose a product based on that:

1. What are our major gripes about CVS and where has CVS failed us?

2. On the flip-side, what are some cool things about CVS that we like and want
to make sure the next package has?

3. What types of development ventures have we embarked on in the past that were
difficult to do with CVS and patches?

4. What kinds of "Wouldn't it be cool if..?" scenarios could we think of that
would help ease development?

For my part:

1. I've been bitten by the fact that the only way to grab a snapshot of the code
at a certain date and time is by timestamp. If there were 50 commits to Drupal
one day, and I want to know "What did the source look like right before patch
#23344 was committed?" it's extremely difficult to do that. This could be lack
of knowledge of CVS on my part, but I remember asking in #drupal about this and
basically being told, "you're screwed." (though killes suggested a workaround
that seemed to work in my case).

2. Morbus is going to slap me, but I really like the convenience of TortoiseCVS.
*DUCK* I also like the fact that I can browse the CVS repo on the web and do
quickie diffs between versions to spot changes.

3. Forms API. This was a huge, sweeping change against almost every file in
Drupal. We were trying to have 10 or more developers each changing little chunks
here and there and rolling them into one huge monster patch. This was an
absolute nightmare before we had a SVN repository of our own to commit to so we
had something stable to commit against.

4. I don't really have enough knowledge in this area to comment on this. The
only thing I could think of is CSL, Bryght, and Drupal.org all sharing the same
RCS, but I don't know what specific advantages that would have only that it
would be more "unified."

-Angie