RE: svn server binaries for windows 2003
-Original Message- From: Jeegnesh Sheth [mailto:jsh...@src-solutions.com] Sent: 15 November 2011 20:09 To: users@subversion.apache.org Subject: RE: svn server binaries for windows 2003 Have my current svn server on windows 2003 with apache. Looking to upgrade to svn 1.7.1 from 1.5 Looked at subversion edge. Is there an easier way wherein I can just replace the 1.5 binaries with 1.7.1 binaries? You can get the windows compiled binaries from http://alagazam.net/ ~ mark c
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Philip Martin philip.mar...@wandisco.com writes: I hate to confess to such absent mindedness, but I may have svn deleteed this file. I see that I don't have a local copy of it, which supports that theory. If I did that, I didn't commit the change -- the repository still has the file. I'll have to think about that. This does explain some things. The client is not adding or modifying the file due to any change sent from server, it is merely restoring the missing file from its own metadata. That's a small step forward in understanding the problem. It's still not clear how the upgrade went wrong. It's not as simple as svn rm file, svn upgrade, svn update as that works (and would have created an op_depth0 nodes row that we didn't see in the very first query you ran). Perhaps it's something to do with the moved file? Perhaps you did something like: svn rm file-before-mv # or perhaps a mv? # some other wc moves and commits the file svn update # getting a delete/delete tree conflict svn resolved# or revert? rm file-after-mv# a non-svn rm svn upgrade Perhaps you had two files with the same checksum (that's legitimate) and that caused the upgrade to fail? I'll experiment and see if I can reproduce it. -- Philip
Re: wierd issue with subversion edge
This is the check out command from the repo tab in subversion edge 'svn co http://TargetProcess.companyname.com/svn/AccountProjects AccountProjects --username=admin' On file system the naming is F:\SVN\AccountProjects the checkout command has kept the casing of AccountProjects. OK. That is what I would expect and what it should be doing. What is the question? If you have edited the httpd.conf file at all then it is kind of up to you to make sure the configuration is correct and will give you a working server. You are no longer allowing SVN Edge to manage the server and write a correct configuration for you. -- Thanks Mark Phippard http://markphip.blogspot.com/
Changing the location of where tempfile is created
I don't know whether this is an artefact of svn itself, TortoiseSvn or a mixture of the both; the error is being reported from svn's io.c. A colleague has an IT-locked-down PC where he can't write to the root of C:\ or D:\. He just tried to do an update (in Tortoise) where there was a revision conflict, and instead of a fix-it prompt, he got: Couldn't do property merge Unable to make name for D:\tempfile I eventually tried the update on the command line, and that then prompted me with the usual conflict resolution (text) prompt. This implies the issue is within Tortoise, but it is aSVN library routine that's giving the error. So my question is: is there an environment variable or something that specifies where SVN creates a tempfile when there's no other dir. specified? -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
svn update does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Hi! svn update does not work with SVNParentPath in location and 1.7-client (HTTPv2) But it works with 1st-level repos, and works with 1.6 for all repos. It was worked for 1.6 server and less. Test environment on the server (apache-2.2 + subversion-1.7.1): cd /usr/home/svn svnadmin create leaf mkdir foo cd foo svnadmin create bar Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location Restart apache and run test on client (1.7.1): 1. Test lead repo: svn co svn co http://host.name/svn/leaf cd leaf svn mkdir testdir svn ci -m test # It'ok 2. Test bar repo: svn co http://host.name/svn/foo/bar cd bar svn mkdir testdir svn ci -m test # Fails: svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/svn/foo/bar/!svn/me' In server log (httpd-error.log): [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory -- Sergey Skvortsov mailto: s...@protey.ru
Re: Changing the location of where tempfile is created
On Wed, Nov 16, 2011 at 01:57:27PM +, Neil Bird wrote: So my question is: is there an environment variable or something that specifies where SVN creates a tempfile when there's no other dir. specified? Yes. Any of TMPDIR, TMP, or TEMP should work.
Re: Couldn't open rep-cache database (post commit FS processing)
Following up… I tried changed the permissions on the repository to be more permissive, and changing the user/group of the Apache server: no help. I also tried recompiling from source, but that did not help either. To recap, I am getting this warning after every commit since we upgraded the SVN server to 1.7.1: Warning: post commit FS processing had error: Couldn't open rep-cache database On 2011-11-14, at 21:35 , Aleksandr Sidorenko wrote: Since posting the question, I tried using svnserve instead of Apache (the mod_dav_svn module), and the error does NOT occur in this case (we would still prefer to stick with mod_dav_svn). How did you manage permissions using svnserver? You mentioned a group which you gave read/write access for the file. Did you made svnserve-deamon member of thet group or did something else? I thought of lock files rep-cache.db which may be not created during insufficient permissions on the parent directory. But I don't know if SQLite works this way. I ran the svnserver test as root, without any restrictions. But I don't think it's a permission issue on the rep-cache.db file since I even tried giving it unrestricted read/write access to be sure that wasn't the case. Could other files be involved?
Re: svn update does not work with SVNParentPath in location and 1.7-client (HTTPv2)
On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote: Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory You are nesting locations. This isn't a valid configuration because it leads to ambiguity when splitting a URL into the part which is outside of the repository and the part which is inside the repository. You need something like this instead: Location /svn/bar ... /Location Location /svn/foo ... /Location
Re: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2)
s/svn update/svn commit/ On 16.11.2011 18:31, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote: Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory You are nesting locations. This isn't a valid configuration because it leads to ambiguity when splitting a URL into the part which is outside of the repository and the part which is inside the repository. Why this configuration is not valid? It worked in 1.6 servers. It seems like regression. You need something like this instead: Location /svn/bar ... /Location Location /svn/foo ... /Location I want to avoid use SVNPath for every leaf repo in the root. SVNParentPath is intended for such purpose. Also I want to use SVNListParentPath to autogenerate normal listing. It's impossible with multiple SVNPath. Please note that problem is only with commit. Other commands work just fine. So I suppose it is bug. -- Sergey Skvortsov mailto: s...@protey.ru
RE: Difference between 'svn update' and 'svn checkout'
2011/11/12 Blair Zajac bl...@orcaware.com: On 11/11/2011 06:41 PM, Andy Levy wrote: On Fri, Nov 11, 2011 at 21:12, Welington Rodrigues Braga welrbr...@welrbraga.eti.br wrote: Hi guys, I've just started to use Subversion a few months ago and I am really are asking me why I had never used it before but it is not the reason of my contact. To be honest I am trying to to do a post-commit script that automatically sincronizes a given workcopy when any of my users commits their modifications to my repository. Although it's is ok and working fine (at least in my simples test), I did not put in production yet because I have a doubt that neither Subversion manual or Google were able to answer me. I didn't find any difference beetwen 'svn update' and 'svn checkout' commands which is the main function of my post-commit script. Nowadays I'm using 'svn checkout' and it is working, like I said, but I'm not sure if I'm losing some functionality with this option. Can anyone help me and answer my question? svn checkout creates a new working copy. svn update updates an existing working copy. As Andy said, but there is some special behavior in checkout. If you run svn checkout on top of an existing working copy it'll work if the URL is the same as the working copy URLs, but otherwise fail, so this may explain the behavior you see. But if you did svn co $URL1 dir svn co $URL2 dir the second one would fail. It's best to do something like this if test -d dir; then svn up dir else svn co $URL dir fi Thanks Andy and Blair. I've already understood this part explained on manual so my doubt is considering that a working copy was created and populated before, it will only receive changes (never it will send or commit them) and aI will not modify he URL. Considering those points. Will the behavious of both be the same or there are any risk of happen something wrong? If this is running as a post commit hook on the server, I would favor using Update. It will be much faster and accomplish what you want. BOb
Re: Assertion failed and crash with 1.7.1
On 10/27/11 14:57, Mark Phippard wrote:
On Thu, Oct 27, 2011 at 8:12 AM, Attila Nagy b...@fsn.hu
mailto:b...@fsn.hu wrote:
ZFS.
It it worth to make benchmarks with this WC with 1.6 and 1.7? I so,
I can try to find the time for it.
There are some pretty easy to run benchmarks you can run to see if 1.7
is simply slower in your environment. See:
https://ctf.open.collab.net/sf/projects/csvn/
If those benchmarks show 1.7 is slower for you, then that would point to
issues with the 1.7 changes in your environment. As I mentioned
earlier, and as an example, these benchmarks show that 1.7 is slower
with WC on a network mount.
If the benchmarks show 1.7 is faster, then we could focus on scalability
issues that your working copy raises. Maybe inefficient indexes or
something like that.
It turned out that not updating which is much slower (however I can't
really comment on the exact numbers now), but the propgets.
To understand this: as I've mentioned, I store operating system images
in svn, so I have to reproduce owner and permission information too.
Therefore I store them in svn properties and re-create them as needed on
updates.
I use pysvn for this and basically the code looks like this (in python):
def update_perms():
for path in propchg:
proplist = svn.propget('file:permissions', path)
if not os.path.islink(path) and proplist.has_key(path):
set_perms(path, proplist[path])
svn.update(walkroot)
update_perms()
The svn update collects the changed entries (propchg) and update_perms
iterates on them and gets their file:permissions property and sets it in
the file system.
And this is what takes ages (literally), compared to 1.6.
Any ideas about what could be done in this topic?
I will try to make more specific numbers if needed.
Re: Couldn't open rep-cache database (post commit FS processing)
Aleksandr Sidorenko asidore...@cashontime.com writes: I tried changed the permissions on the repository to be more permissive, and changing the user/group of the Apache server: no help. I also tried recompiling from source, but that did not help either. To recap, I am getting this warning after every commit since we upgraded the SVN server to 1.7.1: Warning: post commit FS processing had error: Couldn't open rep-cache database As you are building from source could you try the following patch, it will cause the lower level error to be returned: Index: subversion/libsvn_fs_fs/rep-cache.c === --- subversion/libsvn_fs_fs/rep-cache.c (revision 1202695) +++ subversion/libsvn_fs_fs/rep-cache.c (working copy) @@ -121,7 +121,7 @@ fs_fs_data_t *ffd = fs-fsap_data; svn_error_t *err = svn_atomic__init_once(ffd-rep_cache_db_opened, open_rep_cache, fs, pool); - return svn_error_quick_wrap(err, _(Couldn't open rep-cache database)); + return err; } svn_error_t * -- Philip
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 10:21 , Philip Martin wrote:
Aleksandr Sidorenko asidore...@cashontime.com writes:
Rebuilt, now I get this message on post-commit:
Warning: post commit FS processing had error:
Couldn't perform atomic initialization
It could be the atomic functions failing, but more likely it's still a
DB problem. Please add this patch as well:
Index: subversion/libsvn_subr/atomic.c
===
--- subversion/libsvn_subr/atomic.c (revision 1202695)
+++ subversion/libsvn_subr/atomic.c (working copy)
@@ -57,8 +57,7 @@
SVN_ATOMIC_INIT_FAILED,
SVN_ATOMIC_START_INIT);
#endif
- return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, err,
- Couldn't perform atomic initialization);
+ return err;
}
svn_atomic_cas(global_status,
SVN_ATOMIC_INITIALIZED,
No change (same error).
But it seems it's not this error that is triggered; it's the one a few lines
down (I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish. */
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
Couldn't perform atomic initialization);
Re: Couldn't open rep-cache database (post commit FS processing)
Aleksandr Sidorenko asidore...@cashontime.com writes:
But it seems it's not this error that is triggered; it's the one a few lines
down (I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish. */
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
Couldn't perform atomic initialization);
Wow! The atomic operations are failing! Which OS? Which distribution?
Which complier? 32-bit or 64-bit?
--
Philip
RE: Couldn't open rep-cache database (post commit FS processing)
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: woensdag 16 november 2011 16:37
To: Aleksandr Sidorenko
Cc: users@subversion.apache.org
Subject: Re: Couldn't open rep-cache database (post commit FS
processing)
Aleksandr Sidorenko asidore...@cashontime.com writes:
But it seems it's not this error that is triggered; it's the one a few
lines down
(I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish.
*/
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
Couldn't perform atomic
initialization);
Wow! The atomic operations are failing! Which OS? Which distribution?
Which complier? 32-bit or 64-bit?
You get in this branch if a previous atomic initialization call failed: the
callback function failed and returned an error. This result is then ignored
in some code paths.
It is most likely not caused by the atomic operations failing itself, but
more likely by an initialization error in a third party library.
Bert
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 10:36 , Philip Martin wrote:
Aleksandr Sidorenko asidore...@cashontime.com writes:
But it seems it's not this error that is triggered; it's the one a few lines
down (I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish. */
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
Couldn't perform atomic initialization);
Wow! The atomic operations are failing! Which OS? Which distribution?
Which complier? 32-bit or 64-bit?
Linux 2.6.9-34 (CentOS 4.3), 64-bit
gcc 3.4.5
It did work in 1.6.12; what changed?
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 10:41 , Bert Huijben wrote:
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: woensdag 16 november 2011 16:37
To: Aleksandr Sidorenko
Cc: users@subversion.apache.org
Subject: Re: Couldn't open rep-cache database (post commit FS
processing)
Aleksandr Sidorenko asidore...@cashontime.com writes:
But it seems it's not this error that is triggered; it's the one a few
lines down
(I changed the error message to detect it):
#if APR_HAS_THREADS
/* Wait for whichever thread is performing initialization to finish.
*/
/* XXX FIXME: Should we have a maximum wait here, like we have in
the Windows file IO spinner? */
else while (status != SVN_ATOMIC_INITIALIZED)
{
if (status == SVN_ATOMIC_INIT_FAILED)
return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
Couldn't perform atomic
initialization);
Wow! The atomic operations are failing! Which OS? Which distribution?
Which complier? 32-bit or 64-bit?
You get in this branch if a previous atomic initialization call failed: the
callback function failed and returned an error. This result is then ignored
in some code paths.
It is most likely not caused by the atomic operations failing itself, but
more likely by an initialization error in a third party library.
Any idea which library might be involved? I only used the default configuration
options when building from source:
./configure --with-sqlite=/usr/local
Using sqlite 3.7.8.
Re: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2)
On Wed, Nov 16, 2011 at 06:37:39PM +0400, Sergey Skvortsov wrote: s/svn update/svn commit/ On 16.11.2011 18:31, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote: Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory You are nesting locations. This isn't a valid configuration because it leads to ambiguity when splitting a URL into the part which is outside of the repository and the part which is inside the repository. Why this configuration is not valid? Before Subversion gets called, Apache HTTPD decides which Location block gets to handle a request. Subversion has no control over this decision. Note that Apache HTTPD looks only at URLs. It has no idea and does not care whether or not there is a Subversion repository anywhere within the URL http://svn.example.com/svn/foo/bar/baz With your configuration the URL has two possible repositories: http://svn.example.com/svn/foo http://svn.example.com/svn/foo/bar So how is Apache HTTPD supposed to tell which of your Location blocks should handle requests for the URL http://svn.example/com/svn/foo/bar/baz? Should Location /svn handle it or should Location /svn/foo handle it? The documentation at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.basic says: == Be sure that when you define your new Location, it doesn't overlap with other exported locations. For example, if your main DocumentRoot is exported to /www, do not export a Subversion repository in Location /www/repos. If a request comes in for the URI /www/repos/foo.c, Apache won't know whether to look for a file repos/foo.c in the DocumentRoot, or whether to delegate mod_dav_svn to return foo.c from the Subversion repository. The result is often an error from the server of the form 301 Moved Permanently. == The error you see is not 301 but the root cause of the problem is the same. It worked in 1.6 servers. It seems like regression. I am surprised that it worked. I want to avoid use SVNPath for every leaf repo in the root. SVNParentPath is intended for such purpose. Also I want to use SVNListParentPath to autogenerate normal listing. It's impossible with multiple SVNPath. You have repositories in /usr/home/svn and also /usr/home/svn/foo. This is a bad way of organising your repositories because there is no unique way to map URLs to repository roots. Put your repositories into distinct, and flat, directories. Don't nest them in a tree. Move some of your repositories into /usr/home/svn/foo and some into /usr/home/svn/bar, and change your configuration file to look like this: Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location Location /svn/bar DAV svn SVNParentPath /usr/home/svn/bar SVNListParentPath on /Location This will give you a setup that works reliably.
Re: Couldn't open rep-cache database (post commit FS processing)
Bert Huijben b...@qqmail.nl writes: You get in this branch if a previous atomic initialization call failed: the callback function failed and returned an error. This result is then ignored in some code paths. It is most likely not caused by the atomic operations failing itself, but more likely by an initialization error in a third party library. Ah, yes! When we first open/read the rep-cache during the commit the failure is not treated as a hard error. The subsequent open in the post-commit then returns the atomic error. If the rep-cache has been setup you should see: $ sqlite3 repo/db/rep-cache.db select * from sqlite_master table|rep_cache|rep_cache|3|CREATE TABLE rep_cache ( hash TEXT NOT NULL PRIMARY KEY, revision INTEGER NOT NULL, offset INTEGER NOT NULL, size INTEGER NOT NULL, expanded_size INTEGER NOT NULL ) index|sqlite_autoindex_rep_cache_1|rep_cache|4| I suspect you will see no output because init_sqlite has failed. I see you are using --with-sqlite=/usr/local. Did you build sqlite with thread support? We should check which sqlite is being picked at runtime: either use ldd executable or identify the process ID and grep through /proc/NNN/maps, look libsqlite. The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated. greping through /proc/xxx/maps gives me the following: 2a96fc4000-2a97058000 r-xp 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 sqlite was built with default options, but --enable-threadsafe defaults to yes if it's not used, so I guess it *is* built with thread support?
Re: Couldn't open rep-cache database (post commit FS processing)
Aleksandr Sidorenko asidore...@cashontime.com writes: The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated. greping through /proc/xxx/maps gives me the following: 2a96fc4000-2a97058000 r-xp 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 sqlite was built with default options, but --enable-threadsafe defaults to yes if it's not used, so I guess it *is* built with thread support? Try this patch: Index: subversion/libsvn_fs_fs/fs_fs.c === --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) @@ -5580,6 +5580,7 @@ svn_error_t *err; err = svn_fs_fs__get_rep_reference(old_rep, b-fs, rep-sha1_checksum, b-parent_pool); + SVN_ERR(err); /* ### Other error codes that we shouldn't mask out? */ if (err == SVN_NO_ERROR || err-apr_err == SVN_ERR_FS_CORRUPT To make the first error hard. Then try committing a file over ra_local: $ rm -rf repo svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/f That should make the error explicit. -- Philip
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 11:15 , Philip Martin wrote: ... Try this patch: Index: subversion/libsvn_fs_fs/fs_fs.c === --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) @@ -5580,6 +5580,7 @@ svn_error_t *err; err = svn_fs_fs__get_rep_reference(old_rep, b-fs, rep-sha1_checksum, b-parent_pool); + SVN_ERR(err); /* ### Other error codes that we shouldn't mask out? */ if (err == SVN_NO_ERROR || err-apr_err == SVN_ERR_FS_CORRUPT To make the first error hard. Then try committing a file over ra_local: $ rm -rf repo svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/f That should make the error explicit. I should note that the error does NOT occur locally, or if I use svnserve. It only occurs for commits done via HTTP (the mod_dav_svn module). For local commits (or via svnserve), the repo/db/rep-cache.db file is touched as expected (the modification date changes).
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 11:15 , Philip Martin wrote: Aleksandr Sidorenko asidore...@cashontime.com writes: The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated. greping through /proc/xxx/maps gives me the following: 2a96fc4000-2a97058000 r-xp 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 sqlite was built with default options, but --enable-threadsafe defaults to yes if it's not used, so I guess it *is* built with thread support? Try this patch: Index: subversion/libsvn_fs_fs/fs_fs.c === --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) @@ -5580,6 +5580,7 @@ svn_error_t *err; err = svn_fs_fs__get_rep_reference(old_rep, b-fs, rep-sha1_checksum, b-parent_pool); + SVN_ERR(err); /* ### Other error codes that we shouldn't mask out? */ if (err == SVN_NO_ERROR || err-apr_err == SVN_ERR_FS_CORRUPT To make the first error hard. Then try committing a file over ra_local: $ rm -rf repo svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/f That should make the error explicit. Ok, I tried this patch, and this is the error I get: svn: E200030: SQLite compiled for 3.7.9, but running with 3.3.17 So, it seems the sqlite version I compiled is NOT getting used; it's taking the older one. I suspect it's not looking in the right place (/usr/lib64 vs /usr/local/lib). I'm going to investgate this.
Re: Couldn't open rep-cache database (post commit FS processing)
Aleksandr Sidorenko asidore...@cashontime.com writes: On 2011-11-16, at 11:15 , Philip Martin wrote: ... Try this patch: Index: subversion/libsvn_fs_fs/fs_fs.c === --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) @@ -5580,6 +5580,7 @@ svn_error_t *err; err = svn_fs_fs__get_rep_reference(old_rep, b-fs, rep-sha1_checksum, b-parent_pool); + SVN_ERR(err); /* ### Other error codes that we shouldn't mask out? */ if (err == SVN_NO_ERROR || err-apr_err == SVN_ERR_FS_CORRUPT To make the first error hard. Then try committing a file over ra_local: $ rm -rf repo svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/f That should make the error explicit. I should note that the error does NOT occur locally, or if I use svnserve. It only occurs for commits done via HTTP (the mod_dav_svn module). For local commits (or via svnserve), the repo/db/rep-cache.db file is touched as expected (the modification date changes). That should work for apache as well, but only the first commit after apache is started. Subsequent commits will just give the atomic error message. -- Philip
Re: Changing the location of where tempfile is created
Around about 16/11/11 14:27, Stefan Sperling typed ... Yes. Any of TMPDIR, TMP, or TEMP should work. OK, thanks. I have to admit to not having tried those usual suspects (!) as the problem had been resolved by the time I started digging. I'll try getting him to set one of those if we see it again. -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
On Wed, Nov 16, 2011 at 2:03 AM, Philip Martin philip.mar...@wandisco.comwrote: Philip Martin philip.mar...@wandisco.com writes: I hate to confess to such absent mindedness, but I may have svn deleteed this file. I see that I don't have a local copy of it, which supports that theory. If I did that, I didn't commit the change -- the repository still has the file. I'll have to think about that. This does explain some things. The client is not adding or modifying the file due to any change sent from server, it is merely restoring the missing file from its own metadata. That's a small step forward in understanding the problem. It's still not clear how the upgrade went wrong. It's not as simple as svn rm file, svn upgrade, svn update as that works (and would have created an op_depth0 nodes row that we didn't see in the very first query you ran). Yes, I tried that myself with a sub-directory including exactly the same file. Perhaps it's something to do with the moved file? Perhaps you did something like: svn rm file-before-mv # or perhaps a mv? Definitely no mv. Maybe an rm. # some other wc moves and commits the file I'm pretty sure this isn't the case. There's been no activity for this file since January, and I've done many global check-ins where I'd have noticed local changes if I'd made them before January. svn update # getting a delete/delete tree conflict svn resolved# or revert? rm file-after-mv# a non-svn rm svn upgrade Perhaps you had two files with the same checksum (that's legitimate) and that caused the upgrade to fail? I'll experiment and see if I can reproduce it. That is quite possible. This was a large sub-directory with many files. Another thing which is unusual about our use of SVN is several very large(~20MB) text files, though the particular file we've been concentrating on was quite small. -- Philip
Re: Couldn't open rep-cache database (post commit FS processing)
On 2011-11-16, at 11:37 , Aleksandr Sidorenko wrote: On 2011-11-16, at 11:15 , Philip Martin wrote: Aleksandr Sidorenko asidore...@cashontime.com writes: The sqlite command worked (I see the expected output), but I suspect that's because the rep-cache.db file was already there (since 1.6.12). If I move it, though, the file is NOT recreated. greping through /proc/xxx/maps gives me the following: 2a96fc4000-2a97058000 r-xp 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97058000-2a97158000 ---p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 /usr/local/lib/libsqlite3.so.0.8.6 sqlite was built with default options, but --enable-threadsafe defaults to yes if it's not used, so I guess it *is* built with thread support? Try this patch: Index: subversion/libsvn_fs_fs/fs_fs.c === --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) @@ -5580,6 +5580,7 @@ svn_error_t *err; err = svn_fs_fs__get_rep_reference(old_rep, b-fs, rep-sha1_checksum, b-parent_pool); + SVN_ERR(err); /* ### Other error codes that we shouldn't mask out? */ if (err == SVN_NO_ERROR || err-apr_err == SVN_ERR_FS_CORRUPT To make the first error hard. Then try committing a file over ra_local: $ rm -rf repo svnadmin create repo $ svn import -mm repo/format file://`pwd`/repo/f That should make the error explicit. Ok, I tried this patch, and this is the error I get: svn: E200030: SQLite compiled for 3.7.9, but running with 3.3.17 So, it seems the sqlite version I compiled is NOT getting used; it's taking the older one. I suspect it's not looking in the right place (/usr/lib64 vs /usr/local/lib). I'm going to investgate this. RESOLVED. The problem was that our Apache server was loading the PHP module *before* the mod_dav_svn module, and PHP uses an old sqlite library. Reversing the load order eliminates the error (see http://www.snowbotic.com/archives/61). Thanks everyone; it really helped me pin this down!
Re: Assertion failed and crash with 1.7.1
Attila Nagy b...@fsn.hu writes:
I use pysvn for this and basically the code looks like this (in python):
def update_perms():
for path in propchg:
proplist = svn.propget('file:permissions', path)
if not os.path.islink(path) and proplist.has_key(path):
set_perms(path, proplist[path])
svn.update(walkroot)
update_perms()
The svn update collects the changed entries (propchg) and update_perms
iterates on them and gets their file:permissions property and sets it
in the file system.
And this is what takes ages (literally), compared to 1.6.
Any ideas about what could be done in this topic?
It might be faster to run a recursive propget, which is a single
transaction, and discard the output if it doesn't match one of the
changed paths.
--
Philip
Re: tortoise svn issue?
On 16.11.2011 14:39, Keith A Burnett wrote: (See attached file: svn) tortoise just crashes when doing a repo-browser http://code.google.com/p/tortoisesvn/issues/detail?id=126
Re: Downloading Link for SVN 1.7.1 Server
On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad waseem.shah...@curemd.com wrote: I need to download SVN 1.7.1 Server for windows. Any link. http://www.visualsvn.com/downloads/ -- Ivan Zhakov
Re: svnadmin load is slow for many small revisions
We are not going to fix any speed issues in 1.5. That said, why are you so sure you must use exactly 1.4? Subversion 1.7 can create, read, and write 1.4 repositories. And there have been significant performance improvements in the past four years... Vyacheslav Zholudev wrote on Tue, Nov 15, 2011 at 23:29:09 +0100: Hi all, After transition from debian lenny to squeeze I recompiled my version of SVN 1.4 (yes, I do need exactly 1.4). I tried to load a dump with many 1 file revisions into the BDB-based repository. First 300 revisions are committed really fast, like 10 revisions per second. After 1000 revisions, it is about 1-2 seconds per one revision. And performance keeps degrading. I'm curious what that might be? I tried to compile against different versions of APR (from 1.3 to 1.5) with BDB 4.8. I used libtool 1.5 since autogen.sh does not work with libtool 2.2. May this be somehow related to my issue? Maybe some compilations flags are wrong for a new system, or some libraries that I'm linking against (e.g. neon)? I have no real clue what that might be, so I will highly appreciate if somebody can give me any pointers, even vague ones or possible hints to try, since I really need SVN 1.4 for my other projects. P.S. CPU usage is very high, waiting for IO was about high (that what I would expect) and decreases to 0% over the time. P.P.S. I also tried to compile in maintainer mode and without, with preinstalled APR, and by putting them into source tree, with mod_dav and without. Still the same... Thanks a lot in advance, Vyacheslav
Re: svnadmin load is slow for many small revisions
We are not going to fix any speed issues in 1.5. Yes, I understand that. My hope was that it's not a direct SVN issue, but some problem of incorrect linking libraries or the like. That said, why are you so sure you must use exactly 1.4? Subversion 1.7 can create, read, and write 1.4 repositories. And there have been significant performance improvements in the past four years... I just have my own project based on the code of SVN 1.4 and porting to 1.7 may take considerable efforts. I post this message just in a hope that somebody could have any ideas why slowdown started to appear on a new version of linux distribution. Vyacheslav Vyacheslav Zholudev wrote on Tue, Nov 15, 2011 at 23:29:09 +0100: Hi all, After transition from debian lenny to squeeze I recompiled my version of SVN 1.4 (yes, I do need exactly 1.4). I tried to load a dump with many 1 file revisions into the BDB-based repository. First 300 revisions are committed really fast, like 10 revisions per second. After 1000 revisions, it is about 1-2 seconds per one revision. And performance keeps degrading. I'm curious what that might be? I tried to compile against different versions of APR (from 1.3 to 1.5) with BDB 4.8. I used libtool 1.5 since autogen.sh does not work with libtool 2.2. May this be somehow related to my issue? Maybe some compilations flags are wrong for a new system, or some libraries that I'm linking against (e.g. neon)? I have no real clue what that might be, so I will highly appreciate if somebody can give me any pointers, even vague ones or possible hints to try, since I really need SVN 1.4 for my other projects. P.S. CPU usage is very high, waiting for IO was about high (that what I would expect) and decreases to 0% over the time. P.P.S. I also tried to compile in maintainer mode and without, with preinstalled APR, and by putting them into source tree, with mod_dav and without. Still the same... Thanks a lot in advance, Vyacheslav Best, Vyacheslav
RE: Downloading Link for SVN 1.7.1 Server
-Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: Wednesday, November 16, 2011 4:40 PM To: Waseem Shahzad Cc: users@subversion.apache.org Subject: Re: Downloading Link for SVN 1.7.1 Server On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad waseem.shah...@curemd.com wrote: I need to download SVN 1.7.1 Server for windows. Any link. http://www.visualsvn.com/downloads/ -- Ivan Zhakov or search for subversion edge
Re: workqueue.c line 672: assertion failed (checksum !=NULL)
Stefan Sperling-7 wrote: Get a new checkout. This problem will be fixed in 1.7.1 which will be released in 4 days or so. I downloaded version 1.7.1 (upgrading from 1.6.something) and the bug's still there... -- View this message in context: http://old.nabble.com/workqueue.c-line-672%3A-assertion-failed-%28checksum-%21%3DNULL%29-tp32690129p32858669.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: workqueue.c line 672: assertion failed (checksum !=NULL)
On 11/16/2011 4:20 PM, AlfredD wrote: Stefan Sperling-7 wrote: Get a new checkout. This problem will be fixed in 1.7.1 which will be released in 4 days or so. I downloaded version 1.7.1 (upgrading from 1.6.something) and the bug's still there... No, he meant your working copy is corrupted and you need to check out another. The working copy upgrade process cannot handle certain types of working copy corruption. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
RE: Downloading Link for SVN 1.7.1 Server
And what about authentic download of Tortoise SVN 1.7.0 Cheers, Waseem Bukhari -Original Message- From: Jeegnesh Sheth [mailto:jsh...@src-solutions.com] Sent: Wednesday, November 16, 2011 4:55 PM To: Ivan Zhakov; Waseem Shahzad Cc: users@subversion.apache.org Subject: RE: Downloading Link for SVN 1.7.1 Server -Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: Wednesday, November 16, 2011 4:40 PM To: Waseem Shahzad Cc: users@subversion.apache.org Subject: Re: Downloading Link for SVN 1.7.1 Server On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad waseem.shah...@curemd.com wrote: I need to download SVN 1.7.1 Server for windows. Any link. http://www.visualsvn.com/downloads/ -- Ivan Zhakov or search for subversion edge
RE: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2)
-Original Message- From: Sergey Skvortsov [mailto:s...@protey.ru] Sent: 17 November 2011 07:09 Subject: Re: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2) snip I disagree. This cite is irrelevant to my issue. It worked in 1.6 servers. It seems like regression. I am surprised that it worked. I am not, because it's correct way. You asked for help on this list. Stefan took the time to explain what is wrong with your configuration and why. Now you tell him he is wrong? Are you an apache httpd developer? If not, then I recommend you re-read Stefan's explanation, he does know what he is talking about. ~ mark c
RE: Downloading Link for SVN 1.7.1 Server
[please do not top-post on this list] -Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: Wednesday, November 16, 2011 4:40 PM To: Waseem Shahzad Cc: users@subversion.apache.org Subject: Re: Downloading Link for SVN 1.7.1 Server On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad waseem.shah...@curemd.com wrote: I need to download SVN 1.7.1 Server for windows. Any link. http://www.visualsvn.com/downloads/ -- Ivan Zhakov or search for subversion edge -Original Message- From: Waseem Shahzad [mailto:waseem.shah...@curemd.com] Sent: 17 November 2011 07:26 Subject: RE: Downloading Link for SVN 1.7.1 Server And what about authentic download of Tortoise SVN 1.7.0 Cheers, Waseem Bukhari 5 seconds with google (other search engines are available!) will bring you the tortoisesvn homepage [1] with all the download links you could want. Why would you want 1.7.0 when there are already newer versions? ~ mark c [1] try http://tortoisesvn.net/downloads.html and look for `Older Releases`
Re: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2)
On 11/16/2011 11:08 PM, Sergey Skvortsov wrote: On 16.11.2011 19:56, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 06:37:39PM +0400, Sergey Skvortsov wrote: s/svn update/svn commit/ On 16.11.2011 18:31, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote: Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory You are nesting locations. This isn't a valid configuration because it leads to ambiguity when splitting a URL into the part which is outside of the repository and the part which is inside the repository. Why this configuration is not valid? Before Subversion gets called, Apache HTTPD decides which Location block gets to handle a request. Subversion has no control over this decision. Note that Apache HTTPD looks only at URLs. It has no idea and does not care whether or not there is a Subversion repository anywhere within the URL http://svn.example.com/svn/foo/bar/baz With your configuration the URL has two possible repositories: http://svn.example.com/svn/foo http://svn.example.com/svn/foo/bar So how is Apache HTTPD supposed to tell which of your Location blocks should handle requests for the URL http://svn.example/com/svn/foo/bar/baz? ShouldLocation /svn handle it or shouldLocation /svn/foo handle it? Of course /svn/foo. Really? And what if you check out a copy of http://svn.example.com/svn/foo and create a directory named bar in it? Are you expecting Apache or Subversion to notice that this is the path to another repository and thus ban creation of the new directory? What if the repository http://svn.example.com/svn/foo already has a directory named bar in it when you first move the child repository into /svn/foo/bar? I could go on, but the possibilities for ambiguity are endless. Don't nest repositories. Locations are worked down from shortest URI. So correct SVNParentPath must be passed to mod_dav_svn. The documentation at http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.basic says: == Be sure that when you define your new Location, it doesn't overlap with other exported locations. For example, if your main DocumentRoot is exported to /www, do not export a Subversion repository inLocation /www/repos. If a request comes in for the URI /www/repos/foo.c, Apache won't know whether to look for a file repos/foo.c in the DocumentRoot, or whether to delegate mod_dav_svn to return foo.c from the Subversion repository. The result is often an error from the server of the form 301 Moved Permanently. == The error you see is not 301 but the root cause of the problem is the same. I disagree. This cite is irrelevant to my issue. It worked in 1.6 servers. It seems like regression. I am surprised that it worked. I am not, because it's correct way. It is not the correct way. Don't nest repositories. Also, in 1.7 reading repos is working fine: OPTIONS /svn/foo/bar HTTP/1.1 200 REPORT /svn/foo/bar/!svn/me HTTP/1.1 200 but only POST fails: POST /svn/foo/bar/!svn/me HTTP/1.1 500 So the problem is not in Apache or configuration but in mod_dav_svn itself. It is obviously a regression. It was never intended to work, so it cannot be a regression. Don't nest repositories. I want to avoid use SVNPath for every leaf repo in the root. SVNParentPath is intended for such purpose. Also I want to use SVNListParentPath to autogenerate normal listing. It's impossible with multiple SVNPath. You have repositories in /usr/home/svn and also /usr/home/svn/foo. This is a bad way of organising your repositories because there is no unique way to map URLs to repository roots. I disagree, see above. There are robust way to handle Locations in Apache. I prefer to organize my repos in this way because is natural. Similar to filesystems: I like to place files and organize them to folder/directories as I want to. You are mixing file system references and Subversion references. This leads to ambiguity. Don't do it, even if it feels natural to you. Put your repositories into distinct, and flat, directories. Don't nest them in a tree. Move some of your repositories into /usr/home/svn/foo and some into /usr/home/svn/bar, and change your configuration file to look like this: [skip] This will give you a setup that works reliably. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: svn commit does not work with SVNParentPath in location and 1.7-client (HTTPv2)
On 17.11.2011 11:40, David Chapman wrote: On 11/16/2011 11:08 PM, Sergey Skvortsov wrote: On 16.11.2011 19:56, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 06:37:39PM +0400, Sergey Skvortsov wrote: s/svn update/svn commit/ On 16.11.2011 18:31, Stefan Sperling wrote: On Wed, Nov 16, 2011 at 02:43:17PM +0400, Sergey Skvortsov wrote: Configuration for Apache: Location /svn DAV svn SVNParentPath /usr/home/svn SVNListParentPath on /Location Location /svn/foo DAV svn SVNParentPath /usr/home/svn/foo SVNListParentPath on /Location [Wed Nov 16 10:32:58 2011] [error] [client 10.10.10.10] (20014)Internal error: Can't open file '/usr/home/svn/foo/foo/format': No such file or directory You are nesting locations. This isn't a valid configuration because it leads to ambiguity when splitting a URL into the part which is outside of the repository and the part which is inside the repository. Why this configuration is not valid? Before Subversion gets called, Apache HTTPD decides which Location block gets to handle a request. Subversion has no control over this decision. Note that Apache HTTPD looks only at URLs. It has no idea and does not care whether or not there is a Subversion repository anywhere within the URL http://svn.example.com/svn/foo/bar/baz With your configuration the URL has two possible repositories: http://svn.example.com/svn/foo http://svn.example.com/svn/foo/bar So how is Apache HTTPD supposed to tell which of your Location blocks should handle requests for the URL http://svn.example/com/svn/foo/bar/baz? ShouldLocation /svn handle it or shouldLocation /svn/foo handle it? Of course /svn/foo. Really? And what if you check out a copy of http://svn.example.com/svn/foo and create a directory named bar in it? Please, re-read initial example. /svn/foo is not a repo. It is just directory containing repos. And /svn too. You can not checkout /svn/foo or /svn. Are you expecting Apache or Subversion to notice that this is the path to another repository and thus ban creation of the new directory? What if the repository http://svn.example.com/svn/foo already has a directory named bar in it when you first move the child repository into /svn/foo/bar? I could go on, but the possibilities for ambiguity are endless. Don't nest repositories. Again, there are no nested repositories. I am talking about broken SVNParentPath behaviour. -- Sergey Skvortsov mailto: s...@protey.ru
