A streamlined way to develop core patches
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-pa... 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.
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.
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-pa...
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.
On Sun, Dec 7, 2008 at 5:27 AM, David Timothy Strauss < david@fourkitchens.com> 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
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@fourkitchens.com
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:
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)
Hi On 08/12/2008, at 1:17 AM, Jakob Petsovits <jpetso@gmx.at> 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
Hi On 08/12/2008, at 2:38 AM, Jakob Petsovits <jpetso@gmx.at> 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
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@heydon.com.au> wrote:
Hi
On 08/12/2008, at 2:38 AM, Jakob Petsovits <jpetso@gmx.at> 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
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 <gordon@heydon.com.au> wrote:
Hi
On 08/12/2008, at 2:38 AM, Jakob Petsovits <jpetso@gmx.at> 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
-- View this message in context: http://www.nabble.com/A-streamlined-way-to-develop-core-patches-tp20877884p2... Sent from the Drupal - Dev mailing list archive at Nabble.com.
Fantastic! Thanks Matt. On Tue, Jan 6, 2009 at 7:36 PM, Matt V. <mvance@pobox.com> 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:
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.
participants (8)
-
Chris Johnson -
Damien Tournoud -
David Timothy Strauss -
Gordon Heydon -
Jakob Petsovits -
Karoly Negyesi -
Konstantin Käfer -
Matt V.