Can't commit perl code
Hi, I've searched for quite some time for the answer to this problem. OS: Centos 5.5 Subversion version: svn, version 1.6.13 (r1002816) compiled Oct 2 2010, 20:48:38 Steps to reproduce: 1) created a new repo in /opt/svnrepo using the following command: svnadmin create myproject 2) Next I checked out the client on my workstation (I've tried it on a Mac and a Linux Centos 5.5 system) svn co https://myserver.whatever.com/repopath/reponame reponame 3) cd reponame 4) I copied the mason files (autohandler, dbhandler) and the other .html files into the reponame from the server 5) svn ci Here's what I keep getting and I haven't found any way around it (for those who say: Just Google it, I invite you to find me solution that actually works, most haven't!) Adding autohandler svn: Commit failed (details follow): svn: Server sent unexpected return value (500 Internal Server Error) in response to PROPFIND request for '/repos/acutrans/!svn/wrk/123df6d8-1458-42ca-bb69-a1f438f3ee78/autohandler' svn: Server sent unexpected return value (500 Internal Server Error) in response to PROPFIND request for '/repos/acutrans/autohandler' svn: Your commit message was left in a temporary file: svn:'/home/nathanb/acutrans/svn-commit.3.tmp' This keeps happening over and over on the same file. It does the same thing to .mas files as well. FYI - this is a brand new repo. Also we use this same repository to check C code in and it works fine. I've deleted the repo and added it again to see if that would solve it, but I get the same issue. Please help as this has been frustrating.
Re: Can't commit perl code
Ok, Your post was great and led me to find this particular problem causing the issue, but I still haven't solved the problem. These apache handlers are causing the issue: SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler #Hide private components from users. SetHandler perl-script PerlInitHandler Apache::Constants::NOT_FOUND The above are Mason handlers which need to be there, but not for the directory where we try and check code in. The location handlers are causing me the headache. This is tougher to solve than I originally thought. Is there any way to disable these handlers for a subdirectory? I've tried a ton of things to do it already, but pretty much every combination has failed. The URI location would be under /myfolder The physical location on the server would be /usr/local/myfolder Adding this line to the httpd.conf file changed the behavior: SetHandler default-handler Here's the error message now: Server sent unexpected return value (500 Internal Server Error) in response to CHECKOUT request for '/myfolder YADDA YADDA' Any clues on how to disable the apache directives for /myfolder? On Feb 26, 2011, at 4:52 PM, Ryan Schmidt wrote: > On Feb 26, 2011, at 16:18, Nate wrote: > >> Steps to reproduce: >> 1) created a new repo in /opt/svnrepo using the following command: svnadmin >> create myproject >> 2) Next I checked out the client on my workstation (I've tried it on a Mac >> and a Linux Centos 5.5 system) >> svn co https://myserver.whatever.com/repopath/reponame reponame >> 3) cd reponame >> 4) I copied the mason files (autohandler, dbhandler) and the other .html >> files into the reponame from the server >> 5) svn ci >> >> Here's what I keep getting and I haven't found any way around it (for those >> who say: Just Google it, I invite you to find me solution that actually >> works, most haven't!) >> Adding autohandler >> svn: Commit failed (details follow): >> svn: Server sent unexpected return value (500 Internal Server Error) in >> response to PROPFIND request for >> '/repos/acutrans/!svn/wrk/123df6d8-1458-42ca-bb69-a1f438f3ee78/autohandler' >> svn: Server sent unexpected return value (500 Internal Server Error) in >> response to PROPFIND request for '/repos/acutrans/autohandler' >> svn: Your commit message was left in a temporary file: >> svn:'/home/nathanb/acutrans/svn-commit.3.tmp' >> >> This keeps happening over and over on the same file. It does the same thing >> to .mas files as well. > > I am guessing there is some kind of global rule in your Apache configuration > file, or an applicable .htaccess file, that has a rule that is causing this > problem. (A rule probably meant for some entirely other purpose, but which is > also having an effect for your Subversion commits.) See for example previous > messages on this list like: > > http://svn.haxx.se/users/archive-2008-07/0944.shtml > > >
Re: Can't commit perl code
> On Mar 3, 2011, at 01:37, Nate wrote: > >> Your post was great and led me to find this particular problem causing the >> issue, but I still haven't solved the problem. >> >> These apache handlers are causing the issue: >> >> SetHandler perl-script >> PerlHandler HTML::Mason::ApacheHandler >> >> >> #Hide private components from users. >> >> SetHandler perl-script >> PerlInitHandler Apache::Constants::NOT_FOUND >> >> >> The above are Mason handlers which need to be there, but not for the >> directory where we try and check code in. >> >> The location handlers are causing me the headache. This is tougher to solve >> than I originally thought. Is there any way to disable these handlers for a >> subdirectory? I've tried a ton of things to do it already, but pretty much >> every combination has failed. >> >> The URI location would be under /myfolder >> The physical location on the server would be /usr/local/myfolder >> >> Adding this line to the httpd.conf file changed the behavior: >> >> SetHandler default-handler >> >> >> Here's the error message now: >> Server sent unexpected return value (500 Internal Server Error) in response >> to CHECKOUT request for '/myfolder YADDA YADDA' >> >> Any clues on how to disable the apache directives for /myfolder? > > Before you were getting an error on a PROPFIND, now on a CHECKOUT. These are > WebDAV methods that Subversion uses but that presumably your web site > doesn't... would it work to limit the Mason directives to just GET and POST > requests? > > > > > SetHandler perl-script > PerlHandler HTML::Mason::ApacheHandler > > > #Hide private components from users. > > SetHandler perl-script > PerlInitHandler Apache::Constants::NOT_FOUND > > Yeah, that won't work. It would break all the sites. What Mason does is It takes regular .html files and runs them as perl as it has embedded perl code. It includes subs in .mas files and in the autohandlers, plus the dbhandlers. One thing I tried was the following code: SetHandler None PerlHandler None However, this did not work either.
Re: [PATCH] bash URL completion
Nice! I was looking at doing the same thing! *Do you have the full completion code that you could post directly? (not just the DIFF?)* Thanks in advance! On Friday, July 27, 2012 at 3:31:51 AM UTC-6, Gerlando Falauto wrote: > > Hi everyone, > > I strongly felt the urge to have some way of bash-completing URLS from > the command line when doing checkouts, listing, cat (for README/REVNOTES > files) and so on... > I looked up the "tools/client-side/bash_completion" script only to > realize it works for local (file:///) but not remote URLs. > So I came up with the attached patch, which works for me (tested with > bash 4.1.2, svn 1.6.11) > The idea was (apart from adding sub-dir completion with a gross "svn ls" > command) to (manually) list known repositories within a ~/.svn_repos > file, one per line: > > http://srv1/proj1 > svn://srv2/proj2 > > The reason behind this is that data cached in > ~/.subversion/auth/svn.simple does not contain the full project URL > (only the server name) and I could not find a way to get that > information anywhere else. > > I known it would've made more sense to ask for advice *BEFORE* touching > the code, but still... :-) > > Thanks in advance for your feedback! > Gerlando > > P.S. I'm not subscribed to the list, so please Cc: me, thanks! >
Checksum mismatch between 1.4.2 server and 1.7 client
Hi all, I'm not sure if this is something I did wrong or a bug, but I'm only seeing this on the svn client I built myself (not in TortoiseSVN 1.7.5 or debian's 1.6.12dfsg-6 with the same server). I rebuilt with --enable-maintainer-mode to try to get more information At random, arbitrary files, checkouts fail, along the lines of: subversion/svn/checkout-cmd.c:168: (apr_err=200014) subversion/libsvn_client/checkout.c:229: (apr_err=200014) subversion/libsvn_client/update.c:551: (apr_err=200014) subversion/libsvn_client/update.c:412: (apr_err=200014) subversion/libsvn_ra_serf/update.c:2399: (apr_err=200014) subversion/libsvn_ra_serf/update.c:2399: (apr_err=200014) subversion/libsvn_ra_serf/util.c:1913: (apr_err=200014) subversion/libsvn_ra_serf/util.c:1913: (apr_err=200014) subversion/libsvn_subr/checksum.c:418: (apr_err=200014) svn: E200014: Checksum mismatch for 'REDACTED': expected: 14c7009f204c02209ef14148a8bde444 actual: d41d8cd98f00b204e9800998ecf8427e I did ./get-deps for dependencies, and my version information is: $ svn --version svn, version 1.7.3 (r1242825) compiled Feb 23 2012, 16:20:07 Copyright (C) 2012 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme If there is any other information I could provide, let me know. Thanks, -Nate
Re: Checksum mismatch between 1.4.2 server and 1.7 client
On Fri, Feb 24, 2012 at 12:46 AM, Daniel Shahaf wrote: > Nate Parsons wrote on Thu, Feb 23, 2012 at 16:46:55 -0500: >> * ra_serf : Module for accessing a repository via WebDAV protocol using serf. >> - handles 'http' scheme >> - handles 'https' scheme >> >> If there is any other information I could provide, let me know. > > Are you able to rebuild --with-neon and try again? I have no particular > reason to suggest this, but it might help isolate the problem. > > (And see the ~/.subversion/servers:global:http-library config option) I couldn't before because my neon was too old, but I built the version pulled down by svn's get-deps.sh, and now --with-neon works. My --version output is now: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I didn't see any errors related to neon and https, so do I have to do anything special to get https through neon? On the plus side, neon and http work!
Installing perl bindings after the fact
Hi all, I'm currently a non-root, non-sudo-er user on this particular linux box, and I'd like to start using SVN::Core. The box has subversion 1.6.12 and perl 5.10.0, but my perl script can't find SVN/Core.pm in @INC. Is there an easy way to get this working without bothering my sysadmin? I don't have a problem hard coding my script to look for SVN/Core.pm in a particular path, it's just a matter of getting the file installed. Thanks, -Nate
svn log -r based on a start date suddenly no longer returns any revisions
Hi,
I have an issue with a subversion repository that suddenly, between 2 attempts
roughly an hour or so apart, returns an empty xml list for the following
command:
D:\vcrs\svn\Collabnet\bin\svn log -r
{2008-01-01T00:00:00}:{2019-02-20T10:21:03} --username username --password
password http://testmachine:8110/svn/svn/UNITTEST/trunk --xml -v
The xml returned is:
It should find exactly 2 commits in this range, because running svn log on the
same directory without any revision filter and no --xml or -v arguments returns
the following:
r886 | (no author) | 2009-03-10 13:19:52 +0100 (di, 10 mrt 2009) | 1 line
deleted readme.txt
r876 | (no author) | 2009-03-10 10:33:56 +0100 (di, 10 mrt 2009) | 1 line
added extra files and folders
r3 | (no author) | 2005-11-10 15:38:33 +0100 (do, 10 nov 2005) | 1 line
r1 | (no author) | 2005-11-10 15:32:07 +0100 (do, 10 nov 2005) | 1 line
Initial import of Subversion Unit Test project
I had already created a stack overflow question on this issue at
https://stackoverflow.com/questions/54784054/subversion-log-command-doesnt-show-the-most-recent-revision-from-almost-10-year,
but with no answers afterwards. We originally had this problem late last month
(around the 20th of February), and we ended up having to restore that
repository from a backup. This issue suddenly returned today. Every other
aspect of our unit tests works without issues on the same repository.
Passing along a revision number instead of a start date returns the expected
result: if we replace the date in 2008 with a 3 indicating we want to get
everything since revision 3, we get the expected result.
I tried this both with a Collabnet svn.exe of version 1.8.19, and an Apache
Subversion 1.11.1 client. We have this issue on multiple machines, so it
doesn't seem to be anything machine specific, and nothing has changed in that
period apart from tags added through the unittests.
I'm not subscribed to the mailing list, and as such would like to be CC'd in
any discussions regarding this issue.
Kind regards,
Nate
RE: svn log -r based on a start date suddenly no longer returns any revisions
Hi,
I've done an svn log on the root of the repository, wrote it to an XML log and
counted the number of times the string "revision=" occurred in that log using
Powershell. It returned 9246. This is also the number of the last revision in
the log list, at the very bottom of the file. Is this enough evidence to assume
they are strictly monotonically increasing? I'm not sure how else to do this
considering this log has well over 9000 revisions.
I'm open to any more suggestions.
Nate
-Original Message-
From: Andreas Stieger
Sent: donderdag 28 maart 2019 18:06
To: Nate Kerkhofs
Cc: users@subversion.apache.org
Subject: Aw: svn log -r based on a start date suddenly no longer returns any
revisions
> svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...]
> --xml -v
> [..]
> It should find exactly 2 commits in this range
Check if all revisions (0:HEAD) on the root of the repository (not just trunk)
are strictly monotonic increasing. If they are not, this can cause this issue.
It is most frequently caused by importing repository history into a subtree of
an existing repository.
Andreas
RE: RE: svn log -r based on a start date suddenly no longer returns any revisions
> I should have been more clear. You want to check the date. In other words,
> the svn:date property of a revision N must be later than the same of a
> revision M, for every N>M.
I see.
Checking the tag revisions done yesterday through the other unit tests, all the
dates of the revisions are monotonically increasing, with time between dates
ranging from 2 seconds to 2 hours, but always increasing compared to the
previous date. I'm not sure if any older revisions might be causing the issue,
but I'm assuming that any commits that have been done a day or earlier before
the issues occurred probably didn't cause it, because I assume they'd have
triggered the issue earlier. I'm not sure about that last thing, but it seems
logical.
In case it could actually be one of the earlier revisions, are there any tricks
or software I can use to test whether revisions are broken in this manner?
I'm still open to more suggestions, as before.
Nate
-Original Message-
From: Andreas Stieger
Sent: vrijdag 29 maart 2019 9:49
To: users@subversion.apache.org
Subject: Aw: RE: svn log -r based on a start date suddenly no longer returns
any revisions
> > svn log -r {2008-01-01T00:00:00}:{2019-02-20T10:21:03} [...] http://[...]
> > --xml -v
> > [..]
> > It should find exactly 2 commits in this range
>
> Check if all revisions (0:HEAD) on the root of the repository (not just
> trunk) are strictly monotonic increasing.
[...] counted the number of times the string "revision="
I should have been more clear. You want to check the date. In other words, the
svn:date property of a revision N must be later than the same of a revision M,
for every N>M.
Andreas
RE: svn log -r based on a start date suddenly no longer returns any revisions
Hi,
After running the first --show-item command, I have indeed found that this repo
does not have monotonically increasing dates: that first command returns
revision number 1311. Checking the svn log xml dump file I made, it appears
that r1153 is in 2010, and then r1154 is back in 2005, and then it starts
climbing from that again. It doesn't reach dates after the r1311 date until
1419.
The appropriate way to fix this would most likely be to simply create a new svn
repository from scratch, but could we in theory rewrite the revisions between
r1154 and r1419 (the revisions that are backdated), either through changing the
date to be properly monotonically increasing again or through deleting them
entirely? This repository is purely for unit tests, so having to create an
entirely new repository would create a lot of work.
Kind regards,
Nate
-Original Message-
From: Daniel Shahaf
Sent: vrijdag 29 maart 2019 15:20
To: Nate Kerkhofs
Cc: Andreas.Stieger ; users@subversion.apache.org
Subject: Re: svn log -r based on a start date suddenly no longer returns any
revisions
Nate Kerkhofs wrote on Fri, 29 Mar 2019 09:08 +00:00:
> Checking the tag revisions done yesterday through the other unit
> tests, all the dates of the revisions are monotonically increasing,
> with time between dates ranging from 2 seconds to 2 hours, but always
> increasing compared to the previous date. I'm not sure if any older
> revisions might be causing the issue, but I'm assuming that any
> commits that have been done a day or earlier before the issues
> occurred probably didn't cause it, because I assume they'd have
> triggered the issue earlier. I'm not sure about that last thing, but it seems
> logical.
I don't think that's right, actually. Suppose that revisions 0:100 have
monotonically-increasing dates, then somebody creates a revision with an old
date (r101), then somebody creates a normal r102, then development goes on at a
rate of one revision per day. Because of how binary search works, the backdated
r101 would have no effect on the resolution of "in the distant past" dates for
a long time (and even once it does fire, it will afterwards go latent again,
because of how the math works).
You probably have a large chunk of backdated revisions, not just one.
Try running these commands:
svn info --show-item=revision -r "{2008-01-01T00:00:00}" ^/ svn info
--show-item=revision -r "{2019-02-20T10:21:03}" ^/
I think you might find that the first of these two commands gives a revision
number more recent than you'd expect, probably for the reasons explained in
Andreas's first reply.
> In case it could actually be one of the earlier revisions, are there
> any tricks or software I can use to test whether revisions are broken
> in this manner?
Iterate the revisions from 0 to HEAD and check if their svn:date values are
monotonically increasing. It's all of 10 lines of code in any scripting
language. (If you use 'propget svn:date' you won't even need a date arithmetic
library, because sorting ISO-8601 data as ASCII strings sorts it
chronologically.)
Cheers,
Daniel
P.S. (Humour detour: rfc2550)
