Home ›
Agaric wants version control that lets Drupal core and contrib replace entire directories within our checkoutsAgaric wants version control that lets Drupal core and contrib replace entire directories within our checkouts
Submitted by Benjamin Melançon on January 13, 2008 - 10:30am
As a small web design and development company, Agaric has a very specific need:
To have one part of a project under version control come from Drupal core, to have another part come from our selection of Drupal contributed modules including our own (and this would actually reside inside Drupal core), and to have the rest (theme, custom site-specific modules) be our own work and also reside inside the Drupal core directories.
We then want to be able to check out this conglomeration all at once to dev, test, and live.
Right now we have each of these three areas checked out independently, and while they do happily reside inside one another, there's some inconvenience and risk of not keeping everything in synch.
The solution we're looking at now is shell scripts but if there's a way for a version control system to just understand this need and accept it, that would be best.
Resolution
Searched words:
mercurial
git
subversion
svn
Comments
SVN Externals
You can do this easily with SVN externals.
For example, we maintain Drupal several contributed modules under http://svn.advantagelabs.com/managed/
Then, for each client repository, we store the contents of their "sites" folder ( e.g. local/overriden themes and modules ). For the DocumentRoot of these sites, we use the svn:externals property to reference the managed drupal and sites/all folder.
In this way, we can permit multiple developers to access the per-site repositories, without affecting core files. When a security or other update is required, you can suck down the changes from the shared repository.
I did a lightning talk on this in Sunnyvale, and I think there's video someplace.
Rather than duplicating efforts, we would not mind at all if people use our managed repo at http://svn.advantagelabs.com/managed/
You can see how it all fits together by checking out out http://svn.advantagelabs.com/sites/foo.com/
A script for generating a repository like foo.com is available at http://svn.advantagelabs.com/managed/drupal/branches/drupal-5/scripts/mkdrupal.sh
Git submodules
You can do similar things like mentioned SVN externals with Git submodules... and have the advantage of distributed SCM, and better branching (cheap branches) and merging (automatically determine merge base, rename support).
Submodules are described in
Working on Drupal with Git is described in Upgrading Drupal with Git article on VersionControl blog, and extended a bit in Managing your local Drupal installation with Git.
You can do two-way interaction between Subversion and Git using git-svn.
--
Jakub Narebski
Wow! We are honored by the commenters here
Thank you, Allie, for sharing the SVN externals approach. That's closest to what we have now and we'll definitely look at it.
Pajunas looks a great concept and company. Have you run across May First People Link? Maybe we could all work together on some things.
Jakub, I cannot resist the lure of trying Git with the workflow described. Thanks for the great tips and links.
We'll report on how we go about things-- the only other pieces I don't see as already in place, armed with these resources now, is making it extremely easy to add modules to a Drupal installation (rather than keeping a full set of our selection in sites/all/modules) and including the Drupal modules we maintain, and test out on our own sites, which are ultimately committed to Drupal.org.
From your description, it
From your description, it sounds like what you actually want is the ability to develop (with version control) a project that's shaped like the Drupal core, but with your code also inside it, and have your project able to merge in newer Drupal versions. That is, if somebody looked at your project's organization, and didn't notice the directories for your code, they'd think they were looking at the Drupal core, because you don't have anything outside the Drupal directories, just inside them.
With git, you can just clone the Drupal repository, stick in your code, and commit; git doesn't care particularly much that this gives two upstream locations (Drupal's version control system and your own), and you can take changes from each of them. You can also list your own separate history as a parent of the first commit you make and git should be able to follow the history of files in the resulting repository back into whichever history is appropriate (and git doesn't care that there are now two unrelated initial commits, one from Drupal and one from your own history).
Submodules are more for what your subject suggests instead of what your body suggests: having an unmodified version of Drupal sitting within your project as a subdirectory under your code. This has the advantage that, if you make changes to Drupal's core code and want to submit them back to Drupal.org, that subdirectory contains an unexceptional Drupal.org working directory without your stuff, but the disadvantage that it doesn't give the organization of the project as a whole that you ask for.
Drupal Modules + Custom Changes -> Contributed back to Drupal
Checking out the great resource on Drupal > Drupal + Modules > Drupal + Modules + Custom modifications cloning chain at the link Jakub suggested (Upgrading Drupal with Git), it looks great. It seems each site we maintain should be its own repository? I have one big question for this approach, which I also posted over there:
Actually, the key question now is can git combine projects?
Every Drupal module should have its own repository, I think. Because Drupal is itself in CVS, it needs to be possible to take a tarball (or CVS) of a Drupal module and replace a previously existing one, and merge the new one into our representation of it, and pull or push from that into all the places where its used in our sites.
ConfigManager which can be used with Bazaar seems to do that. I do think Git can too, but how?
You may have seen this by now …
… there is a Git mirror of the drupal CVS repository available mikkel.hoegh.org. I'm currently trying the same as you were doing 4 months ago.
My basic plan is to have the same setup as the version control blog suggests.
I'm also considering wether to make each of the contrib modules as a Git submodule or just leave them as they are, getting versioning from the production site repo. I will definitely submodule the modules that I make for each site, so they can be shared between projects.
Are you still using this method, or is it all a pain to administer? I'm concerned that syncing changes to the server could be painful if you forget to pull the 20 or so contrib submodules in any given site.
There should be a git suck-all command to pull in all submodule changes as well as the other linked repo's (in this case repo's 1 and 2) for an entire project.
The more I use it the more Git seems like a magic hoover, suck up the good stuff git :)
I abondoned git and fell back to svn plus piston
Hmm, I better update this. Submodules proved too raw / frustrating for me.
However piston is getting git support, I understand, if it doesn't have it already, and there's giston, and braid, and something else on the page I found at the time that described piston, but I can't find those notes. I would advise against submodules, but maybe the problem was me and not them. However I think git with something like piston would be much better. I just ran out of time on reconfiguring the system and it was easier to fall back on SVN and throw Piston into the mix.
Definitely interested in moving to Git, so I'd love to stay updated on your solutions and questions!
best,
benjamin, Agaric Design Collective
Thanks for the update
Its good to know what other people are doing to manage Drupal installs.
From first sight Piston looks like it could be replaced by the same method Mikka Hoegh used with a git-cvs-import (to create the Drupal Git mirror). It will pull in the changes from the Drupal repo. Using it to check out early versions of Drupal is fun :) I'd guess you can checkout a branch for each version of Drupal you support.
Not to sure if creating a git_cvs-import of single modules would result in the whole Drupal contrib tree coming into the Git repo. I'm still using a Google code Mac OSX package of Git that doesn't do the cvs-import.
I'll let you know how it goes. It does seem to be a lot to set up. Maybe a simple single repo would be better scratches chin
Post new comment