A streamlined way to develop core patches

[David Timothy Strauss]

I've made a post on the Four Kitchens blog about a new repository we're hosting to support streamlined core development.

The post is here:

http://www.fourkitchens.com/blog/2008/12/07/using-bazaar-work-drupal-core-patches

And here it is in plain text:

As anyone who's developed core patches knows, it's not the writing of initial patch that takes the work, it's the combination of revising the patch and keeping up to date with HEAD. With Drupal.org's CVS, this is difficult because you cannot commit your core changes to checkpoint your work. CVS's merge algorithms are also relatively poor for maintaining large divergence from CVS HEAD.

One option -- which several community members used to create the huge DB-TNG patch -- was to create a Subversion repository. This is far too much overhead for smaller core patches, and it still required person-by-person approval to commit to the Subversion repository.

Four Kitchens is now hosting a much more flexible system for users of Bazaar. Every hour, we synchronize core changes from CVS HEAD into our Drupal 7 branch, which is available for anonymous branching by anyone.

Simply download and install Bazaar, which has packages or installers for Linux, Windows, Mac OS X, and BSD. We're using a repository format that should work with Bazaar 1.0 and newer, at a minimum.

Then, where you're ready to develop, run this:

bzr branch bzr://vcs.fourkitchens.com/drupal/7 [optional-working-copy-directory]

You'll have a fresh working copy with a number of benefits over a CVS checkout:

You can commit to your local branch to checkpoint your work: bzr commit
You can integrate in changes to HEAD using Bazaar's superior merge algorithms: bzr merge
You can branch from your own branch: bzr branch [existing] [new]
If you're working with others and they have Bazaar branches, too, you can merge from their branches to collaborate.
And when you're ready to post a patch, run bzr diff --old bzr://vcs.fourkitchens.com/drupal/7 to create a patch reflecting all of your changes relative to CVS HEAD.

It will be a while before Drupal.org moves to anything other than CVS. Until then, we can foster decentralized development quite effectively using something like the Four Kitchens repository.

[Karoly Negyesi]

Thanks for the summary and the bzr mirror!

There is another bzr mirror at https://code.launchpad.net/~vcs-imports/drupal/main and I am using solely bzr for the last three years for core development. First James Blackwell (big kudos to the guy for trying to get us over to bzr, pity it did not happen) provided a bzr mirror and then launchpad took over.

If you ask "why are we not on bzr yet?" then head over http://drupal.org/node/289117 please. Some of the concerns do not apply to bzr (for eg. it has a tortoisebzr as part of the main client and we have quite some bzr knowledge in house and it's so easy to use) but other concerns do apply and may prohibit such a move completely.

[Konstantin Käfer]

Thanks!

Is it possible to remove the empty directories that are unused in CVS  
(like /database or /themes/goofy).

Konstantin

On 07.12.2008, at 05:27, David Timothy Strauss wrote:

> I've made a post on the Four Kitchens blog about a new repository  
> we're hosting to support streamlined core development.
>
> The post is here:
>
> http://www.fourkitchens.com/blog/2008/12/07/using-bazaar-work-drupal-core-patches
>
> And here it is in plain text:
>
> As anyone who's developed core patches knows, it's not the writing  
> of initial patch that takes the work, it's the combination of  
> revising the patch and keeping up to date with HEAD. With  
> Drupal.org's CVS, this is difficult because you cannot commit your  
> core changes to checkpoint your work. CVS's merge algorithms are  
> also relatively poor for maintaining large divergence from CVS HEAD.
>
> One option -- which several community members used to create the  
> huge DB-TNG patch -- was to create a Subversion repository. This is  
> far too much overhead for smaller core patches, and it still  
> required person-by-person approval to commit to the Subversion  
> repository.
>
> Four Kitchens is now hosting a much more flexible system for users  
> of Bazaar. Every hour, we synchronize core changes from CVS HEAD  
> into our Drupal 7 branch, which is available for anonymous branching  
> by anyone.
>
> Simply download and install Bazaar, which has packages or installers  
> for Linux, Windows, Mac OS X, and BSD. We're using a repository  
> format that should work with Bazaar 1.0 and newer, at a minimum.
>
> Then, where you're ready to develop, run this:
>
> bzr branch bzr://vcs.fourkitchens.com/drupal/7 [optional-working-
> copy-directory]
>
> You'll have a fresh working copy with a number of benefits over a  
> CVS checkout:
>
> You can commit to your local branch to checkpoint your work: bzr  
> commit
> You can integrate in changes to HEAD using Bazaar's superior merge  
> algorithms: bzr merge
> You can branch from your own branch: bzr branch [existing] [new]
> If you're working with others and they have Bazaar branches, too,  
> you can merge from their branches to collaborate.
> And when you're ready to post a patch, run bzr diff --old bzr://
> vcs.fourkitchens.com/drupal/7 to create a patch reflecting all of  
> your changes relative to CVS HEAD.
>
> It will be a while before Drupal.org moves to anything other than  
> CVS. Until then, we can foster decentralized development quite  
> effectively using something like the Four Kitchens repository.

[Damien Tournoud]

On Sun, Dec 7, 2008 at 5:27 AM, David Timothy Strauss <david@...> wrote:

I've made a post on the Four Kitchens blog about a new repository we're hosting to support streamlined core development.

I also maintain a Git mirror at:
    http://git.drupalfr.org/drupal-core-nok.git
    and git://git.drupalfr.org/git/drupal-core-nok.git

... that is especially useful to manage patch series using Stacked Git. See this page for a walk-through:

    http://drupal.org/node/337933

Damien Tournoud

[Gordon Heydon]

Hi,

I also have a git repository of core, and I also have every  
contributed modules and themes in there own git repositories as well.

The problem that I found was that gitweb falls over with that many  
repositories. So over christmas I am going to be writing up a  
replacement for gitweb which will scale to cover all the projects in  
contrib.

The main reason I am building this is not for this huge number of git  
repositories but so that I can give my clients a methods to view their  
updates and changes on the current system which the git repository is  
a part of.

I am going to split out the repository browser out so that other  
modules can register repositories and then browser to them.

I will see how I go. All going well I will drop a line on development.

Gordon.

On 07/12/2008, at 11:11 PM, Damien Tournoud wrote:

> On Sun, Dec 7, 2008 at 5:27 AM, David Timothy Strauss <david@...
> > wrote:
> I've made a post on the Four Kitchens blog about a new repository  
> we're hosting to support streamlined core development.
>
> I also maintain a Git mirror at:
>     http://git.drupalfr.org/drupal-core-nok.git
>     and git://git.drupalfr.org/git/drupal-core-nok.git
>
> ... that is especially useful to manage patch series using Stacked  
> Git. See this page for a walk-through:
>
>     http://drupal.org/node/337933
>
> Damien Tournoud
>

On Sunday, 7. December 2008, Gordon Heydon wrote:

> Hi,
>
> I also have a git repository of core, and I also have every
> contributed modules and themes in there own git repositories as well.
>
> The problem that I found was that gitweb falls over with that many
> repositories. So over christmas I am going to be writing up a
> replacement for gitweb which will scale to cover all the projects in
> contrib.
>

[snip]
>
> I am going to split out the repository browser out so that other
> modules can register repositories and then browser to them.
>
> I will see how I go. All going well I will drop a line on development.

I think it would be great if you tried that as improvement of
(or replacement for) versioncontrol_project.
But of course, how you want to do it is totally up to you :P

Wishes,
  Jakob (nearly having completed the 5.x-2.0 stuff for Version Control API)

[Gordon Heydon]

Hi



On 08/12/2008, at 1:17 AM, Jakob Petsovits <jpetso@...> wrote:

> On Sunday, 7. December 2008, Gordon Heydon wrote:
>> Hi,
>>
>> I also have a git repository of core, and I also have every
>> contributed modules and themes in there own git repositories as well.
>>
>> The problem that I found was that gitweb falls over with that many
>> repositories. So over christmas I am going to be writing up a
>> replacement for gitweb which will scale to cover all the projects in
>> contrib.
>>
> [snip]
>>
>> I am going to split out the repository browser out so that other
>> modules can register repositories and then browser to them.
>>
>> I will see how I go. All going well I will drop a line on  
>> development.
>
> I think it would be great if you tried that as improvement of
> (or replacement for) versioncontrol_project.
> But of course, how you want to do it is totally up to you :P
>
> Wishes,
>  Jakob (nearly having completed the 5.x-2.0 stuff for Version  
> Control API)

I may take a look but it but I have a feeling I will need more than  
what is available in the version control api

Plus I want to make it pretty light weight so that adding this to a  
site will have no impact

Gordon

On Sunday, 7. December 2008, Gordon Heydon wrote:
> I may take a look but it but I have a feeling I will need more than
> what is available in the version control api
>
> Plus I want to make it pretty light weight so that adding this to a
> site will have no impact

Mmkay, no problem, just wanted to make sure that you consider the possibility
before dismissing it :)

(I reserve the right to port good stuff to Version Control API, though.)

Have fun,
  Jakob

[Gordon Heydon]

Hi



On 08/12/2008, at 2:38 AM, Jakob Petsovits <jpetso@...> wrote:

> On Sunday, 7. December 2008, Gordon Heydon wrote:
>> I may take a look but it but I have a feeling I will need more than
>> what is available in the version control api
>>
>> Plus I want to make it pretty light weight so that adding this to a
>> site will have no impact
>
> Mmkay, no problem, just wanted to make sure that you consider the  
> possibility
> before dismissing it :)

I may actually use the version control api to extend the fuctionality  
and not provide the base functionity.
>
> (I reserve the right to port good stuff to Version Control API,  
> though.)

No problem

Gordon

[Chris Johnson-21]

Should we have a handbook page or two on drupal.org which lists the
currently supported alternative repositories, and brief summaries of
their usage (i.e. copy the Four Kitchens description above essentially
verbatim)?  It seems like services like these could be highly valuable
to the community.

Thanks to all who support these things.

..chris

On Sun, Dec 7, 2008 at 2:45 PM, Gordon Heydon <gordon@...> wrote:

> Hi
>
>
>
> On 08/12/2008, at 2:38 AM, Jakob Petsovits <jpetso@...> wrote:
>
>> On Sunday, 7. December 2008, Gordon Heydon wrote:
>>>
>>> I may take a look but it but I have a feeling I will need more than
>>> what is available in the version control api
>>>
>>> Plus I want to make it pretty light weight so that adding this to a
>>> site will have no impact
>>
>> Mmkay, no problem, just wanted to make sure that you consider the
>> possibility
>> before dismissing it :)
>
> I may actually use the version control api to extend the fuctionality and
> not provide the base functionity.
>>
>> (I reserve the right to port good stuff to Version Control API, though.)
>
> No problem
>
> Gordon
>

[David Timothy Strauss]

I've done this now. All revisions 7 and later have CVS updates with pruned directories.

----- "Konstantin Käfer" <kkaefer@...> wrote:

> Thanks!
>
> Is it possible to remove the empty directories that are unused in CVS
>
> (like /database or /themes/goofy).
>
> Konstantin
>
> On 07.12.2008, at 05:27, David Timothy Strauss wrote:
>
> > I've made a post on the Four Kitchens blog about a new repository  
> > we're hosting to support streamlined core development.
> >
> > The post is here:
> >
> >
> http://www.fourkitchens.com/blog/2008/12/07/using-bazaar-work-drupal-core-patches
> >
> > And here it is in plain text:
> >
> > As anyone who's developed core patches knows, it's not the writing
>
> > of initial patch that takes the work, it's the combination of  
> > revising the patch and keeping up to date with HEAD. With  
> > Drupal.org's CVS, this is difficult because you cannot commit your
>
> > core changes to checkpoint your work. CVS's merge algorithms are  
> > also relatively poor for maintaining large divergence from CVS
> HEAD.
> >
> > One option -- which several community members used to create the  
> > huge DB-TNG patch -- was to create a Subversion repository. This is
>
> > far too much overhead for smaller core patches, and it still  
> > required person-by-person approval to commit to the Subversion  
> > repository.
> >
> > Four Kitchens is now hosting a much more flexible system for users
>
> > of Bazaar. Every hour, we synchronize core changes from CVS HEAD  
> > into our Drupal 7 branch, which is available for anonymous branching
>  
> > by anyone.
> >
> > Simply download and install Bazaar, which has packages or installers
>  
> > for Linux, Windows, Mac OS X, and BSD. We're using a repository  
> > format that should work with Bazaar 1.0 and newer, at a minimum.
> >
> > Then, where you're ready to develop, run this:
> >
> > bzr branch bzr://vcs.fourkitchens.com/drupal/7 [optional-working-
> > copy-directory]
> >
> > You'll have a fresh working copy with a number of benefits over a  
> > CVS checkout:
> >
> > You can commit to your local branch to checkpoint your work: bzr  
> > commit
> > You can integrate in changes to HEAD using Bazaar's superior merge
>
> > algorithms: bzr merge
> > You can branch from your own branch: bzr branch [existing] [new]
> > If you're working with others and they have Bazaar branches, too,  
> > you can merge from their branches to collaborate.
> > And when you're ready to post a patch, run bzr diff --old bzr://
> > vcs.fourkitchens.com/drupal/7 to create a patch reflecting all of  
> > your changes relative to CVS HEAD.
> >
> > It will be a while before Drupal.org moves to anything other than  
> > CVS. Until then, we can foster decentralized development quite  
> > effectively using something like the Four Kitchens repository.

--
David Strauss
   | david@...
   | [phone] [mobile]
Four Kitchens
   | http://fourkitchens.com
   | [phone] [office]
   | [phone] [direct]

[Matt V.]

I realize this thread is a bit old, but I ran across it in the archives and decided to create the documentation page Chris described:

    http://drupal.org/node/355154

I was able to track down two mirrors each in Subversion, Git, and Bazaar. If anyone knows of a Mercurial mirror (or any other additions or corrections), please feel free to update the page.

- Matt V.

Chris Johnson-21 wrote:

Should we have a handbook page or two on drupal.org which lists the
currently supported alternative repositories, and brief summaries of
their usage (i.e. copy the Four Kitchens description above essentially
verbatim)?  It seems like services like these could be highly valuable
to the community.

Thanks to all who support these things.

..chris

On Sun, Dec 7, 2008 at 2:45 PM, Gordon Heydon <[e-mail]> wrote:
> Hi
>
>
>
> On 08/12/2008, at 2:38 AM, Jakob Petsovits <[e-mail]> wrote:
>
>> On Sunday, 7. December 2008, Gordon Heydon wrote:
>>>
>>> I may take a look but it but I have a feeling I will need more than
>>> what is available in the version control api
>>>
>>> Plus I want to make it pretty light weight so that adding this to a
>>> site will have no impact
>>
>> Mmkay, no problem, just wanted to make sure that you consider the
>> possibility
>> before dismissing it :)
>
> I may actually use the version control api to extend the fuctionality and
> not provide the base functionity.
>>
>> (I reserve the right to port good stuff to Version Control API, though.)
>
> No problem
>
> Gordon
>

[Chris Johnson-21]

Fantastic!  Thanks Matt.

On Tue, Jan 6, 2009 at 7:36 PM, Matt V. <mvance@...> wrote:

>
> I realize this thread is a bit old, but I ran across it in the archives and
> decided to create the documentation page Chris described:
>
>    http://drupal.org/node/355154
>
> I was able to track down two mirrors each in Subversion, Git, and Bazaar. If
> anyone knows of a Mercurial mirror (or any other additions or corrections),
> please feel free to update the page.
>
> - Matt V.