You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Fairchild, Gregory J - OASAM OCIO CTR" <Fa...@DOL.gov> on 2019/03/08 20:24:59 UTC
svn:E155007:None of the tarets are working copies
Hi,
I'm fairly new to subversion and new to this email listing. If this is not the correct format or avenue to report this problem, let me know.
Background: We're trying to eliminate all our Solaris 10 servers, so we need to migrate Subversion from a Solaris 10 server to Solaris 11. Current version of apache is 2.2.15 and Subversion is 1.6.11. I built a Solaris 11 server (11.3), installed and configured Subversion and Apache and had it up and running (after some initial errors regarding hook files, permissions, load module, etc). Under 11.3, we were using apache 2.2 (don't remember the rev) and Subversion 1.7. I did a dump/load from the old server to the new server so that users could test. All was working well. Then, before we switched over to the new server as production, 11.4 came out and we patched the new server to that. With 11.4, Oracle removed apache 2.2 and Subversion 1.7 altogether. So we now needed to get apache 2.4 and Subversion 1.9 working. I went through the install and configuration process. There was an initial problem with starting apache. I opened a case with Oracle and they were able to help resolve it by having me add the 'LoadModule dav_module libexec/mod_dav.so' to httpd.conf. I also had the following errors:
[cid:image005.png@01D4CA05.AF2546D0]
[cid:image006.png@01D4CA05.AF2546D0]
I was able to correct for these errors by changing from using svnuser:svngrp to webservd:webservd and changing the owner on all the files in the repository and then restarting apache.
Problem: After working through the problems above, Oracle said they really couldn't go further with support as it was outside of their scope. The problem I have now is:
Checking in new files still given the error.
[cid:image012.png@01D4D29F.B9EF5590]
The commit seems to be working, but the post-commit does not.
User is using Tortoise vs 1.7.15. I have had another user try with Tortoise 1.11. I have had the user try to create a new working copy and still get the same error.
In addition to the LoadModule above, I am also loading the following:
# Subversion required modules
LoadModule dav_svn_module libexec/mod_dav_svn.so
LoadModule authz_svn_module libexec/mod_authz_svn.so
In addition to changing the user/group, other httpd.conf changes are:
# Subversion add-ons - Greg Fairchild 02/13/19
<Location /subversion>
DAV svn
SVNPath /rpool/svn/subversion/repository
#
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /rpool/svn/subversion/repository/conf/svn-auth-file
Require valid-user
</Location>
Post-commit looks like this:
#!/bin/sh
REPOS="$1"
REV="$2"
/usr/bin/svn update /var/apache2/2.4/htdocs/ >> /rpool/svn/subversion/repository/logs/post-commit.log
Any help will be appreciated. Thanks
Greg
[cid:image001.png@01D4D5AE.347D26F0]
Greg Fairchild
U.S. Department of Labor
Office of the Chief Information Officer
Enterprise IT Operations | Senior Network/Systems Engineer III (Contractor)
fairchild.gregory@dol.gov<ma...@dol.gov>
801-233-4992
Re: svn:E155007:None of the tarets are working copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Fairchild, Gregory J - OASAM OCIO CTR wrote on Mon, 11 Mar 2019 22:22 +00:00:
> "You can avoid this by throwing a mutex around the svn(1) call (see
> flock(1))." Being that I'm pretty new to subversion, you lost me here.
It's possible for the post-commit process of rN to run in parallel to
the post-commit process of rN+1. If that happens, it's possible for the
'svn update' processes launched by the two post-commit processes to
run in parallel. If that happens, at least one of the two 'svn update'
processes will error out, probably with E155004 ("working copy is
already locked").
In short, post-commit hooks need to be written to account for the fact
that Subversion does not sequence or serialize hook invocations. In
your case, that means changing «svn update $args» to «flock … svn update
$args» in order to ensure that concurrent post-commit hook runs will run
'svn update' in sequence, rather than in parallel. (The runs might
_still_ be out of order — I mean, rN+1 before rN — but your hook is
indifferent to the $REV parameter.)
flock(1) is simply a program that takes a lock, aka a mutex. It's not
standardized so you'll have to look up the flags on your system.
Cheers,
Daniel
P.S. Having said all that, look up svnpubsub and svnwcsub in tools/ in
the source tree. They do basically what you are after with that hook.
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: Saturday, March 09, 2019 7:22 AM
> To: Ryan Schmidt; Fairchild, Gregory J - OASAM OCIO CTR
> Cc: Subversion Users
> Subject: Re: svn:E155007:None of the tarets are working copies
...
> While I'm here, let me point out that post-commit runs for different
> revisions may happen in parallel or even out of order. In this case, the
> worst that could happen is that the svn(1) invocation in the second run
> will error out with E155004 and the error will be marshalled back to the
> user who committed. You can avoid this by throwing a mutex around the
> svn(1) call (see flock(1)).
RE: svn:E155007:None of the tarets are working copies
Posted by "Fairchild, Gregory J - OASAM OCIO CTR" <Fa...@DOL.gov>.
Hi Daniel,
Thanks for the feedback.
As I responded to Ryan, the directory exists and the log file is being written to.
I'll look at moving the location. Appreciate the advice on that.
"You can avoid this by throwing a mutex around the svn(1) call (see flock(1))." Being that I'm pretty new to subversion, you lost me here.
Greg
-----Original Message-----
From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
Sent: Saturday, March 09, 2019 7:22 AM
To: Ryan Schmidt; Fairchild, Gregory J - OASAM OCIO CTR
Cc: Subversion Users
Subject: Re: svn:E155007:None of the tarets are working copies
Ryan Schmidt wrote on Sat, 09 Mar 2019 08:43 +00:00:
> On Mar 8, 2019, at 14:24, Fairchild, Gregory J - OASAM OCIO CTR wrote:
> > Post-commit looks like this:
> > #!/bin/sh
> > REPOS="$1"
> > REV="$2"
> > /usr/bin/svn update /var/apache2/2.4/htdocs/ >> /rpool/svn/subversion/repository/logs/post-commit.log
> >
> > Any help will be appreciated. Thanks
>
> The first question I would ask is: Does the directory
> /rpool/svn/subversion/repository/logs exist? If not, create it.
That should solve the immediate problem, but you should plan to move
that directory to another place.
/rpool/svn/subversion/repository is a repository, so you shouldn't
create files or directories under it except those specifically described
in the documentation, for forward compatibility with future versions of
Subversion (which may start using $REPOS_DIR/logs/ in some way or
another).
While I'm here, let me point out that post-commit runs for different
revisions may happen in parallel or even out of order. In this case, the
worst that could happen is that the svn(1) invocation in the second run
will error out with E155004 and the error will be marshalled back to the
user who committed. You can avoid this by throwing a mutex around the
svn(1) call (see flock(1)).
Cheers,
Daniel
Re: svn:E155007:None of the tarets are working copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Sat, 09 Mar 2019 08:43 +00:00:
> On Mar 8, 2019, at 14:24, Fairchild, Gregory J - OASAM OCIO CTR wrote:
> > Post-commit looks like this:
> > #!/bin/sh
> > REPOS="$1"
> > REV="$2"
> > /usr/bin/svn update /var/apache2/2.4/htdocs/ >> /rpool/svn/subversion/repository/logs/post-commit.log
> >
> > Any help will be appreciated. Thanks
>
> The first question I would ask is: Does the directory
> /rpool/svn/subversion/repository/logs exist? If not, create it.
That should solve the immediate problem, but you should plan to move
that directory to another place.
/rpool/svn/subversion/repository is a repository, so you shouldn't
create files or directories under it except those specifically described
in the documentation, for forward compatibility with future versions of
Subversion (which may start using $REPOS_DIR/logs/ in some way or
another).
While I'm here, let me point out that post-commit runs for different
revisions may happen in parallel or even out of order. In this case, the
worst that could happen is that the svn(1) invocation in the second run
will error out with E155004 and the error will be marshalled back to the
user who committed. You can avoid this by throwing a mutex around the
svn(1) call (see flock(1)).
Cheers,
Daniel
RE: svn:E155007:None of the tarets are working copies
Posted by "Fairchild, Gregory J - OASAM OCIO CTR" <Fa...@DOL.gov>.
Hi Ryan,
Thanks for the feedback.
Logs directory and .log file exist.
root@wsu3a:~# ls -ld /rpool/svn/subversion/repository/logs
drwxr-xr-x 2 webservd webservd 3 Mar 4 18:33 /rpool/svn/subversion/repository/logs
root@wsu3a:~# ls -l /rpool/svn/subversion/repository/logs
total 9
-rw-r--r-- 1 webservd webservd 465 Mar 5 14:34 post-commit.log
root@wsu3a:~#
Permissions should be fine since it's writing to the file. I actually added some debug (echo $REPOS and $REV to the log file) to the post-commit script to try to see what the script environment looks like. Here's a sample of what's in the post-commit.log:
/rpool/svn/subversion/repository
11748
Skipped 'var/apache2/2.4/htdocs'
/rpool/svn/subversion/repository
11749
Skipped 'var/apache2/2.4/htdocs'
/rpool/svn/subversion/repository
11750
Skipped 'var/apache2/2.4/htdocs'
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2019@ryandesign.com]
Sent: Saturday, March 09, 2019 1:44 AM
To: Fairchild, Gregory J - OASAM OCIO CTR
Cc: Subversion Users
Subject: Re: svn:E155007:None of the tarets are working copies
On Mar 8, 2019, at 14:24, Fairchild, Gregory J - OASAM OCIO CTR wrote:
> I’m fairly new to subversion and new to this email listing. If this is not the correct format or avenue to report this problem, let me know.
Welcome!
> Background: We’re trying to eliminate all our Solaris 10 servers, so we need to migrate Subversion from a Solaris 10 server to Solaris 11. Current version of apache is 2.2.15 and Subversion is 1.6.11. I built a Solaris 11 server (11.3), installed and configured Subversion and Apache and had it up and running (after some initial errors regarding hook files, permissions, load module, etc). Under 11.3, we were using apache 2.2 (don’t remember the rev) and Subversion 1.7. I did a dump/load from the old server to the new server so that users could test. All was working well. Then, before we switched over to the new server as production, 11.4 came out and we patched the new server to that. With 11.4, Oracle removed apache 2.2 and Subversion 1.7 altogether. So we now needed to get apache 2.4 and Subversion 1.9 working. I went through the install and configuration process. There was an initial problem with starting apache. I opened a case with Oracle and they were able to help resolve it by having me add the ‘LoadModule dav_module libexec/mod_dav.so’ to httpd.conf. I also had the following errors:
>
> <image002.png>
Transcribing the text so that those who don't wish to load images can read it, and so that it can be searched, this is a TortoiseSVN dialog reading:
Subversion reported an error:
DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent
At least one property change failed; repository is unchanged
Error setting property 'svn:log':
Can't open file '/rpool/svn/subversion/repository/db/write-lock': Permission denied
> <image003.png>
This is a TortoiseSVN "Commit Failed!" dialog saying:
Command Commit
Error Commit failed (details follow):
Error Can't open file '/rpool/svn/subversion/repository/db/txn-current-lock':
Error Permission denied
Completed!
The operation failed.
> I was able to correct for these errors by changing from using svnuser:svngrp to webservd:webservd and changing the owner on all the files in the repository and then restarting apache.
Ok great! It's certainly not uncommon to discover, when transferring services from one server to another, that ownership or permissions need to be adjusted to what the new server expects. Glad you got it figured out.
> Problem: After working through the problems above, Oracle said they really couldn’t go further with support as it was outside of their scope. The problem I have now is:
>
> Checking in new files still given the error.
> <image004.png>
This TortoiseSVN "Commit Finished!" dialog reads:
Command Commit
Adding C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pkb
Adding C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pks
Sending content C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pkb
Sending content C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pks
Completed At revision: 11746
Error post-commit hook failed (exit code 1) with output:
Error /rpool/svn/subversion/repository/hooks/post-commit[51]: /rpool/svn/subversion/repository/logs/post-commit.log: cannot create [No such file or directory]
> The commit seems to be working, but the post-commit does not.
> Post-commit looks like this:
> #!/bin/sh
> REPOS="$1"
> REV="$2"
> /usr/bin/svn update /var/apache2/2.4/htdocs/ >> /rpool/svn/subversion/repository/logs/post-commit.log
>
> Any help will be appreciated. Thanks
The first question I would ask is: Does the directory /rpool/svn/subversion/repository/logs exist? If not, create it.
If it already exists, then check if its ownership and permissions are such that the webservd user/group can create the post-commit.log file inside it.
If the post-commit.log file exists, check its permissions and ownership as well.
Re: svn:E155007:None of the tarets are working copies
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 8, 2019, at 14:24, Fairchild, Gregory J - OASAM OCIO CTR wrote:
> I’m fairly new to subversion and new to this email listing. If this is not the correct format or avenue to report this problem, let me know.
Welcome!
> Background: We’re trying to eliminate all our Solaris 10 servers, so we need to migrate Subversion from a Solaris 10 server to Solaris 11. Current version of apache is 2.2.15 and Subversion is 1.6.11. I built a Solaris 11 server (11.3), installed and configured Subversion and Apache and had it up and running (after some initial errors regarding hook files, permissions, load module, etc). Under 11.3, we were using apache 2.2 (don’t remember the rev) and Subversion 1.7. I did a dump/load from the old server to the new server so that users could test. All was working well. Then, before we switched over to the new server as production, 11.4 came out and we patched the new server to that. With 11.4, Oracle removed apache 2.2 and Subversion 1.7 altogether. So we now needed to get apache 2.4 and Subversion 1.9 working. I went through the install and configuration process. There was an initial problem with starting apache. I opened a case with Oracle and they were able to help resolve it by having me add the ‘LoadModule dav_module libexec/mod_dav.so’ to httpd.conf. I also had the following errors:
>
> <image002.png>
Transcribing the text so that those who don't wish to load images can read it, and so that it can be searched, this is a TortoiseSVN dialog reading:
Subversion reported an error:
DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent
At least one property change failed; repository is unchanged
Error setting property 'svn:log':
Can't open file '/rpool/svn/subversion/repository/db/write-lock': Permission denied
> <image003.png>
This is a TortoiseSVN "Commit Failed!" dialog saying:
Command Commit
Error Commit failed (details follow):
Error Can't open file '/rpool/svn/subversion/repository/db/txn-current-lock':
Error Permission denied
Completed!
The operation failed.
> I was able to correct for these errors by changing from using svnuser:svngrp to webservd:webservd and changing the owner on all the files in the repository and then restarting apache.
Ok great! It's certainly not uncommon to discover, when transferring services from one server to another, that ownership or permissions need to be adjusted to what the new server expects. Glad you got it figured out.
> Problem: After working through the problems above, Oracle said they really couldn’t go further with support as it was outside of their scope. The problem I have now is:
>
> Checking in new files still given the error.
> <image004.png>
This TortoiseSVN "Commit Finished!" dialog reads:
Command Commit
Adding C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pkb
Adding C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pks
Sending content C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pkb
Sending content C:\Users\kto\Downloads\working_folder\CalendarICWF\PLSQL\edit - Copy - Copy.pks
Completed At revision: 11746
Error post-commit hook failed (exit code 1) with output:
Error /rpool/svn/subversion/repository/hooks/post-commit[51]: /rpool/svn/subversion/repository/logs/post-commit.log: cannot create [No such file or directory]
> The commit seems to be working, but the post-commit does not.
> Post-commit looks like this:
> #!/bin/sh
> REPOS="$1"
> REV="$2"
> /usr/bin/svn update /var/apache2/2.4/htdocs/ >> /rpool/svn/subversion/repository/logs/post-commit.log
>
> Any help will be appreciated. Thanks
The first question I would ask is: Does the directory /rpool/svn/subversion/repository/logs exist? If not, create it.
If it already exists, then check if its ownership and permissions are such that the webservd user/group can create the post-commit.log file inside it.
If the post-commit.log file exists, check its permissions and ownership as well.