--svnsync and --svncommit not working
bear_beavis - June 23, 2009 - 07:22
| Project: | Drush |
| Version: | All-Versions-HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | svn svnsync |
Description
Hi,
I got some problem with drush updating site when using --svnsync and/or --svncommit.
When i use : /drush.php -r /var/www/mysite.com/trunk/drupal updatecode --svnsync --verbose views
update works but --svnsync has no effect.
Trying to figure out what was going on with commands/pm/version_control/svn.inc, i found that svn 'info/add/commit/remove' was called but without the full path of modules directory.
Please can you take a look on attached patch.
Thanks.
| Attachment | Size |
|---|---|
| svn-ok.patch | 1.46 KB |
#1
Got to this issue as well, patch works, although the same change was missing in the
<?phpversion_control_post_install()
?>
Attached is the same patch with this other slight modification. Tried it and it works OK.
+1 for this to have it working ASAP.
Patch's against CVS
#2
I'm having the same problem even with the patch across several servers. With verbose on, I see that svn.inc gets included but no svn commands are executed. Maybe it's my setup: I have d6.13 under CVS and the sites dir under SVN. Does the entire install need to be under SVN for this to work?
#3
@boinkster, have you tried the latest patch in this issue?
#4
Yes, to no avail. Also tried on a test install that fully under SVN (not just files). Same thing, I can see that svn.inc is included but no SVN commands happen - no errors either:
drush dl og --svnsync
Initialized Drupal 6.13 root directory at C:/xampplite/htdocs/svntest [notice]
Initialized Drupal site default at sites/default [notice]
Including non-version specific file : [notice]
C:\xampplite\drush\commands/pm/package_handler/wget.inc
Including non-version specific file : [notice]
C:\xampplite\drush\commands/pm/version_control/svn.inc
Using destination directory [notice]
C:/xampplite/htdocs/svntest/sites/all/modules/
Downloading project og ... [notice]
Executing: wget http://ftp.drupal.org/files/projects/og-6.x-1.3.tar.gz
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files\GnuWin32/etc/wgetrc
--2009-07-10 11:56:22-- http://ftp.drupal.org/files/projects/og-6.x-1.3.tar.gz
Resolving ftp.drupal.org... 140.211.166.134
Connecting to ftp.drupal.org|140.211.166.134|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 259100 (253K) [application/x-gzip]
Saving to: `og-6.x-1.3.tar.gz'
0K .......... .......... .......... .......... .......... 19% 17.3K 12s
50K .......... .......... .......... .......... .......... 39% 38.6K 6s
100K .......... .......... .......... .......... .......... 59% 34.0K 4s
150K .......... .......... .......... .......... .......... 79% 31.2K 2s
200K .......... .......... .......... .......... .......... 98% 13.4K 0s
250K ... 100% 5.56K=12s
2009-07-10 11:56:34 (21.9 KB/s) - `og-6.x-1.3.tar.gz' saved [259100/259100]
Downloading og-6.x-1.3.tar.gz was successful. [notice]
Md5 checksum of og-6.x-1.3.tar.gz verified. [notice]
Executing: gzip -d og-6.x-1.3.tar.gz
Executing: tar -xf og-6.x-1.3.tar -C "C:/xampplite/htdocs/svntest/sites/all/modules/"
Calling unlink(og-6.x-1.3.tar)
Project og (6.x-1.3) downloaded to ?[0;33m?[1m[success]?[0m
C:/xampplite/htdocs/svntest/sites/all/modules/.
Command dispatch complete [notice]
If I call --version-control=svn AND --svnsync it throws these errors:
drush dl ad --version-control=svn --svnsync
Initialized Drupal 6.13 root directory at C:/xampplite/htdocs/svntest [notice]
Initialized Drupal site default at sites/default [notice]
Including non-version specific file : [notice]
C:\xampplite\drush\commands/pm/package_handler/wget.inc
No was set for including the version_control engine 1. ?[31m?[1m[error]?[0m
Using destination directory [notice]
C:/xampplite/htdocs/svntest/sites/all/modules/
Downloading project ad ... [notice]
Executing: wget http://ftp.drupal.org/files/projects/ad-6.x-2.0.tar.gz
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files\GnuWin32/etc/wgetrc
--2009-07-10 14:23:08-- http://ftp.drupal.org/files/projects/ad-6.x-2.0.tar.gz
Resolving ftp.drupal.org... 140.211.166.134
Connecting to ftp.drupal.org|140.211.166.134|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 125531 (123K) [application/x-gzip]
Saving to: `ad-6.x-2.0.tar.gz'
0K .......... .......... .......... .......... .......... 40% 11.5K 6s
50K .......... .......... .......... .......... .......... 81% 21.2K 2s
100K .......... .......... .. 100% 15.0K=8.2s
2009-07-10 14:23:17 (15.0 KB/s) - `ad-6.x-2.0.tar.gz' saved [125531/125531]
Downloading ad-6.x-2.0.tar.gz was successful. [notice]
Md5 checksum of ad-6.x-2.0.tar.gz verified. [notice]
Executing: gzip -d ad-6.x-2.0.tar.gz
Executing: tar -xf ad-6.x-2.0.tar -C "C:/xampplite/htdocs/svntest/sites/all/modules/"
Calling unlink(ad-6.x-2.0.tar)
Project ad (6.x-2.0) downloaded to ?[0;33m?[1m[success]?[0m
C:/xampplite/htdocs/svntest/sites/all/modules/.
Fatal error: Call to undefined function version_control_post_install() in C:\xampplite\drush\commands\pm\pm.drush.inc on line 817
Drush command could not be completed. ?[31m?[1m[error]?[0m
These were on my local windows box but I get the same behavior on remote 'nix server. Not sure where to troubleshoot. Am I using the correct syntax?
#5
You are getting the same error on the linux machine? even the Fatal error: Call to undefined function version_control_post_install()?. I'd troubleshoot 'nix definitely, as windows i not 100% supported by drush.
#6
Okay, not the fatal error, but --svnsync doesn't run:
[user1@140997-web1 public_html]$ drush dl services --version-control=svn --svnsync
Initialized Drupal 6.13 root directory at /home/user1/public_html [notice]
Initialized Drupal site default at sites/default [notice]
Including non-version specific file : [notice]
/home/user1/drush/commands/pm/package_handler/wget.inc
Including non-version specific file : [notice]
/home/user1/drush/commands/pm/version_control/svn.inc
Using destination directory [notice]
/home/user1/public_html/sites/all/modules/
Downloading project services ... [notice]
Executing: wget http://ftp.drupal.org/files/projects/services-6.x-2.x-dev.tar.gz
--18:46:53-- http://ftp.drupal.org/files/projects/services-6.x-2.x-dev.tar.gz
=> `services-6.x-2.x-dev.tar.gz'
Resolving ftp.drupal.org... 64.50.236.52
Connecting to ftp.drupal.org|64.50.236.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30,990 (30K) [application/x-gzip]
0K .......... .......... .......... 100% 234.80 KB/s
18:46:54 (234.80 KB/s) - `services-6.x-2.x-dev.tar.gz' saved [30990/30990]
Downloading services-6.x-2.x-dev.tar.gz was successful. [notice]
Md5 checksum of services-6.x-2.x-dev.tar.gz verified. [notice]
Executing: gzip -d services-6.x-2.x-dev.tar.gz
Executing: tar -xf services-6.x-2.x-dev.tar -C "/home/user1/public_html/sites/all/modules/"
Calling unlink(services-6.x-2.x-dev.tar)
Project services (6.x-2.x-dev) downloaded to [success]
/home/user1/public_html/sites/all/modules/.
Command dispatch complete [notice]
It is the same without the version-control call.
How would I track this down?
#7
I think I know what might be happening. I only tried this patch using dl or even updatecode command using a module that was already present in the SVN repository, and then, the code properly finds the .svn directory inside it. If you, which might be the case, execute a dl command with a new module being downloaded, I am almost possitive the function that validate if the source is being versioned by SVN will failed. I believe the check of .svn has to be made with the parent directory rather than the project one. I'll take a look at this patch and maybe improve it
#8
I confirmed this on a third server (CentOS). With the patch applied to HEAD, --svnsync works with updatecode but not with dl. I'll review the other servers on Monday to confirm.
#9
I have tried everything and I can't get --svnsync or --svncommit to work with dl or updatecode to save my life.
I've tried the All-Versions-HEAD on both CentOS and MAMP stack: no dice.
#10
I had this issue in mind for a while. After noticing that dl was not working with the patch but updatecode was I looked at the patch and realized we thought things wrong. The version_control_is_versioned() should be checked against the path, and not against the actual project. Path would be the parent, which would be versioned for both new and updated code.
The part of the patch that prepends the path to the svn commands, I think it's still right.
Attached is a patch which I think fixes most issues.
#11
I had this problem too, and the patch in #10 fixed it for me.
#12
looks reasonable. committed.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.