Multiple modules, multiple versions, in Eclipse
Greetings, all After some time away from Drupal due to work responsibilities, I have found myself able to return to module development (and I'm really glad of this!). I decided, since my local development environment was already outdated, to make the jump to Eclipse instead of continuing to code in vi and update CVS manually. I've used Eclipse for Java work but not for PHP previously. I got Eclipse up and running and editing my code, and was able to checkout and commit changes to my modules. Three modules that hadn't been updated for months now have new updates awaiting release. Where I ran into trouble is in managing the branch tags, and I think it's because of the way I set things up in Eclipse. Right now, I have one workspace called "drupal" and a project called "drupal-6-contrib", and I imported code for my three modules using the CVS checkout feature of Eclipse to select the correct branch. Eclipse can't find the branch or version tags for the individual code folders, even though it *did* find them when I did the initial checkout and commit. I need to be able to manage my modules for multiple Drupal core versions, and also for multiple modules, and I'm looking for advice from others as to the "best practices" for doing this. How did you partition your development environment as far as workspace, project, and folder levels, with regard to Drupal core and module versioning standards? There are lots of articles on d.o and on the web at-large about setting up the Eclipse mechanics, but I haven't found anything on this particular topic that talks about being able to do multiple versions concurrently. Ideally, I'd like to keep this in a single workspace so I can cut and paste code when forward-porting or back-porting, but that may not be practical. Thanks for any advice. Kind regards, Scott -- Syscrusher <syscrusher@4th.com>
I use a single workspace for all my Drupal work (and a few other for code using different coding standards). Then I do one "project" per module per active branch. For example, if I need to implement a feature in D7 then backport to D6, I'll have one "project" per. Importing a project via CVS makes this easy. Also, I can keep most of the projects closed and cut down on memory footprint. I've also got one "project" per site, containing just code that is unique to that site. Custom themes, etc. Long ago I had one mega-project with many CVS repos, but that was not flexible and grew unwieldy. - Ken Winters Syscrusher wrote:
I need to be able to manage my modules for multiple Drupal core versions, and also for multiple modules, and I'm looking for advice from others as to the "best practices" for doing this. How did you partition your development environment as far as workspace, project, and folder levels, with regard to Drupal core and module versioning standards?
Hi Ken - How do you build a dev site using your root-level contrib module projects? Do you just symlink together a site? This is a classic Drupal problem, and it's not really even solved well by git, which has submodule support, but not sure it makes everything better. -Randy On Sun, Jun 6, 2010 at 12:12 PM, Ken Winters <kwinters@coalmarch.com> wrote:
I use a single workspace for all my Drupal work (and a few other for code using different coding standards).
Then I do one "project" per module per active branch. For example, if I need to implement a feature in D7 then backport to D6, I'll have one "project" per. Importing a project via CVS makes this easy. Also, I can keep most of the projects closed and cut down on memory footprint.
I've also got one "project" per site, containing just code that is unique to that site. Custom themes, etc.
Long ago I had one mega-project with many CVS repos, but that was not flexible and grew unwieldy.
- Ken Winters
Syscrusher wrote:
I need to be able to manage my modules for multiple Drupal core versions, and also for multiple modules, and I'm looking for advice from others as to the "best practices" for doing this. How did you partition your development environment as far as workspace, project, and folder levels, with regard to Drupal core and module versioning standards?
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
In my local development environment (MAMP) I do tend to use a lot of symlinks. I also have one giant SVN repo which contains common modules that I don't maintain (admin_menu, token, etc.) which can be symlinked in bulk. - Ken Winters Randy Fay wrote:
Hi Ken -
How do you build a dev site using your root-level contrib module projects? Do you just symlink together a site?
This is a classic Drupal problem, and it's not really even solved well by git, which has submodule support, but not sure it makes everything better.
-Randy
On Sun, Jun 6, 2010 at 12:12 PM, Ken Winters <kwinters@coalmarch.com <mailto:kwinters@coalmarch.com>> wrote:
I use a single workspace for all my Drupal work (and a few other for code using different coding standards).
Then I do one "project" per module per active branch. For example, if I need to implement a feature in D7 then backport to D6, I'll have one "project" per. Importing a project via CVS makes this easy. Also, I can keep most of the projects closed and cut down on memory footprint.
I've also got one "project" per site, containing just code that is unique to that site. Custom themes, etc.
Long ago I had one mega-project with many CVS repos, but that was not flexible and grew unwieldy.
- Ken Winters
Syscrusher wrote:
I need to be able to manage my modules for multiple Drupal core versions, and also for multiple modules, and I'm looking for advice from others as to the "best practices" for doing this. How did you partition your development environment as far as workspace, project, and folder levels, with regard to Drupal core and module versioning standards?
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
On 06/06/2010 2:55 PM, Randy Fay wrote:
How do you build a dev site using your root-level contrib module projects? Do you just symlink together a site?
I use an external build configuration to rsync the module to the appropriate dev site. Then I'm just one click away from copying the changes in. Once I'm happy with them, I build a proper patch, revert the rsync destination, and apply the patch. --Andrew
On Sun, 2010-06-06 at 14:12 -0400, Ken Winters wrote:
Then I do one "project" per module per active branch. For example, if I need to implement a feature in D7 then backport to D6, I'll have one "project" per. Importing a project via CVS makes this easy. Also, I can keep most of the projects closed and cut down on memory footprint.
Thanks for the post -- this is what I was thinking about doing, but wanted to ask before I completely rebuild my workspace, to avoid wasted effort if it was a Very Bad Idea. :-) So let's say I have "mymodule" with a branch tag of DRUPAL-6--1. What process would you use (from the Eclipse perspective) to commit first a beta (or two) and then a production release in getting that to DRUPAL-6--2? It sounds as if my problem may stem from having done one project per module rather than one project per module per branch. Scott -- ------------------------------------------------------------------------------ Scott Courtney scott@4th.com http://www.4th.com/ -- Syscrusher <syscrusher@4th.com>
I actually do branching via terminal, since the Eclipse interface for that is a little confusing. As soon as the branch tag exists, the rest is easy to do in Eclipse. Once you make the branch, create another project for it and leave the old branch intact. Having just one project per module doesn't really save you anything, and becomes a giant pain when you want to have both open at once. You could just make do with diff windows, but it's hard to work like that. Betas and such are really a non-issue, because you don't have to branch (just tag). Get to the point where you want to release a beta, commit in the 6--2 project, then tag. Beta 2 is the same, commit then tag. Backport to 6--1? Open the 6--1 project, patch it, commit, tag for release. - Ken Winters On Jun 6, 2010, at 11:18 PM, Syscrusher wrote:
On Sun, 2010-06-06 at 14:12 -0400, Ken Winters wrote:
Then I do one "project" per module per active branch. For example, if I need to implement a feature in D7 then backport to D6, I'll have one "project" per. Importing a project via CVS makes this easy. Also, I can keep most of the projects closed and cut down on memory footprint.
Thanks for the post -- this is what I was thinking about doing, but wanted to ask before I completely rebuild my workspace, to avoid wasted effort if it was a Very Bad Idea. :-)
So let's say I have "mymodule" with a branch tag of DRUPAL-6--1. What process would you use (from the Eclipse perspective) to commit first a beta (or two) and then a production release in getting that to DRUPAL-6--2?
It sounds as if my problem may stem from having done one project per module rather than one project per module per branch.
Scott
-- ------------------------------------------------------------------------------ Scott Courtney scott@4th.com http://www.4th.com/
-- Syscrusher <syscrusher@4th.com>
On Mon, 2010-06-07 at 08:36 -0400, Ken Winters wrote:
I actually do branching via terminal, since the Eclipse interface for that is a little confusing. As soon as the branch tag exists, the rest is easy to do in Eclipse.
Thanks to Ken and others for some very helpful posts. I will try the setup you have suggested. Scott -- Syscrusher <syscrusher@4th.com>
participants (4)
-
Andrew Berry -
Ken Winters -
Randy Fay -
Syscrusher