Subversion integration: svn add and svn commit after drush install

thats my workflow too. i'd like to see this in drush. i'm not sure how best to implement it. maybe a post hook a you suggest. i guess that hook could run for all drush commands, not just pm install.

at a high level, thats what is needed. but i don't think that we need to svn remove files that are staying in the repository. we only need to remove those that are no longer in the directory. similarly, we need to discover newly added files and svn add them. there are some scripts out there for this from which we might learn. for example, see http://piston.rubyforge.org/.

if it gets too complicated, i guess we could only hook into pm install for now and leave pm update for later.

here is a great blog post which details usage of svn_load_dirs.pl. That script ships with svn and really helps handle changes like this. see http://www.burtonini.com/blog/computers/svn-vendor-2005-05-04-13-55

Hi, I've just discovered the wonders of drush & the pm install feature!

Just wondered on the svn setup you guys are using, as I currently use svn:externals to add drupal modules to sites, so theres only one copy of the module code in the svn repos.

I take it doing things the way you show benjamin, each site in your repository has its own copy of the contrib module? Don't see much of an issue with that, seeing how easy drush makes adding & instaling modules now! Just wanted to see how others do things before I start using drush in my daily workflow : )

Thanks,
Phil

I keep each project in separate svn repository and same for Contrib. No svn:externals for me and my clients. Folks who like svn:externals might be interested in the repos at http://svn.advantagelabs.com

Cheers Moche, will try & take a look at that link when I get a spare mo.

Although I'm starting to think I might ditch svn:externals, as it can complicate things alittle, and instead go for a similar setup to you guys.

Back to the original post, when doing an update on a module already in your svn repos, would the workflow go like this?

cd /var/www/drupal-5_3-live/sites/all/modules/
sudo php drush/drush.php -l http://example.com pm update fasttoggle
sudo svn_load_dirs.pl.....
> resolve any conflicts manually? <
sudo svn commit -m "Updated fasttoggle via Drush"

yes, thats the idea. perhaps someone could try this out and see how well it works. then we'll talk about how smart drush should get about this workflow.

A drupal specific tutorial including svn-load-dirs: http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion

Another option, that seems quite a bit simpler (especially if we want to implement in PHP!) is http://gael-varoquaux.info/computers/svnautocommit/#the-autocommit-script - this does what is described above - reading the output of svn stat, and adding/deleting the files as appropriate.

..and a patch...

I have moved all subversion integration out of the main drush_pm module, and into a drush_pm_svn module (yay!). There is now a hook to suppress backups, and another more general one after the install/update of each project, which should be useful for lots of things. I have added a simple static get/set function to store the output of the last exec (this is somewhat the same style as used by perl, IIRC) - which seemed neater and easier than returning a whole array of the return value plus the output. We need this to parse svn stat output, but it is also handy for presenting more helpful error messages (we should apply this approach to the handler modules too, I think).

Everything else is pretty much self explanatory. I have added lots of error checking and messages. I didn't go for drush_die, since none of these really seem 'fatal' to me, however I am open to suggestions otherwise! This needs testing with the wget handler (I tested quite a lot with cvs though), and perhaps a good read through the documentation and error messages.

Nice work!

* Need some Doxygen for drush_shell_exec_output_set()
* Personally I find it easier to work with XML output than regexing out info. See `svn stat --xml` for an example. Not a big deal I suppose.
* Does it make sense to implement the backup step as a 'pre' operation of pm update?
* Instead of implementing pre/post hooks that are specific to install and update, why not add these for all commands. Maybe in drush_dispatch(). That function seems to support multiple commands in one drush call but I have never tried that.
* I suspect some implementations will want to pass in subversion credentials in this call. We should document how to do that in the help for the commands and/or in example.drushrc.php
* Some support for DRUSH_SIMULATE mode would be very handy here.

-moshe

Need some Doxygen for drush_shell_exec_output_set()

Added.

Personally I find it easier to work with XML output than regexing out info. See `svn stat --xml` for an example. Not a big deal I suppose.

I agree here - I think it might be best to add this to the D6 version though, since we have PHP5 and hence SimpleXML, and keep the D5 version PHP4 compatible.

Does it make sense to implement the backup step as a 'pre' operation of pm update?

I thought about that, but we still need some way for other modules to overrule the backups. The only other things I can think of seem more complex or fragile.

Instead of implementing pre/post hooks that are specific to install and update, why not add these for all commands. Maybe in drush_dispatch(). That function seems to support multiple commands in one drush call but I have never tried that.

This is a great idea, and should be easy to implement. However I think this is a different patch because neither of these would really help us here - skip_backup needs to know the source of the module to check for .svn directories and drush_pm_post_update should only be run after a successful install (not just after the completion of the command). Also each of them should be run for each project, not once per command.

I suspect some implementations will want to pass in subversion credentials in this call. We should document how to do that in the help for the commands and/or in example.drushrc.php

I have added these, which I think could be useful (although only occasionally), we need a separate parameter for each command because different svn commands accept different parameters (and throw errors if they get one they don't expect).

Some support for DRUSH_SIMULATE mode would be very handy here.

It already works in simulation mode by not actually running the shell command. Not sure what else we would do in simulation mode - svn has a --dry-run option, but only for merge (which we aren't using).

and a HEAD patch (could use a test)

and a tweaked D5 patch

and a tweaked D5 patch

Forgot the HEAD patch (end of day...)

Committed! This was nicely done. Thanks Grugnog2.

I think that svncommit should imply svnsync. This saves typing.