Re: Preserve timestamps while creating tag with SVN copy
Steve Cohen wrote:
I would like to be able to create a tag using the SVN copy command so
that the timestamps on the files in the destination are the same as
those in the source.
there are no individual timestamps on files in the repository, only
one timestamp on the revision as a whole.
If you are talking about the timestamp of the commit / tag though ...
That can easyly be changed to match the tag source using svn propset
svn:date --revprop -r tagrevision date repopath.
Be aware that the svn -r {date} ... syntax will no longer work
properly if you do so (because it relies on the revision timestamps to
be ordered).
And you will need a pre-revprop-change hook to allows revprop changes.
--
Lorenz
Re: How to revert a --record-only svn merge before a commit
On 29/10/13 05:38, Zk W wrote: Hi All We use SVN 1.6 How do we perform a svn merge revert of a revision number that is --record-only in linux shell before a svn commit ? We perform svn merge --record-only -c 1234 http://testsomething.com We like to revert that step. Thank you Sincerely That only changes the svn:mergeinfo property, so I would suggest editing it. Since you did not have a target in the command you showed us I guess it was the current directory (unless you simply omitted it for simplicity), which I hope is the root of your WC (it should always be the root of your WC, it makes things much easier). So, in the root of your WC run this command svn pe svn:mergeinfo . and delete the info for revision 1234 (which again I guess it's not the real one :-) Hope this helps. Giulio
Re: How to revert a --record-only svn merge before a commit
On 29.10.2013 10:10, Giulio Troccoli wrote: On 29/10/13 05:38, Zk W wrote: Hi All We use SVN 1.6 How do we perform a svn merge revert of a revision number that is --record-only in linux shell before a svn commit ? We perform svn merge --record-only -c 1234 http://testsomething.com We like to revert that step. Thank you Sincerely That only changes the svn:mergeinfo property, so I would suggest editing it. Since you did not have a target in the command you showed us I guess it was the current directory (unless you simply omitted it for simplicity), which I hope is the root of your WC (it should always be the root of your WC, it makes things much easier). So, in the root of your WC run this command svn pe svn:mergeinfo . and delete the info for revision 1234 (which again I guess it's not the real one :-) Hope this helps. Instead of editing mergeinfo, which is always a bad idea, just revert the directory changes: svn revert . This will revert the property changes on the repository, including svn:mergeinfo. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: How to revert a --record-only svn merge before a commit
On Tue, Oct 29, 2013 at 09:10:45AM +, Giulio Troccoli wrote: On 29/10/13 05:38, Zk W wrote: Hi All We use SVN 1.6 How do we perform a svn merge revert of a revision number that is --record-only in linux shell before a svn commit ? We perform svn merge --record-only -c 1234 http://testsomething.com We like to revert that step. Thank you Sincerely That only changes the svn:mergeinfo property, so I would suggest editing it. Since you did not have a target in the command you showed us I guess it was the current directory (unless you simply omitted it for simplicity), which I hope is the root of your WC (it should always be the root of your WC, it makes things much easier). So, in the root of your WC run this command svn pe svn:mergeinfo . and delete the info for revision 1234 (which again I guess it's not the real one :-) Hope this helps. Giulio I would advise against editing or deleting mergeinfo. Instead, run the same merge in reverse: svn merge --record-only -c -1234 http://testsomething.com Note the minus in front of 1234. This approach will also fix up subtree mergeinfo, if any.
Re: How to revert a --record-only svn merge before a commit
On 29/10/13 10:43, Stefan Sperling wrote: On Tue, Oct 29, 2013 at 09:10:45AM +, Giulio Troccoli wrote: On 29/10/13 05:38, Zk W wrote: Hi All We use SVN 1.6 How do we perform a svn merge revert of a revision number that is --record-only in linux shell before a svn commit ? We perform svn merge --record-only -c 1234 http://testsomething.com We like to revert that step. Thank you Sincerely That only changes the svn:mergeinfo property, so I would suggest editing it. Since you did not have a target in the command you showed us I guess it was the current directory (unless you simply omitted it for simplicity), which I hope is the root of your WC (it should always be the root of your WC, it makes things much easier). So, in the root of your WC run this command svn pe svn:mergeinfo . and delete the info for revision 1234 (which again I guess it's not the real one :-) Hope this helps. Giulio I would advise against editing or deleting mergeinfo. Instead, run the same merge in reverse: svn merge --record-only -c -1234 http://testsomething.com Note the minus in front of 1234. This approach will also fix up subtree mergeinfo, if any. Ah yes, of course. I didn't use the merge command because the OP said how to reverse before the commit and there could be other merges that he wants to keep. I didn't think of using --record-only with a reverse merge, but it make sense Giulio
RE: malformed argument re-use in svn_client_url_from_path2
Hi Ben and Bert,
thanks for the feedback. The crashing problem was in fact poor handling of
memory pools, as Bert suggested, and now it is fixed. There is no bug in
svn_client_url_from_path2.
Best,
Andre.
-Original Message-
From: Maximo, Andre (GE Global Research)
Sent: Friday, October 25, 2013 10:31 AM
To: 'Ben Reser'; Bert Huijben; users@subversion.apache.org
Subject: RE: malformed argument re-use in svn_client_url_from_path2
Thanks Bert again and Ben for joining.
I am handling the error in the code (I just omitted for clarity), but the
execution I am describing never throws an error. I also have tested passing the
same pool and using the GetBuffer() method, but down to the same segfault at
the svn_client_url_from_path2() call. Here is the updated code:
void CVCS::svnURLPath(CString urlPath, const CString fullPath)
{
CError svnErr;
const char *url = NULL;
CString path(fullPath);
svnErr.err = svn_client_url_from_path2(url, path.GetBuffer(), m_svn_ctx,
m_svn_pool, m_svn_pool);
if (svnErr.err != NULL)
throw svnErr;
if (url != NULL)
urlPath = CString(url);
}
When I pass fullPath = C:\\WD, an error is thrown with the message:
'C:\WD' is not a working copy (ok here, don't think it was a fluke). I then
checkout from the repository to it and update it using SVN api (all ok), now
C:\WD exists and when I call svnURLPath on it, the url is returned fine.
I try to find another path inside it, like fullPath = C:\\WD\\History
Items\\Documents\\File.txt. The behavior I expect is an error thrown saying
this path does not exist in the repository (because it really still doesn't),
but the execution just crashes inside svnURLPath, more specifically in the
svn_client_url_from_path2(). (I also tested with a more simple fullPath =
C:\\WD\\Test and crashes the same). Looking at this function I notice the
svn_dirent_get_absolute() call with the same path_or_url argument and jumped
to the conclusion that this was the problem. But it may well be the second
function svn_wc__node_get_url(), getting lost with an unknown path. I am not,
maybe it is a Windows specific problem?
Best,
Andre.
-Original Message-
From: Ben Reser [mailto:b...@reser.org]
Sent: Thursday, October 24, 2013 6:36 PM
To: Maximo, Andre (GE Global Research); Bert Huijben;
users@subversion.apache.org
Subject: Re: malformed argument re-use in svn_client_url_from_path2
On 10/24/13 11:44 AM, Maximo, Andre (GE Global Research) wrote:
void CVCS::svnURLPath(CString urlPath, const CString fullPath)
{
apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
const char *url = NULL;
svn_error_t *err = svn_client_url_from_path2(url, fullPath, m_svn_ctx,
m_svn_pool, local_pool);
if (url != NULL)
urlPath = CString(url);
svn_pool_destroy(local_pool);
}
Looking at this code more closely I see that you're passing
svn_client_url_from_path2() a pointer to a CString class. I'm guessing you're
using MFC based on that class name. So I suspect what you really needed on the
svn_client_url_from_path2() call is:
svn_error_t *err = svn_client_url_from_path2(url, fullPath-GetBuffer(),
m_svn_ctx, m_svn_pool, local_pool);
Bert's and my earlier points about the lack of checking for errors still
stands. In this case our particular implementation is good enough that it
wouldn't break your code since url will still be NULL. But we don't promise
that.
I think the fact that it's succeeding for you when passing a valid path is a
fluke and failing when passing a non-existent path is just a fluke.
Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
An Apache configuration serving Subversion repositories, with mod_wsgi 3.3 authentication provider, causes per request segfaults in Apache 2.2.22 with mod_dav_svn from Subversion 1.7.13. If mod_wsgi auth directives are removed from the Apache configuration, then repositories are served properly. The identical configuration with Subversion 1.7.9 (from https://launchpad.net/~svn/+archive/ppa) and the stock Ubuntu 12.04 Subversion 1.6.17 works as expected with mod_wsgi auth directives in place. Environment: Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-55-virtual x86_64) Apache/2.2.22 (Ubuntu) DAV/2 SVN/1.7.13 mod_wsgi/3.3 Python/2.7.3 Subversion 1.7.13 (http://subversion.apache.org/packages.html Ubuntu Linux: WANdisco) Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_worker_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgid_module (shared) dav_module (shared) dav_svn_module (shared) authz_svn_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) mime_module (shared) negotiation_module (shared) reqtimeout_module (shared) setenvif_module (shared) status_module (shared) wsgi_module (shared) httpd.conf: CoreDumpDirectory /tmp/apache2-gdb-dump LogLevel debug listen 8080 VirtualHost *:8080 ServerName svn.mydomain.org Location /projects DAV svn SVNParentPath /var/lib/svn SVNListParentPath Off WSGIAccessScript /var/lib/wsgi/access.wsgi /Location /VirtualHost VirtualHost *:80 ServerName svn.mydomain.org Location /projects DAV svn SVNParentPath /var/lib//svn SVNListParentPath Off AuthType Basic AuthName WSGIAuth AuthBasicProvider wsgi WSGIAuthUserScript /var/lib/wsgi/access.wsgi Require valid-user WSGIAuthGroupScript /var/lib/wsgi/access.wsgi Require group authorized /Location /VirtualHost access.wsgi: import logging logging.basicConfig(format='%(asctime)s %(levelname)s:%(message)s', level=logging.DEBUG) LOG = logging.getLogger(__name__) def allow_access(*args, **kwargs): LOG.debug(mod_wsgi allow_access called.) return True def check_password(*args, **kwargs): LOG.debug(mod_wsgi check_password called.) return True def groups_for_user(*args, **kwargs): LOG.debug(mod_wsgi groups_for_user called.) return [“authorized”] Apache error log: [Tue Oct 29 11:12:45 2013] [warn] mod_wsgi: Compiled for Python/2.7.2+. [Tue Oct 29 11:12:45 2013] [warn] mod_wsgi: Runtime using Python/2.7.3. [Tue Oct 29 11:12:45 2013] [notice] Apache/2.2.22 (Ubuntu) DAV/2 SVN/1.7.13 mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations [Tue Oct 29 11:12:45 2013] [info] Server built: Jul 12 2013 13:37:15 [Tue Oct 29 11:12:45 2013] [debug] worker.c(1757): AcceptMutex: sysvsem (default: sysvsem) [Tue Oct 29 11:12:45 2013] [info] mod_wsgi (pid=11326): Initializing Python. [Tue Oct 29 11:12:45 2013] [info] mod_wsgi (pid=11325): Initializing Python. [Tue Oct 29 11:12:45 2013] [info] mod_wsgi (pid=11326): Attach interpreter ''. [Tue Oct 29 11:12:45 2013] [info] mod_wsgi (pid=11325): Attach interpreter ''. [Tue Oct 29 11:12:55 2013] [debug] mod_deflate.c(615): [client 129.59.105.145] Zlib: Compressed 481 to 328 : URL /projects/somerepo [Tue Oct 29 11:12:59 2013] [info] [client elided] mod_wsgi (pid=11326, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 11:12:59 2013] [info] [client elided] mod_wsgi (pid=11325, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 11:13:00 2013] [notice] child pid 11325 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 11:13:00 2013] [notice] child pid 11326 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 11:13:01 2013] [info] mod_wsgi (pid=11384): Initializing Python. [Tue Oct 29 11:13:01 2013] [info] mod_wsgi (pid=11384): Attach interpreter ''. [Tue Oct 29 11:13:19 2013] [info] mod_wsgi (pid=11412): Initializing Python. [Tue Oct 29 11:13:19 2013] [info] mod_wsgi (pid=11412): Attach interpreter ''. [Tue Oct 29 11:13:21 2013] [info] [client elided] mod_wsgi (pid=11384, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 11:13:21 2013] [info] [client elided] mod_wsgi (pid=11412, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 11:13:22 2013] [notice] child pid 11384 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 11:13:22 2013] [notice] child pid 11412 exit signal Segmentation fault (11), possible coredump in
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
On 29.10.2013 13:45, Howard, Larry P wrote: An Apache configuration serving Subversion repositories, with mod_wsgi 3.3 authentication provider, causes per request segfaults in Apache 2.2.22 with mod_dav_svn from Subversion 1.7.13. If mod_wsgi auth directives are removed from the Apache configuration, then repositories are served properly. What if you remove the SVN configuration and just set up a plain server with WSGI authentication? Given your description of the issue, and the fact that the WSGI process crashes, I'd sooner suspect mod_wsgi or your access script, even though I can't see anything obviously wrong with them. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Svndumpfilter
Hi Guys, I am trying to extract one folder B from the repository Current_repo and create a separate reposiotry. The followed the below steps but nothing has been loaded to the new repository new_repo. * svnadmin dump /var/svn/data/Current_repo repo.dump * cat repo.dump | svndumpfilter include --drop-empty-revs --renumber-revs http://localhost/svn/Current_repo/B sv.dump * svnadmin load /var/svn/data/new_repo sv.dump Thanks Regards, Anup T S __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
Re: Svndumpfilter
On Tue, Oct 29, 2013 at 08:05:37PM +0530, Somashekarappa, Anup (CWM-NR) wrote: Hi Guys, I am trying to extract one folder B from the repository Current_repo and create a separate reposiotry. The followed the below steps but nothing has been loaded to the new repository new_repo. * svnadmin dump /var/svn/data/Current_repo repo.dump * cat repo.dump | svndumpfilter include --drop-empty-revs --renumber-revs http://localhost/svn/Current_repo/B sv.dump I think you have a usage error. $ svndumpfilter help include include: Filter out nodes without given prefixes from dumpstream. usage: svndumpfilter include PATH_PREFIX... ^^^ What PATH_PREFIX is meant to say is that svndumpfilter expects an in-repository path. But you gave it a URL. Try something like: cat repo.dump | svndumpfilter include --drop-empty-revs --renumber-revs /B sv.dump * svnadmin load /var/svn/data/new_repo sv.dump
Apache Subversion 1.8.4 released
I'm happy to announce the release of Apache Subversion 1.8.4. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: d114557f5de725890ba285f1902983196a11d7ad subversion-1.8.4.tar.gz 6753989f5c6909dac74e3109547bf4794d3002d4 subversion-1.8.4.zip 6e7ac5b56ec22995c763a668c658577f96f2c090 subversion-1.8.4.tar.bz2 PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.4.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.4.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.4.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 Branko Čibej [4096R/A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Fuhrmann [4096R/57921ACC] with fingerprint: 056F 8016 D9B8 7B1B DE41 7467 99EC 741B 5792 1ACC Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.4 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.4/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
Thanks for following up. Amending the previous httpd.conf as shown below successfully invokes the mod_wsgi auth functions. httpd.conf: CoreDumpDirectory /tmp/apache2-gdb-dump LogLevel debug listen 8080 VirtualHost *:8080 ServerName svn.mydomain.org DocumentRoot /var/www Location /index.html WSGIAccessScript /var/lib/wsgi/access.wsgi /Location /VirtualHost VirtualHost *:80 ServerName svn.mydomain.org DocumentRoot /var/www Location /index.html AuthType Basic AuthName WSGIAuth AuthBasicProvider wsgi WSGIAuthUserScript /var/lib/wsgi/access.wsgi Require valid-user WSGIAuthGroupScript /var/lib/wsgi/access.wsgi Require group authorized /Location /VirtualHost -- Larry Howard, Sr. Research Scientist Institute for Software Integrated Systems, Vanderbilt University On Oct 29, 2013, at 7:58 AM, Branko Čibej br...@wandisco.com wrote: On 29.10.2013 13:45, Howard, Larry P wrote: An Apache configuration serving Subversion repositories, with mod_wsgi 3.3 authentication provider, causes per request segfaults in Apache 2.2.22 with mod_dav_svn from Subversion 1.7.13. If mod_wsgi auth directives are removed from the Apache configuration, then repositories are served properly. What if you remove the SVN configuration and just set up a plain server with WSGI authentication? Given your description of the issue, and the fact that the WSGI process crashes, I'd sooner suspect mod_wsgi or your access script, even though I can't see anything obviously wrong with them. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com smime.p7s Description: S/MIME cryptographic signature
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
On 29.10.2013 18:10, Howard, Larry P wrote: Thanks for following up. Amending the previous httpd.conf as shown below successfully invokes the mod_wsgi auth functions. httpd.conf: CoreDumpDirectory /tmp/apache2-gdb-dump LogLevel debug listen 8080 VirtualHost *:8080 ServerName svn.mydomain.org DocumentRoot /var/www Location /index.html WSGIAccessScript /var/lib/wsgi/access.wsgi /Location /VirtualHost VirtualHost *:80 ServerName svn.mydomain.org DocumentRoot /var/www Location /index.html AuthType Basic AuthName WSGIAuth AuthBasicProvider wsgi WSGIAuthUserScript /var/lib/wsgi/access.wsgi Require valid-user WSGIAuthGroupScript /var/lib/wsgi/access.wsgi Require group authorized /Location /VirtualHost Hmm ... This is reaching a bit far, but your initial post shows that the crashes happen on the VirtualHost on port 80. I notice that you have this parameter: SVNParentPath /var/lib//svn The extra slash shouldn't hurt, but maybe it does ... can you access the repository, with your original configuration, on port 8080 -- which doesn't have the extra slash in the SVNParentPath parameter? And what happens if you remove that slash in the port 80 vhost configuration? -- Brane On Oct 29, 2013, at 7:58 AM, Branko Čibej br...@wandisco.com wrote: On 29.10.2013 13:45, Howard, Larry P wrote: An Apache configuration serving Subversion repositories, with mod_wsgi 3.3 authentication provider, causes per request segfaults in Apache 2.2.22 with mod_dav_svn from Subversion 1.7.13. If mod_wsgi auth directives are removed from the Apache configuration, then repositories are served properly. What if you remove the SVN configuration and just set up a plain server with WSGI authentication? Given your description of the issue, and the fact that the WSGI process crashes, I'd sooner suspect mod_wsgi or your access script, even though I can't see anything obviously wrong with them. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: svn: E195016: merge error is dropping last character of path
-Original Message- From: Andrew Reedick Sent: Wednesday, September 11, 2013 9:19 AM To: users@subversion.apache.org Subject: svn: E195016: merge error is dropping last character of path So... any reason why the last character in paths are getting dropped in the Missing ranges: output? Ex: the k is missing from trunk in Missing ranges: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Or, maybe the problem is limited to the first entry? Ex: the 'g' is getting left off in the first Missing ranges. portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 Just confirming that 1.8.4 has fixed the problem: * merge: fix path corruption during reintegration (r1523666) I re-ran my merge and the last letter is no longer being dropped from trunk and config, and that confi and config have been combined back into one line. portal/branches/dev.bug Missing ranges: /portal/trunk:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 portal/branches/dev.bug/config Missing ranges: /portal/trunk/config:4217,4378,4387,4435,4452,4459
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
On Oct 29, 2013, at 12:53 PM, Branko Čibej br...@wandisco.com wrote: Hmm ... This is reaching a bit far, but your initial post shows that the crashes happen on the VirtualHost on port 80. I notice that you have this parameter: SVNParentPath /var/lib//svn The extra slash shouldn't hurt, but maybe it does ... can you access the repository, with your original configuration, on port 8080 -- which doesn't have the extra slash in the SVNParentPath parameter? And what happens if you remove that slash in the port 80 vhost configuration? — Brane Unable to access through 8080 with the original Apache configuration, nor after removing the extra slash from the port 80 vhost configuration: [Tue Oct 29 18:04:26 2013] [notice] Apache/2.2.22 (Ubuntu) DAV/2 SVN/1.7.13 mod_wsgi/3.3 Python/2.7.3 configured -- resuming normal operations [Tue Oct 29 18:04:26 2013] [info] Server built: Jul 12 2013 13:37:15 [Tue Oct 29 18:04:26 2013] [debug] worker.c(1757): AcceptMutex: sysvsem (default: sysvsem) [Tue Oct 29 18:04:26 2013] [info] mod_wsgi (pid=13477): Initializing Python. [Tue Oct 29 18:04:26 2013] [info] mod_wsgi (pid=13476): Initializing Python. [Tue Oct 29 18:04:26 2013] [info] mod_wsgi (pid=13476): Attach interpreter ''. [Tue Oct 29 18:04:26 2013] [info] mod_wsgi (pid=13477): Attach interpreter ''. [Tue Oct 29 18:04:46 2013] [info] [client elided] mod_wsgi (pid=13477, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 18:04:46 2013] [notice] child pid 13477 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 18:07:14 2013] [debug] mod_deflate.c(615): [client elided] Zlib: Compressed 481 to 328 : URL /projects/firetracks/svn [Tue Oct 29 18:07:15 2013] [info] mod_wsgi (pid=13540): Initializing Python. [Tue Oct 29 18:07:15 2013] [info] mod_wsgi (pid=13540): Attach interpreter ''. [Tue Oct 29 18:07:17 2013] [info] [client elided] mod_wsgi (pid=13476, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 18:07:17 2013] [info] [client elided] mod_wsgi (pid=13540, process='', application=''): Loading WSGI script '/var/lib/wsgi/access.wsgi'. [Tue Oct 29 18:07:17 2013] [notice] child pid 13476 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 18:07:18 2013] [notice] child pid 13540 exit signal Segmentation fault (11), possible coredump in /tmp/apache2-gdb-dump [Tue Oct 29 18:07:18 2013] [info] mod_wsgi (pid=13570): Initializing Python. [Tue Oct 29 18:07:18 2013] [info] mod_wsgi (pid=13570): Attach interpreter ''. httpd.conf (repaired): CoreDumpDirectory /tmp/apache2-gdb-dump LogLevel debug listen 8080 VirtualHost *:8080 ServerName svn.mydomain.org Location /projects DAV svn SVNParentPath /var/lib/svn SVNListParentPath Off WSGIAccessScript /var/lib/wsgi/access.wsgi /Location /VirtualHost VirtualHost *:80 ServerName svn.mydomain.org Location /projects DAV svn SVNParentPath /var/lib/svn SVNListParentPath Off AuthType Basic AuthName WSGIAuth AuthBasicProvider wsgi WSGIAuthUserScript /var/lib/wsgi/access.wsgi Require valid-user WSGIAuthGroupScript /var/lib/wsgi/access.wsgi Require group authorized /Location /VirtualHost -- Larry Howard, Sr. Research Scientist Institute for Software Integrated Systems, Vanderbilt University smime.p7s Description: S/MIME cryptographic signature
E120104: ra_serf: An error occurred during decompression
I'm setting up a repository on a new server, and I'm having problems. The new server is Subversion Edge 4.0.2, running Subversion 1.8.3. My client is TortoiseSVN 1.8.2. Other users in the office are running TortoiseSVN 1.7.3, and they are seeing the same problem. Everything seems fine, except that when I do a Show Log from the context menu in a project, I get an error: ra_serf: An error occurred during decompression (TortoiseSVN shows me a do you want to work offline dialog. If I cancel through, I see the above error. If I click work offline, I see the log just fine.) I've also installed Collabnet's command-line subversion 1.8.3 client, and its svn log shows exactly the same error. It displays the logs, and then at the end shows: svn: E120104: ra_serf: An error occurred during decompression So, this doesn't look like it's a problem in TortoiseSVN, since it's showing in both clients. Any idea what is going on?
Re: E120104: ra_serf: An error occurred during decompression
On 10/29/13 1:48 PM, Jeff Dege wrote: ra_serf: An error occurred during decompression This looks to be another case of the ZLib assembly optimizations as described here: https://mail-archives.apache.org/mod_mbox/subversion-dev/201309.mbox/%3C003c01ceaf28%24aab563d0%2400202b70%24%40qqmail.nl%3E Some specific recommendations here (that may not be particularly helpful unless you're building your own client): https://mail-archives.apache.org/mod_mbox/subversion-dev/201310.mbox/%3C00d301ced163%2451c733e0%24f5559ba0%24%40qqmail.nl%3E Can you try with compression turned off and see if the issues disappears? I'm not sure if TortoiseSVN is using a ZLib with the assembly optimizations enabled, that would probably be something to bring to their lists.
Re: E120104: ra_serf: An error occurred during decompression
On Tue, Oct 29, 2013 at 9:48 PM, Jeff Dege jeff.d...@korterra.com wrote: I'm setting up a repository on a new server, and I'm having problems. The new server is Subversion Edge 4.0.2, running Subversion 1.8.3. My client is TortoiseSVN 1.8.2. Other users in the office are running TortoiseSVN 1.7.3, and they are seeing the same problem. Do they see the same error message? That would be weird, because TortoiseSVN 1.7 should use the neon http-library by default, not serf (unless they have configured http-library=serf in their servers configuration file). Everything seems fine, except that when I do a Show Log from the context menu in a project, I get an error: ra_serf: An error occurred during decompression (TortoiseSVN shows me a do you want to work offline dialog. If I cancel through, I see the above error. If I click work offline, I see the log just fine.) I've also installed Collabnet's command-line subversion 1.8.3 client, and its svn log shows exactly the same error. It displays the logs, and then at the end shows: svn: E120104: ra_serf: An error occurred during decompression So, this doesn't look like it's a problem in TortoiseSVN, since it’s showing in both clients. Any idea what is going on? Is there any error in the logs on the server side? Also: Subversion 1.8.4 has just been released today. I just saw it's included in TortoiseSVN 1.8.3. Can you test again with that client? -- Johan
