Tracking code internally with subversion: Our proposed work-flow

We’ve been playing with how we work with Drupal CVS while setting up our own in-house version control system, and we came up with a rough sketch we wanted to document and share. The ultimate goal is to create a robust work-flow where multiple developers can share code through multiple Drupal-based projects, keeping track of internal changes and also keeping the code up-to-date. We want to track code internally in subversion, while also tracking it against Drupal CVS. We have a method to manually check our code against Drupal CVS that I’ll outline below, but we’re interested in hearing if anyone else doing something along these lines that they might be willing to share.

How we’ve been working

We’ve been checking our Drupal code out of CVS through Eclipse. Besides some issues getting the “-p” option in created patches, we’ve found it works pretty well. We can check out, compare, manage patches all with a quick right click of the mouse. This allows our code to stay up to date. We've been considering moving up to PDT, but we ran into some problems and decided to stay with PHPEclipse for now.

We don’t want to maintain our own distros of contrib modules, and we’re definitely anti-fork, but sometimes we find it good to have "our" latest and greatest development code that we can check against the latest Drupal repository. This often happens when we’ve applied a patch (sometimes one that we submitted) that’s still in the queue. Sometimes the patch has been applied to the dev version, but has not been included in a full release yet. We want to stay on the full release, but we need to patch in our latest work. Eventually we will upgrade to the new release with the patch included, whether it’s two weeks into development or six months later when we’re upgrading to the next version.

What we want to do

The need to track our own code is very important. We want to sync custom themes, custom helper modules, and patched contributed modules with the rest of the development team. We want our own versioning internally.

At various points in the process, we’d like to also check the version of a contributed module in development against the current status of the module. This leaves us in a place were we will be trying to work against two repositories. Given some of the technical hurdles we were running into doing this with Eclipse, we are moving towards making this a manual process where we will need to compare how the current module has progressed against the snapshot we have.

Our current plan

Our current process is shaping up to something like this:

1. Create a new PHP project in Eclipse.
2. Check out the latest versions of Core and all contributed modules we want to use.
3. Copy all contents of the project to a new project.
4. Commit the full version of this new project into Subversion.
5. Manage development and changes through Subversion.
6. To compare current code to Drupal CVS, create a new project, import it from CVS, copy and paste code from the subversion project through Eclipse. Right click and choose “Compare with.”
7. To replace current code with code from the Drupal repository, create a new project, import from CVS, copy and past to the Subversion project and commit your changes.

The last two points seem a bit tedious. There's some argument for leaving this a manual decision, which is what we're going with, but it seems there should be a way to better leverage the technology. This is probably the part we are most unsure about, and we'd be interested to see if anyone else has had luck with making this work in a more efficient manner.

Another caveat that we're examining in the need to make sure we document what versions of a contrib module we are using. Once we check it into subversion, all CVS entries are effectively gone. This requires us to keep a master list of what releases we are using for each module. This is another point where we are looking to minimize any confusion through better use of technology.

Thanks in advance for anyone else willing to share! If not, hopefully this will help someone else out there.