Getting SVN to deal with orphaned and new files
I get modules from d.o. from CVS, then I commit them to my own repository with SVN. When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one. But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this. So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files? Thanks, Shai
On 2009-11-24, at 6:19 PM, Shai Gluskin wrote:
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Vendor branches. Though it's not drushified yet, I have a script (originally written by dww) posted which automates the CVS checkout / SVN checkin process. http://www.abdevelopment.ca/blog/drupalcamp-montreal-simplifying-drupal-deve... --Andrew
SVN isn't quite as bad for this as you make it out to be. :-) You can do: svn add --force sites/all/modules and it will recursively add any files under that directory that it doesn't already know about. Be careful of ._ files and similar crap that OS X may create. :-) That's actually my usual workflow at this point. Drush dl to grab new modules, drush update to update a module, followed by the svn command above and then commit. It doesn't handle file deletes or major file reorganization, but those are quite rare. And I almost never check out a module straight from CVS. If I want a dev version, you can tell Drush to get that for you. --Larry Garfield Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
Thanks Larry and Andrew! Larry, can you use --exclude to deal with the OS X crap? Shai On Tue, Nov 24, 2009 at 8:38 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
SVN isn't quite as bad for this as you make it out to be. :-) You can do:
svn add --force sites/all/modules
and it will recursively add any files under that directory that it doesn't already know about. Be careful of ._ files and similar crap that OS X may create. :-)
That's actually my usual workflow at this point. Drush dl to grab new modules, drush update to update a module, followed by the svn command above and then commit. It doesn't handle file deletes or major file reorganization, but those are quite rare.
And I almost never check out a module straight from CVS. If I want a dev version, you can tell Drush to get that for you.
--Larry Garfield
Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
Wow; with drush, as Larry hinted, no need to use CVS versions anymore unless you've hacked the module. Goodbye cvs_deploy module and lots of CVS files getting committed to SVN. But here is my question. Can anyone confirm that what I just described is not so with Drupal core. Though Drush can download a fresh non CVS install of Drupal, It isn't able to upgrade Drupal core. So it seems like it still makes sense to not use Drush for downloading Drupal core, but stick to CVS for ease of upgrade. Can anyone confirm that is correct? Shai On Tue, Nov 24, 2009 at 9:07 PM, Shai Gluskin <shai@content2zero.com> wrote:
Thanks Larry and Andrew!
Larry, can you use --exclude to deal with the OS X crap?
Shai
On Tue, Nov 24, 2009 at 8:38 PM, larry@garfieldtech.com < larry@garfieldtech.com> wrote:
SVN isn't quite as bad for this as you make it out to be. :-) You can do:
svn add --force sites/all/modules
and it will recursively add any files under that directory that it doesn't already know about. Be careful of ._ files and similar crap that OS X may create. :-)
That's actually my usual workflow at this point. Drush dl to grab new modules, drush update to update a module, followed by the svn command above and then commit. It doesn't handle file deletes or major file reorganization, but those are quite rare.
And I almost never check out a module straight from CVS. If I want a dev version, you can tell Drush to get that for you.
--Larry Garfield
Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
On Tuesday 24 November 2009 10:35:06 pm Shai Gluskin wrote:
Wow; with drush, as Larry hinted, no need to use CVS versions anymore unless you've hacked the module. Goodbye cvs_deploy module and lots of CVS files getting committed to SVN.
But here is my question. Can anyone confirm that what I just described is not so with Drupal core. Though Drush can download a fresh non CVS install of Drupal, It isn't able to upgrade Drupal core. So it seems like it still makes sense to not use Drush for downloading Drupal core, but stick to CVS for ease of upgrade. Can anyone confirm that is correct?
Shai
I was using the "vendor drop" method Andrew describes until recently. I just hated having to maintain it. So instead I hacked up a drush command that CAN update core: http://drupal.org/node/434944#comment-1939448 No idea when that issue will work its way into Drush itself, but the code I posted works for me. I'm certain it's not the best approach, but it works for me. :-) -- Larry Garfield larry@garfieldtech.com
Possibly. Or svn ignore. Unfortunately as far as I know you can't set a server-wide ignore list, so I've never bothered to set it up for all of our developers. (Some may have done it themselves. I'm not sure.) For my part I do nearly everything from the Linux command line ssh'ed into the dev server, so it's rarely an issue for me. :-) On Tuesday 24 November 2009 8:07:56 pm Shai Gluskin wrote:
Thanks Larry and Andrew!
Larry, can you use --exclude to deal with the OS X crap?
Shai
On Tue, Nov 24, 2009 at 8:38 PM, larry@garfieldtech.com <
larry@garfieldtech.com> wrote:
SVN isn't quite as bad for this as you make it out to be. :-) You can do:
svn add --force sites/all/modules
and it will recursively add any files under that directory that it doesn't already know about. Be careful of ._ files and similar crap that OS X may create. :-)
That's actually my usual workflow at this point. Drush dl to grab new modules, drush update to update a module, followed by the svn command above and then commit. It doesn't handle file deletes or major file reorganization, but those are quite rare.
And I almost never check out a module straight from CVS. If I want a dev version, you can tell Drush to get that for you.
--Larry Garfield
Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
-- Larry Garfield larry@garfieldtech.com
Thanks again to Larry and Andrew for their responses: really helpful! Just thought I'd let folks know that I've updated/upgraded the list of commands on the Drush handbook page <http://drupal.org/node/477684>. I've also created a printer friendly pdf of that list since since it's nice to have printed cheat sheets for command-line stuff. The pdf is at: http://drupal.org/files/drush-cheat-sheet.pdf The handbook page is at: http://drupal.org/node/477684 Best, Shai On Wed, Nov 25, 2009 at 12:56 AM, Larry Garfield <larry@garfieldtech.com>wrote:
Possibly. Or svn ignore. Unfortunately as far as I know you can't set a server-wide ignore list, so I've never bothered to set it up for all of our developers. (Some may have done it themselves. I'm not sure.) For my part I do nearly everything from the Linux command line ssh'ed into the dev server, so it's rarely an issue for me. :-)
On Tuesday 24 November 2009 8:07:56 pm Shai Gluskin wrote:
Thanks Larry and Andrew!
Larry, can you use --exclude to deal with the OS X crap?
Shai
On Tue, Nov 24, 2009 at 8:38 PM, larry@garfieldtech.com <
larry@garfieldtech.com> wrote:
SVN isn't quite as bad for this as you make it out to be. :-) You can do:
svn add --force sites/all/modules
and it will recursively add any files under that directory that it doesn't already know about. Be careful of ._ files and similar crap that OS X may create. :-)
That's actually my usual workflow at this point. Drush dl to grab new modules, drush update to update a module, followed by the svn command above and then commit. It doesn't handle file deletes or major file reorganization, but those are quite rare.
And I almost never check out a module straight from CVS. If I want a dev version, you can tell Drush to get that for you.
--Larry Garfield
Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
-- Larry Garfield larry@garfieldtech.com
The subversion way of doing this is to maintain two separate trees, one is the subversion repository and the other is the "vendor drop" (i.e. the latest version of Drupal core/contrib/whatever), kept in your file system. Each time you have updated your Drupal files (from cvs or using drush) you run the script: svn_load_dirs.pl (see http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html#svn.advanc... ) This will update your svn repository copy from your local drupal files, but what is important is that it will preserve the correct history in the svn repository so you can see what the changes are. It manages new files, orphans, and actually lets you tell it about renamed files. You can then update your website from the repository. If you need to roll it back, all the svn goodness is available to you. --Andrew On Tue, Nov 24, 2009 at 6:19 PM, Shai Gluskin <shai@content2zero.com> wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
When updating modules I've doing SVN del, CVS co, SVN add instead of simply CVS up because of orphaned and new files. SVN freaks out over orphans and the new files are just a pain since you need to SVN add for each one.
But I just installed Drush and I'm so excited about making all this easy. So I'm motivated to finally ask for help around this.
So if you commit CVS versions of contrib to SVN, what is your method for dealing with orphans and new files?
Thanks,
Shai
I use `cvs update -dP` to get the latest changes from drupal.org's CVS. Then I `svn add ...` and `svn rm ...` as needed. It's not so bad. I treat Drupal core as a vendor branch. I could do so with each module I use as well, but that just seems not worth the effort. Finally, I use svn:externals. So that when I'm working on multiple web sites I can make a patch to core or a module just once, and each website will get that change when I `svn update`. Combining CVS and svn this way is a little tricky, but comes in handy, too. -Dave On Tuesday 24 November 2009 15:19:04 Shai Gluskin wrote:
I get modules from d.o. from CVS, then I commit them to my own repository with SVN.
On 2009-11-25, at 9:49 PM, Dave Cohen wrote:
Finally, I use svn:externals.
Has anyone ever figured out a way to make svn:externals "sticky" a revision for production branches? The biggest issue I had with it was that there was no way to easily fetch the state of the project at a given revision, as externals just point to the HEAD of a path. --Andrew
On Thursday 26 November 2009 10:45:00 am Andrew Berry wrote:
On 2009-11-25, at 9:49 PM, Dave Cohen wrote:
Finally, I use svn:externals.
Has anyone ever figured out a way to make svn:externals "sticky" a revision for production branches? The biggest issue I had with it was that there was no way to easily fetch the state of the project at a given revision, as externals just point to the HEAD of a path.
--Andrew
Back when I was using externals, I had the modules we were external-ing cloned into a local SVN repo. To wit: /svn/drupalcone /modules /views /6.x-2.4 /6.x-2.5 /cck /6.x-2.1 /6.x-2.2 And then in my "new install image" directory, I had svn:external directives to the versions we wanted to use. Then when there was a new version of one of those modules, I'd add it to our repository, update the svn:external directive, and then re-export the base image into each of our in-development projects. Turns out, though, that was a ridiculous amount of work. :-) Plus I'd always be forgetting the right commands or paths or whatever because I'd only use them every so often. That's why I eventually threw that out and switched to all-drush. It's just easier to let each project's svn repo be totally independent and do all updating through Drush. It also means that the onus is not on me to update our base image every time there's a new release, which makes life easier for both me and the rest of our dev team that doesn't have to wait on my slow-arse self before they can update something. :-) -- Larry Garfield larry@garfieldtech.com
On Thu, Nov 26, 2009 at 10:45 AM, Andrew Berry <andrewberry@sentex.net> wrote:
On 2009-11-25, at 9:49 PM, Dave Cohen wrote:
Finally, I use svn:externals.
Has anyone ever figured out a way to make svn:externals "sticky" a revision for production branches? The biggest issue I had with it was that there was no way to easily fetch the state of the project at a given revision, as externals just point to the HEAD of a path.
You can specify a specific revision by appending @1234 to the external URI or adding -r1234 before the external URI external definition. The syntax changed (or was extended) in version 1.5. See http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html for details. -Craig
participants (7)
-
Andrew Berry -
Andrew Fountain -
Craig Forbes -
Dave Cohen -
Larry Garfield -
larry＠garfieldtech.com
-
Shai Gluskin