Re: subversion cross compile (arm)
Takács András writes: > / # svn mkdir file:///var/svn/testrepo/xxx -m "aaa" > fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev > fs_fs: [LINE 2140] calling read_rep_offsets '0 0 4 4 > 2d2977d1c96f487abe4a1e202dd03b4e' > read_rep_offsets: [LINE 1947] '0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e' > read_rep_offsets: [LINE 1956] '0' > read_rep_offsets: [LINE 1973] '0' > read_rep_offsets: [LINE 1984] '4' > read_rep_offsets: [LINE 1995] '4' > read_rep_offsets: [LINE 2009] '2d2977d1c96f487abe4a1e202dd03b4e' > apr_file_open: '/var/svn/testrepo/db/transactions/0-0.txn/node.0.0' > Call svn_fsfs__write_noderev in svn_fs_fs__put_node_revision [LINE 2390] > svn_fsfs__write_noderev HEADER_TEXT > rev 0 > offs 4618626049922564096 > size 4 > exp size 4 > md5 2d2977d1c96f487abe4a1e202dd03b4e > svn_fsfs__write_noderev HEADER_TEXT OK So here the file should contain the line text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e > fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev > fs_fs: [LINE 2140] calling read_rep_offsets '0 4 4 531704 (null)' > read_rep_offsets: [LINE 1947] '0 4 4 531704 (null)' but here when you read the file you get the wrong data. Is the file corrupt or does the problem occur svn_fs_fs__read_noderev? > read_rep_offsets: [LINE 1956] '0' > read_rep_offsets: [LINE 1973] '4' > read_rep_offsets: [LINE 1984] '4' > read_rep_offsets: [LINE 1995] '531704' > subversion/libsvn_fs_fs/fs_fs.c:2239: (apr_err=160004) > svn: Corrupt node-revision '0.0.t0-0' > subversion/libsvn_fs_fs/fs_fs.c:2006: (apr_err=160004) > svn: Malformed text representation offset line in node-rev > read_rep_offsets: apr_strtok #4 last_string '' string '0' str '(null)' > strlen(str) 6 (APR_MD5_DIGESTS > IZE*2) 32 revision 0 offset 4 size 0 expsize 4 -- Philip
Re: subversion cross compile (arm)
Takács András writes: > 2010/12/3 Philip Martin : >> Takács András writes: >> >>> / # svn mkdir file:///var/svn/testrepo/xxx -m "aaa" >>> fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev >>> fs_fs: [LINE 2140] calling read_rep_offsets '0 0 4 4 >>> 2d2977d1c96f487abe4a1e202dd03b4e' >>> read_rep_offsets: [LINE 1947] '0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e' >>> read_rep_offsets: [LINE 1956] '0' >>> read_rep_offsets: [LINE 1973] '0' >>> read_rep_offsets: [LINE 1984] '4' >>> read_rep_offsets: [LINE 1995] '4' >>> read_rep_offsets: [LINE 2009] '2d2977d1c96f487abe4a1e202dd03b4e' >>> apr_file_open: '/var/svn/testrepo/db/transactions/0-0.txn/node.0.0' >>> Call svn_fsfs__write_noderev in svn_fs_fs__put_node_revision [LINE 2390] >>> svn_fsfs__write_noderev HEADER_TEXT >>> rev 0 >>> offs 4618626049922564096 >>> size 4 >>> exp size 4 >>> md5 2d2977d1c96f487abe4a1e202dd03b4e >>> svn_fsfs__write_noderev HEADER_TEXT OK >> >> So here the file should contain the line >> >> text: 0 0 4 4 2d2977d1c96f487abe4a1e202dd03b4e > > This line is in /var/svn/testrepo/db/revs/0/0 file. > It is parsed correctly. The new file '/var/svn/testrepo/db/transactions/0-0.txn/node.0.0' should also contain that same line. Does it? >>> fs_fs: [LINE 2082] calling svn_fs_fs__read_noderev >>> fs_fs: [LINE 2140] calling read_rep_offsets '0 4 4 531704 (null)' >>> read_rep_offsets: [LINE 1947] '0 4 4 531704 (null)' >> >> but here when you read the file you get the wrong data. Is the file >> corrupt or does the problem occur svn_fs_fs__read_noderev? > > I don't know the internal mechanism of subversion, so I don't know > what is this second text representation. > I guess it is generated for the committing (next) revision. > The issue coming (I think) from this function: svn_fsfs__write_noderev > which is called from svn_fs_fs__put_node_revision The problem appears to be the data in the transactions/0-0.txn/node.0.0 file. Either it is getting corrupted when written to the file, or when subsequently read from the file. -- Philip
Re: subversion cross compile (arm)
Takács András writes: > One more interesting addition: > > The representation_string function is called from svn_fs_fs__write_noderev. > Here at the nodrerev->data_rep section I preinted out the revision, > offset, size, enpanded_size fields from the noderev->data_rep > structure: > > rev 0 > offs 4618629949752868864 In hex: 4018AB78 > size 4 > exp size 4 > md5 2d2977d1c96f487abe4a1e202dd03b4e > > The offset seems to be quite high. Is it normal? > > The next debug step is in the representation_string function. Before > calling the apr_psprintf function, I printed out again the fields: > > rs rev 0 > rs offs 4618628953320456192 in hex: 4018AA90 > rs size 4 > rs exp size 4 > rs md5 2d2977d1c96f487abe4a1e202dd03b4e > At a guess its a 32/64 bit issue. Are you using 64 file offsets? -- Philip
Re: subversion cross compile (arm)
Philip Martin writes: > Takács András writes: > >> The next debug step is in the representation_string function. Before >> calling the apr_psprintf function, I printed out again the fields: >> >> rs rev 0 >> rs offs 4618628953320456192 > > in hex: 4018AA90 > >> rs size 4 >> rs exp size 4 >> rs md5 2d2977d1c96f487abe4a1e202dd03b4e >> > > At a guess its a 32/64 bit issue. Are you using 64 file offsets? Obviously you are printing 64-bit offsets, so some part of your system uses 64-bit offsets. I think the problem is that some other part of your system is only writing 32-bits into 64-bits of memory, and leaving the higher 32-bits with random values. -- Philip
Re: subversion cross compile (arm)
Takács András writes: > I checked my toolchain. It's using 32 bit file offsets. > I tried an other toolchain (ct-ng + eglibc). Same result. :( > > 2010/12/3 Philip Martin : >> Takács András writes: >> >>> Here at the nodrerev->data_rep section I preinted out the revision, >>> offset, size, enpanded_size fields from the noderev->data_rep >>> structure: >>> >>> rev 0 >>> offs 4618629949752868864 >> >> In hex: 4018AB78 Here you are printing 64-bits, so some part of your system thinks that apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined in apr.h? -- Philip
Re: subversion cross compile (arm)
Takács András writes: >> Here you are printing 64-bits, so some part of your system thinks that >> apr_off_t is 64-bits. How are apr_off_t and APR_HAS_LARGE_FILES defined >> in apr.h? > > #define APR_HAS_LARGE_FILES 0 > typedef off_t apr_off_t; > > I think this is OK, isn't it? It shows that APR is just following the rest of the system. When you printed values you showed 64 bits so it looks like off_t is 64-bits, which conflicts with your earlier statement that you were using 32-bit file offsets. However the 64-bit values you printed look as if the lower 32-bits are valid and the higher 32-bits are junk. Your environment appears to be confused about the size of file offsets. -- Philip
Re: Subversion Issue: 'delete file' not transmitted to server when performing multiple merge-commit
writes: > My user reported that an extra file existed in the repository after > performing a merge (claiming this file was not in his working copy prior > to the commit). My initial thought was they had done the merges out of > sequence causing the deletion of a file before it was added, the user > was adamant this was not the case. A simpler sequence: rm -rf repo wc file touch file url=file://`pwd`/repo svnadmin create repo svn mkdir -mm $url/trunk svn cp -mm $url/trunk $url/branch svn import -mm file $url/branch/folder/file svn rm -mm $url/branch/folder/file svn co $url/trunk wc svn merge $url/branch@3 wc svn merge $url/branch@4 wc The first merge adds a folder containing a file, the second merge deletes the file. After the two merges 1.6 shows status: Mwc A + wc/folder This is a problem because folder's history is a copy from a revision where it contains the file, so the file will exist in repository after the commit. Using 1.7 status shows: Mwc A + wc/folder D + wc/folder/file so 1.7 will delete explicitly the file when the merge is committed. -- Philip
Re: XML parsing and checksum mismatch errors at updates and checkouts
Daniel Shahaf writes: > [ summary for dev@: bug in trunk that doesn't reproduce in 1.6.16; > I can reproduce it with trunk/ra_serf but not with trunk/ra_neon ] > > Aleksandr Platonov wrote on Thu, Apr 07, 2011 at 17:52:13 +0400: >> >> I build Subversion as a part of TortoiseSVN (see >> http://tortoisesvn.googlecode.com/svn/trunk/ext/build/subversion.build) >> >> This problem happens when I try to checkout following url: >> http://svn.webdav.org/repos/projects/neon/tags/0.29.5 >> > > I can reproduce it (with trunk svn): > > * Checking out that URL over ra_neon proceeds normally. > > * Checking out that URL over ra_serf is > (a) noticeably slower > (b) fails with a checksum error: > > svn: E200014: Checksum mismatch for > '/tmp/svn/neon-0.29.5-via-serf/src/ne_auth.c': >expected: 4ce0a5989ad4d1b0f7f66ae08c1e05c1 > actual: 5848237f8c173bd25a118db45cd5574a I was getting that error last month: http://svn.haxx.se/dev/archive-2011-03/0745.shtml What I find is that the problem sometimes appears and sometimes does not. It's not predictable either, repeating a failed export/checkout will sometimes work and sometimes fail at a different place. That is the case when I try that neon URL: svn: E200014: Checksum mismatch for 'subversion/tests/xx/src/ne_openssl.c': expected: 3bd789b372ca14793e8ac228cdf43a15 actual: be72d4221d805da2484b1cd0182b9049 svn: E200014: Checksum mismatch for 'subversion/tests/xx/src/ne_ssl.h': expected: 6fbb6c5dda02229623c887a9a08b1533 actual: 4f0c8e04845b70ebf1e88adbb780a2f0 I suspect the pool/memory handling in serf or libsvn_ra_serf, but I'm not certain. -- Philip
Re: XML parsing and checksum mismatch errors at updates and checkouts
"Bert Huijben" writes: >> What I find is that the problem sometimes appears and sometimes does >> not. It's not predictable either, repeating a failed export/checkout >> will sometimes work and sometimes fail at a different place. That is >> the case when I try that neon URL: >> >> svn: E200014: Checksum mismatch for >> 'subversion/tests/xx/src/ne_openssl.c': >>expected: 3bd789b372ca14793e8ac228cdf43a15 >> actual: be72d4221d805da2484b1cd0182b9049 >> >> svn: E200014: Checksum mismatch for 'subversion/tests/xx/src/ne_ssl.h': >>expected: 6fbb6c5dda02229623c887a9a08b1533 >> actual: 4f0c8e04845b70ebf1e88adbb780a2f0 >> >> I suspect the pool/memory handling in serf or libsvn_ra_serf, but I'm >> not certain. > > The update in one fetch operation in neon doesn't receive all checksums in > all places. Serf receives a few more, because it uses a request per file. > For trunk I fixed the missing checksums for 1.7, so a trunk server with a > trunk client gets all the checksums editor v1 supports. > > But using an older server or an older client will not. In that case you just > get the calculated checksums in your working copy. > > I think this server is pre 1.5, but it is certainly possible to get invalid > checksums in a checkout when you encounter the problems mentioned in issue > #3711. But you don't encounter these problems with trunk clients. I was getting those checksum errors while doing an export, I'm not sure how 3711 is relevant. -- Philip
Re: XML parsing and checksum mismatch errors at updates and checkouts
Philip Martin writes:
> I was getting those checksum errors while doing an export, I'm not sure
> how 3711 is relevant.
So I got an checksum error during an export using serf for the file
src/ne_uri.c. I compared the "bad" file in the export with a "good"
version from a checkout using neon:
$ diff -a bad/src/svn-DfdRjG good/src/ne_uri.c
86,90c86,110
< #define URI_SEGCHAR (URI_PCHAR | FOT, OT, OT, OT, OT, OT, OT, OT, OT,
O2010-10-14T15:02:41.455674Z *010-10-14T15:02:41.455674Z���
*DAV:getlastmodifiedThu, 14
Oct 2010 15:02:41 GMT�*Thu, 14 Oct 2010 15:02:41
GMTuN��p*�*DAV:version-name1823(+1823�+Z�+
+DAV:creator-displaynamejoe�+joe4r�p`+�+http://subversion.tigris.org/xmlns/dav/md5-checksum###error###,
###error###�<�p,3�(.@-http://subversion.tigris.org/xmlns/dav/�RIW�'(,Ơ��
,http://subversion.tigris.org/xmlns/dav/repository-uuid61a7d7f5-40b7-0310-9c16-bb0ea8cb1845�$61a7d7f5-40b7-0310-9c16-bb0ea8cb1845doH8�-�DAV:supportedlock
<
< X.
<
/T, OT, OT, OT, OT, OT, teK.DAV:lockdiscovery/
---
> #define URI_SEGCHAR (URI_PCHAR | FS)
> /* query = *( pchar / "/" / "?" ) */
> #define URI_QUERY (URI_PCHAR | FS | QU)
> /* fragment == query */
> #define URI_FRAGMENT URI_QUERY
>
> /* any characters which should be path-escaped: */
> #define URI_ESCAPE ((URI_GENDELIM & ~(FS)) | URI_SUBDELIM | OT | PC)
>
> static const unsigned int uri_chars[256] = {
> /* 0xXXx0 x2 x4 x6 x8 xA xC xE */
> /* 0x */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* 1x */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* 2x */ OT, SD, OT, GD, SD, PC, SD, SD, SD, SD, SD, PS, SD, DS, DT, FS,
> /* 3x */ DG, DG, DG, DG, DG, DG, DG, DG, DG, DG, CL, SD, OT, SD, OT, QU,
> /* 4x */ AT, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL,
> /* 5x */ AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, GD, OT, GD, OT, US,
> /* 6x */ OT, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL,
> /* 7x */ AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, AL, OT, OT, OT, TD, OT,
> /* 8x */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* 9x */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* Ax */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* Bx */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* Cx */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
> /* Dx */ OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT, OT,
--
Philip
Re: Problems compiling 1.7.0 on redhat el4 64bit
Mark Phippard writes: > On Tue, Aug 9, 2011 at 4:49 PM, wrote: > >> ** ** >> >> Ok, I’ve tracked down which revision caused the problem. It happened in >> rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. >> Ever since this change went in I am seeing subversion crash when I compile >> on 64bit el4. >> >> ** ** >> >> Just for kicks and giggles I updated to the HEAD revision of >> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on >> rev 1104160, cleaned up the conflicts and built it and viola! No more >> crashing when built on 64bit el4. >> > > Thanks. Moving the thread to dev@ > > Can someone look at this and possibly fix it? > > If you are not on users@, and to summarize this thread. SVN builds fine on > RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw > the same problem with our builds. It could be a compiler/optimiser bug. Which compiler are you using? Can you provide a stack trace of the crash (with debug symbols please)? Does the crash go away if you compile utf.c without optimisation? Which version of APR are you using? Is APR_HAS_THREADS defined in apr.h? -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
writes:
> I am attaching a stack trace with symbols enabled.
Thanks!
> I'm using gcc. The default in the makefile.
I think RHEL may have come with two different gcc, a 3 series and a 4
series. What version does 'gcc -v' show?
> I am using the apr that you get from the get-deps.sh
> script. APR_HAS_THREADS is defined.
Just to check, APR_HAS_THREADS is defined to be 1?
It would be good to confirm that at runtime you really are using the
version of libapr you compiled, run ldd on the svn executable.
> If I disable optimizations by doing "make CFLAGS=-O0" the program no
> longer crashes.
That suggests it could be a compiler bug.
> #0 apr_xlate_conv_buffer (convset=0x2d6674752d6e7673,
convset looks to be corrupt, that value is way bigger than the other
pointer values. It looks like ASCII, "-ftu-nvs", but that probably
just means it's random.
> inbuf=0x7fbe8a "/cos/home/ryttingm", inbytes_left=0x7fb038,
> outbuf=0x54d5a8 "", outbytes_left=0x7fb030) at xlate/xlate.c:339
> 339 if (convset->ich != (iconv_t)-1) {
> (gdb)
> Thread 1 (process 14949):
> #0 apr_xlate_conv_buffer (convset=0x2d6674752d6e7673,
> inbuf=0x7fbe8a "/cos/home/ryttingm", inbytes_left=0x7fb038,
> outbuf=0x54d5a8 "", outbytes_left=0x7fb030) at xlate/xlate.c:339
> status = 0
> #1 0x002a965a4b95 in convert_to_stringbuf (node=0x2a965bcc30,
node looks to be corrupt as well, that looks like a code value.
Looking at the rest of the stack trace I would say this is the first
call to a utf8 conversion function that would have invoked
get_xlate_handle_node and I suspect it is that function that is going
wrong. At a guess something to do with the use of atomic_swap, which
makes it important to confirm the value of APR_HAS_THREADS.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Dave Huang writes: > On Aug 10, 2011, at 4:51 PM, Philip Martin wrote: >> convset looks to be corrupt, that value is way bigger than the other >> pointer values. It looks like ASCII, "-ftu-nvs", but that probably >> just means it's random. > > It's byte-reversed "svn-utf-" Ah, yes! It's a little-endian machine so the pointer value is the opposite order to the string. -- Philip
Re: Problems compiling 1.7.0 on redhat el4 64bit
Philip Martin writes: > writes: > >> If I disable optimizations by doing "make CFLAGS=-O0" the program no >> longer crashes. > > That suggests it could be a compiler bug. The other flag you could try is to enable optimisation but to use -fno-strict-aliasing. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
writes:
> It is set to 1
>>
>> Looking at the rest of the stack trace I would say this is the first
>> call to a utf8 conversion function that would have invoked
>> get_xlate_handle_node and I suspect it is that function that is going
>> wrong. At a guess something to do with the use of atomic_swap, which
>> makes it important to confirm the value of APR_HAS_THREADS.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL;
static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really
want "volatile pointers to data". Perhaps we should do something
similar to svn_cache_config.c. Would you try this patch built with
optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===
--- subversion/libsvn_subr/utf.c(revision 1160136)
+++ subversion/libsvn_subr/utf.c(working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL;
-static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL;
+static void * volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Assertion Failed: workqueue.c
Patrick Quirk writes: > I upgraded to 1.7 yesterday when the new version of Tortoise came out, > and used it with no issues last evening and today until I encountered > this assertion: > > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c' > line 672: assertion failed (checksum != NULL) Is this a working copy that you checked-out with the old 1.6 Tortoise and upgraded to 1.7, or is it a working copy that you checked-out with 1.7? > Now any time I attempt anything (cleanup, update, commit, etc) in that > WC I always get this assertion (using Tortoise or the command line). > I got it first while running an update on my working copy after > resolving a conflict (resolved using 'theirs'). A text-conflict or a tree-conflict? Do you have any local modifications to the working copy? Adds, deletes, copies etc.? Is the sqlite3 utility readily available on Windows? If it is then run: sqlite3 .svn/wc.db "select * from work_queue" -- Philip
Re: Assertion Failed: workqueue.c
Patrick Quirk writes: >> Is the sqlite3 utility readily available on Windows? If it is then run: >> sqlite3 .svn/wc.db "select * from work_queue" > > Yep, here's the output: > 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1) > 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1) > 81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1) > 82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1) > > These are files that were new from the repo and were the last to show up > before the assertion appeared. So now we want to see the nodes row for each of those four paths: sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'" sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'" sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'" sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'" -- Philip
Re: checksum error upgrading working copy
Stefan Sperling writes: > On Thu, Oct 13, 2011 at 04:28:21PM +0200, Daniel Sparing wrote: >> Dear fellow subversion users, >> >> as requested by the error message, i would like to report an error as >> the following: >> >> ---8<--- >> In file >> >> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c' >> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum, >> found_md5_checksum)) >> ---8<--- >> >> what i was doing: I updated my TortoiseSVN client to 1.7.0, then tried >> to upgrade my two working copies to the new 1.7 format, one of them >> succeeded, the other one repeatedly returns the error message above. >> >> daniel > > You had a broken 1.6 working copy which cannot be upgraded. > See http://svn.haxx.se/tsvnusers/archive-2011-10/0086.shtml > > We've been getting this report a lot lately. > Maybe it's time to add this to the FAQ? > > I also think we should change the assert into a proper error message. In this particular case one of the checksum values in one of the .svn/entries files doesn't match the checksum of the corresponding file in .svn/text-base. The incorrect checksum won't show up as an error in 1.6 until an update or commit attempts to modify the corresponding file. The 1.7 upgrade process checks all checksums so it will detect errors that lie dormant in 1.6 working copies. I agree we should be returning a better error, one that includes the name of the file with the incorrect checksum. -- Philip
Re: checksum error upgrading working copy
Hyrum K Wright writes: > Another option might be to run a pre-upgrade check to ensure this type > of error doesn't exist, before we irrevocably upgrade (and potentially > hose) the working copy. This is happening during upgrade so the working copy remains a 1.6 working copy. -- Philip
Re: Assertion Failed: workqueue.c
Patrick Quirk writes: Is the sqlite3 utility readily available on Windows? If it is then run: sqlite3 .svn/wc.db "select * from work_queue" >>> >>> Yep, here's the output: >>> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1) >>> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1) >>> 81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1) >>> 82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1) >>> >>> These are files that were new from the repo and were the last to show up >>> before the assertion appeared. >> >> So now we want to see the nodes row for each of those four paths: >> >> sqlite3 .svn/wc.db "select * from nodes where >> local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'" >> sqlite3 .svn/wc.db "select * from nodes where >> local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'" >> sqlite3 .svn/wc.db "select * from nodes where >> local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'" >> sqlite3 .svn/wc.db "select * from nodes where >> local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'" > > I've attached the output since it's a little unreadable in 80 column format. Thanks! So each file has an op-depth=0, presence=normal line that has a checksum. Can you verify that each checksum exists in pristine: sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$a6fb31cbea18a2f670e5d1387b2a1b118f831f09'" sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$9addd651cd4260ee52b26cf5eae2d2bfe798aba5'" sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$041ffe70415ce290a4f14a770d869e2eb3b420e8'" sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$ea6871c7f57dd63e0a74ac0fd19435232322e5ff'" What I don't yet understand is why each file also has an op-depth=1, presence=base-deleted row. That seems to imply that 'X' is deleted in the working copy, so we should see two lines here: sqlite3 .svn/wc.db "select op_depth, presence from nodes where local_relpath='X'" -- Philip
Re: Error running configure for subversion 1.7.0
Ed Hillmann writes:
> checking for a BSD-compatible install... build/install-sh -c
> configure: Apache Portable Runtime (APR) library configuration
> checking for APR... yes
> checking APR version... 1.4.5
> /u01/ct/ctapp/subversion-1.7.0/configure: bad substitution
>
>
> I can't see what is causing the bad substitution error.
> printf "%s" "${output_flags# }"
I'm guessing it's the # substitution in that line. Which shell are you
using? It's a long time since I used Solaris but there used to be
/usr/xpg4/bin/sh that was more like the shells commonly found on Linux.
Perhaps you could use that. Alternatively you may be able to replace
the above line with:
echo $output_flags
it occurs in several places in configure.
--
Philip
Re: Help! Subversion Exception!
sebb writes: > In that case, either that is an insufficient check, or the upgrade > fails to act correctly on the results of the check. In what way? The upgrade detected the problem, stopped the upgrade and left the 1.6 working copy unchanged apart from some files in .svn/tmp. -- Philip
Re: Problem using mod_dav_svn (returns 500 on non-svn requests)
[Adding dev@s.a.o as I think this is a bug in the Subversion code, although I don't know enough to be sure.] Jean-Daniel Dupas writes: >> Le 18 oct. 2011 à 18:39, Jean-Daniel Dupas a écrit: >> >>> After upgrading to svn 1.7, I encounter some very annoying issues. >>> I have a web server with the following configuration: >>> >>> hostname/ : standard website >>> hostname/svn: subversion repositories (using dav_svn) >>> hostname/projects: other website. >>> >>> Before the update, this configuration were working fine. But after >>> the update, anytime the server receives a POST request (whatever the >>> path is), the dav_svn module try to handle it, and when it failed >>> (always when the path does not start with /svn/...), it returns a >>> 500 error (without logging anything in the error.log, which is an >>> other issue). >>> >>> FWIW, the error is created and returned by the get_resource() >>> function, in mod_dav_svn/repos.c. >>> >>> Is there something I can do to workaround this issue ? > > I found some details about this issue. > > When neither SVNPath, nor SVNParentPath are defined in a vhost, or > alias, the mod_dav_svn prevents processing of all POST requests. > > So it is no longer possible to have mod_dav_svn loaded in an apache > instance used to serve other content (as modules are globals). As far as I can see mod_dav_svn.c:dav_svn__handler passes all POST requests to dav_svn__method_post and that function will return an error if the request does not have SVNPath or SVNParentPath set since it will fail to open a repository. Is that the behaviour we want? I don't think we should be attempting to handle POST requests that are directed at non-Subversion locations. Should one of those functions simply ignore the POST request when neither SVNPath nor SVNParentPath is set? I see we register the hook using APR_HOOK_LAST. Does that mean we expect other hooks to get in first and handle non-Subversion POST requests? What happpens if the other handler also uses APR_HOOK_LAST? Does it then depend on the order of the module loads? Is it random? -- Philip
Re: 1.7.0 does not build on Solaris9
Andreas Krey writes: > + svn commit -m 1 > Adding kadr.polon.p > Transmitting file data .ld.so.1: svn: fatal: relocation error: file > /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: > referenced symbol not found I think that is a zlib symbol. Subversion links some libraries against zlib but doesn't link executables to zlib directly, relying on the library to pull them in. If you build using make EXTRA_LDFLAGS=-lz that will probably fix the problem. If zlib is in some non-standard location you may need make EXTRA_LDFLAGS='-lz -L/some/dir' -- Philip
Re: Help! Subversion Exception!
Les Mikesell writes: > Perhaps it is obvious and known to you. I think the number of error > reports on the list indicates that the scenarios that cause errors are > not generally well understood. The error in this case: line 1935: assertion failed (svn_checksum_match(entry_md5_checksum, found_md5_checksum)) indicates that the working copy is corrupt. This is not a problem that can be solved by running cleanup. It's possible that it could be solved in other ways (by running "svn up -r0" on the affected files perhaps, or "rm -rf on a subdir) but it's still risky to upgrade a corrupt working copy as we don't know what other corruption is present. It's possible that the corruption has lain dormant in the 1.6 working copy for some time, the corrupt checksum will only be reconised when an update or commit attempts to explicitly modify the file with a problem. Other 1.6 operations won't examine the corrupt checksum. However the 1.7 upgrade has to recalculate checksums for all the files so it falls over on such cases. One of the things we would like to do is verify that this really is corruption but that is hard because the error message isn't very good (1.7.1 will do better--it will tell you which file has the problem) and our users don't always have the tools to do it. We need sombody capable of debugging the assertion to identify the file, and then checking the stored checksum against the actual checksum. Alternatively somebody who can validate all the the checksums in the working copy to see if any are wrong. Or somebody who is prepared to send their working copy to me so that I can do it. -- Philip
Re: why does my SVN client process die an hour after completion of commit?
Stefan Sperling writes: > On Fri, Oct 21, 2011 at 10:34:52AM +0100, Jon Nicoll wrote: >> So, my question is: is there something in the 'svn commit' protocol >> which causes the client process to do a lot of work, potentially >> causing the client machine to run out of memory, up to one hour after >> the server has determined that a checkin is complete? > > This is a known issue in Subversion 1.6. > Adding many files in one commit uses too much memory, see: > http://subversion.tigris.org/issues/show_bug.cgi?id=1964#desc12 The reason it happens after a commit is complete on the server is that the client has to modify the metadata for all the items in the working copy that were committed. When the commit starts the items being committed all have local modifications of some kind, when the commit is complete they must all be change to unmodified. This can involve a lot of work, writing pristine text and properties, updating the revision numbers. This updating cannot happen until the client knows that the commit was successful. -- Philip
Re: why does my SVN client process die an hour after completion of commit?
Jon Nicoll writes: > So for now I would be best off to regard my 'initial working > directory' as suspect, and if I checkout from the server into a new > directory, that directory should be correct, yes? You will probably need to run cleanup on the old working copy to remove locks but it should be OK. Items that have been not been updated to commited revision will get pulled from the server on the next update. -- Philip
Re: Problem using mod_dav_svn (returns 500 on non-svn requests)
Philip Martin writes: >>> Le 18 oct. 2011 à 18:39, Jean-Daniel Dupas a écrit: >>>> >>>> Before the update, this configuration were working fine. But after >>>> the update, anytime the server receives a POST request (whatever the >>>> path is), the dav_svn module try to handle it, and when it failed >>>> (always when the path does not start with /svn/...), it returns a >>>> 500 error (without logging anything in the error.log, which is an >>>> other issue). > > Is that the behaviour we want? I don't think we should be attempting to > handle POST requests that are directed at non-Subversion locations. > Should one of those functions simply ignore the POST request when > neither SVNPath nor SVNParentPath is set? Fixed by r1187695, proposed for 1.7.x. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: Subversion Exception!
Pecinovský Rudolf writes: > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\adm_ops.c' > > line 177: assertion failed (status == svn_wc__db_status_normal || status == > svn_wc__db_status_added) > However the command line client tells: > > D:\Tvorba_PGM_SVN>svn st > > !M @B_Knihy\@B_41C_OOP-NMPO\nbproject Yes, that looks like a new bug. I've raised issue 4042: http://subversion.tigris.org/issues/show_bug.cgi?id=4042 -- Philip
Re: build error
Ludescher Antal writes: > In file included from subversion/libsvn_subr/sqlite.c:32:0: > subversion/libsvn_subr/internal_statements.h:6:3: warning: missing > terminating " character [enabled by default] > subversion/libsvn_subr/internal_statements.h:8:4: warning: missing > terminating " character [enabled by default] You trying to build from the .zip file on Linux and the files have the wrong line endings, use the .tar.bz2 file instead. -- Philip
Re: Subversion Exception! - Performing a "copy versioned items" from Tortoise SVN client
"Richard Millet" writes: > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib > svn_wc\copy.c' > > line 491: assertion failed (child_status == > svn_wc__db_status_server_excluded) Probably issue 4026: http://subversion.tigris.org/issues/show_bug.cgi?id=4026 -- Philip
Re: Subversion Exception! - Performing a "copy versioned items" from Tortoise SVN client
Stefan Sperling writes: > On Mon, Oct 24, 2011 at 10:02:03AM -0700, Richard Millet wrote: >> In file >> >> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib >> svn_wc\copy.c' >> >> line 491: assertion failed (child_status == >> svn_wc__db_status_server_excluded) > > It is somewhat likely that this problem got fixed in 1.7.1. Sort of. If the incomplete node is a result of the issue 4035 upgrade problem then 1.7.1 would not have produced the incomplete node and the copy would work. However there are other valid ways to produce incomplete nodes and issue 4026 is still active. > Can you please update to 1.7.1 and try to reproduce it again? Thanks. Unlikely to work. It will only work it the user can go back to the 1.6 working copy and run the upgrade again. -- Philip
Re: 1.7RC4 file externals produce errors on updates
Mothmonsterman writes: > Should this have been resolved with Issue 4015? > > http://subversion.tigris.org/issues/show_bug.cgi?id=4015 > > On Oct 17, 4:30 pm, Mothmonsterman wrote: >> same problem here.. >> >> On Oct 4, 1:10 pm, Rolf Campbell >> wrote: >> >> > When I try to update a working view that contains file-externals, I get >> > an error because the client thinks the external is aversioneditem. >> >> > In an attempt to clear the problem, I deleted the file (locally), but >> > "svn up" restores the file and then complains about itexisting. >> >> > Are file-externals supported in v1.7? >> >> > $ svn up >> > Updating '.': >> > Restored 'lastserial.txt' >> >> > Fetching externaliteminto 'lastserial.txt': >> > svn: warning: W195017: The file external from >> > 'https://[snip]/trunk/SerialNumbers/lastserial.txt'cannotoverwritetheexistingversionedite >> > mat '/c/[snip]/lastserial.txt' >> >> > At revision 3905. >> > svn: E205011: Failure occurred processing one or more externals definitions Difficult to say. Issue 4015 is fixed in 1.7. Are you using rc4? Are you using a 1.7 checkout, or a 1.6 checkout upgraded to 1.7? -- Philip
Re: Diff output: get full path of files
Jacob Weber writes: > I want to pass the output of "svn diff OLD-URL NEW-URL" to a > code-review tool, but I need to include the full path of each file > in the ---/+++ headers. > > The paths in the output always seem to be relative to the directories > you pass in. Is there a way to make it include the full paths? The paths in the standard diff output are repository relative paths. If you want the paths to local copies of the files use --diff-cmd to invoke your own wrapper, the files paths are parameters 6 and 7. -- Philip
Re: 1.7RC4 file externals produce errors on updates
Mothmonsterman writes: > No, it was the 2011-10-11 — 1.7.0 > > I just noticed there is a 1.7.1 release, so I upgraded client to it... > No dice, still have same issue. (svn, version 1.7.1 (r1186859)). > > It is a 1.6 checkout upgraded to 1.7. > > My setup is identical to the test case described in Issue 4015, hence > my reference to it. Which version was used to do the upgrade? If you upgraded the working copy with an a 1.7 pre-release that was affected by 4015 then the upgraded working will be faulty. Changing the client will not fix a faulty working copy. If you upgraded the working copy with a released 1.7 then you should not see the problem and if you do we need to investigate. -- Philip
Re: 1.7RC4 file externals produce errors on updates
Mothmonsterman writes: > 2011-10-11 — 1.7.0 was used to do the upgrade. No release candidates > were ever installed. > > On Oct 24, 5:28 pm, Philip Martin wrote: >> Mothmonsterman writes: >> > No, it was the 2011-10-11 — 1.7.0 >> >> > I just noticed there is a 1.7.1 release, so I upgraded client to it... >> > No dice, still have same issue. (svn, version 1.7.1 (r1186859)). >> >> > It is a 1.6 checkout upgraded to 1.7. >> >> > My setup is identical to the test case described in Issue 4015, hence >> > my reference to it. >> >> Which version was used to do the upgrade? If you upgraded the working >> copy with an a 1.7 pre-release that was affected by 4015 then the >> upgraded working will be faulty. Changing the client will not fix a >> faulty working copy. If you upgraded the working copy with a released >> 1.7 then you should not see the problem and if you do we need to >> investigate. How is the svn:external defined? So what does 'svn st' show on the file external, and on the directory defining the svn:externals? What did they look like when you upgraded? Were they different from the current state? Do you have the sqlite3 tool? -- Philip
Re: 1.7RC4 file externals produce errors on updates
Mothmonsterman writes: > External definition: > C:\eclipse\workspaces_3_6\CADOC\eOMIS>svn propget svn:externals > ^/eOMIS/trunk/src/a/b/c/SF02_SampleClass.java src/a/b/c/ > SF02_SampleClass.java > ^/eOMIS/trunk/src/a/b/c/SF02_SampleServlet.java src/a/b/c/ > SF02_SampleServlet.java > ^/eOMIS/trunk/WebContent/d/sf2tzzz.jsp WebContent/d/sf2tzzz.jsp The 4015 fix doesn't handle svn:externals where the path has multiple components. I've reopened the issue. > svn st: > C:\eclipse\workspaces_3_6\CADOC\eOMIS>svn st > S src\a\b\c\SF02_SampleClass.java > S src\a\b\c\SF02_SampleServlet.java > S WebContent\d\sf2tzzz.jsp You can recover your working copy by updating each file:externals to r0: svn up -r0 src\a\b\c\SF02_SampleClass.java and then updating the whole working copy. -- Philip
Re: Error when updating
Wabe W writes: > First, please bear with my ignorance here. I only just figured out > that I don't get a reply to my e-mail in my inbox. I'm apparently > supposed to visit this page... People are replying to utwente.nl address in your Reply-To header. > Anyway, thank you for replying. To return to the problem: >>Does the problem occur with an upgraded working copy or with > >>a new checkout? > > The answer is: with both. > >>Can you please try a new checkout if you haven't already? > > When it first happened (after upgrading) I tried a new checkout. But > only for one of the directories. > > Right now I checked out the two directories I'm currently using. And I > still get the same error message if I simply click SVN update. Only > if I commit (just anything) first and then update, it works fine - and > only for that directory it works. Did you checkout the new working copy to the same location as the old working copy? If so did you move/delete the old working copy first? What state is your working copy before the update that fails? Any modifications? Can you reproduce the problem with a local test repository? -- Philip
Re: Subversion Exception!
"Schoenbrun, Jason" writes: > I was trying to checkout everything in our repository, from the very > top. Got to 400 - 500 MB before getting this error. > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion > \libsvn_wc\update_editor.c' > > line 1582: assertion failed (action == svn_wc_conflict_action_edit || > action > > == svn_wc_conflict_action_delete || action == > svn_wc_conflict_action_replace) Was this a checkout on top of an existing working copy? Was it checking out externals when the assertion occurred? -- Philip
Re: assertion failed
Davor Barcan writes: > During an update I received the following error: > > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 2898: assertion failed (status != svn_wc__db_status_normal) > > I did not see that error was reported previously on the mailing list > archives, so I am reporting this as requested by the error message. Is this a working copy that was upgraded from a 1.6 checkout? What sort of changes was the update making? Did you have any local modifications in the working copy? Is the error repeatable? -- Philip
Re: SVN repo cross-platform compatibility
Stefan Sperling writes: > With BDB repositories, it will not work, so you should dump/load. Is that right? According to the documentation: http://download.oracle.com/docs/cd/E17076_02/html/gsg/C/databaseLimits.html the BDB database files are portable. I think the BDB environment files are platform dependent, but they can be deleted/recreated on the new platform by running recover. -- Philip
Re: Assertion failed and crash with 1.7.1
Attila Nagy writes: > I'm trying to update a working copy of some tens of GBs with svn 1.7.1 Did you upgrade with 1.7.0 or 1.7.1? > $ svn up > Updating '.': > svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line > 1582: assertion failed (action == svn_wc_conflict_action_edit || > action == svn_wc_conflict_action_delete || action == > svn_wc_conflict_action_replace) > Abort (core dumped) Can you show us a gdb stack trace? How many working nodes do you have? sqlite3 .svn/wc.db "select count (*) from nodes where op_depth > 0" -- Philip
Re: Subversion Exception!
"Schoenbrun, Jason" writes: > I got the same error twice - once the first time I was doing that > checkout, and then again when I checked out on top of an existing > working copy. > > I'm not sure if it was checking out externals at the time. There is not much I can do with the information you have given so far. Can you identify which part of your tree is causing the problem? Does it always happen in the same place? What does the structure of files, directories, externals look like? -- Philip
Re: Subversion Exception!
"Schoenbrun, Jason" writes: > We have a few directories under the main repository URL - "trunk" > worked, but the problem occurred in "legacy". It happens each time (2x? > 3x?) in the same place. If you just checkout "legacy", or "legacy/foo", or "legacy/foo/bar", does the problem still occur? -- Philip
Re: Subversion Exception!
"Schoenbrun, Jason" writes: > Yes, it happens in all 3 scenarios. > > -Original Message----- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: Wednesday, October 26, 2011 11:47 AM > To: Schoenbrun, Jason > Cc: users@subversion.apache.org > Subject: Re: Subversion Exception! > > "Schoenbrun, Jason" writes: > >> We have a few directories under the main repository URL - "trunk" >> worked, but the problem occurred in "legacy". It happens each time > (2x? >> 3x?) in the same place. > > If you just checkout "legacy", or "legacy/foo", or "legacy/foo/bar", > does the problem still occur? So keep going, "legacy/foo/bar/zig/..." until you get the smallest working copy that demonstrates the problem. Describe the tree structure of that working copy as fully as possible, the layout of files and directories, any svn:externals. Compare the repository tree: svn ls -R URL with the working copy tree: ls -R wc # or whatever the Windows equivalent is What is the difference between the two trees? I wonder if it could be some sort of case problem, or some special filename that has special meaning on Windows? -- Philip
Re: Assertion failed and crash with 1.7.1
Attila Nagy writes: > On 10/26/11 15:37, Philip Martin wrote: >> Attila Nagy writes: >> >>> I'm trying to update a working copy of some tens of GBs with svn 1.7.1 >> Did you upgrade with 1.7.0 or 1.7.1? > I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm > currently using. > The upgrade took nearly one week (I can't afford a clean checkout, > because I have to preserve the files' inode numbers), at the start it > was running very fast, and at the end of the week it could print a new > directory in every 8-10 seconds, while the svn processes CPU usage was > 100%. > The disks weren't touched, it seems that even with a database > completely in the OS's buffer cache the SQL operations are pretty slow > with a lot of files. > Could it be because some indexes are missing (or not optimized for > this amount of files), or it is what we could get from SQLite? There is one query/index fix in 1.7.1 but it doesn't affect upgrade. I've not upgraded a wc as large as yours but I have just upgraded a 5GB working copy on my desktop machine (3 years old, not hugely powerful). It took about 45 minutes and used about 30 minutes of CPU. There wasn't any noticeable slowdown as the update proceeded. I see that you are using Fibre Channel storage, perhaps there is an SQLite issue there? What sort of filesystem are you using? -- Philip
Re: Error when updating
Wabe W writes: > I also tried a checkout of a(n existing) repository to a different > location. I get the same error message when I try to update. This is reproducible? You checkout some revision R1 and update to R2 and see the error? Can you describe the changes between R1 and R2? Is there a single revision that causes the problem: checkout R1 and update revision by revision to R2 to determine when the error occurs. > Maybe it is like this because our SVN server has not yet been upgraded to 1.7. > Although release notes say: > "Older clients and servers interoperate transparently with 1.7 > servers and clients. However, some of the new 1.7 features > may > not be available unless both client and server are the latest > version. There are also cases where a new feature will work > but will run less efficiently if the client is new and the > server old." > It seems to me that SVN Update is not a 'new feature' and, therefore, > it should work, right? (Anyway, I will request an update of our > server.) Regards, The server version should be irrelevant. -- Philip
Re: Assertion failed and crash with 1.7.1
Mark Phippard writes: > I would imagine svn upgrade is almost entirely writes and I recall it does > quite a few transactions. So couldn't the linear slow down just be based on > the growth in the amount of bytes that are written to disk each time? Yes, number of transactions matters a lot. However upgrade is a special case that runs in a single SQLite transaction as this makes most upgrades faster. Maybe for really large upgrades the huge transaction is a problem? My 100,000 node working copy upgrades in 45 minutes. Upgrade does a number of read queries as well as writes, but all within the same transaction. -- Philip
Re: tortoise 1.7 - error on repository manipulation
Erwane Breton writes: > On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise > 1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my > other computer with tortoise 1.7.1.22161 > > The error is always the same > >> Commit >> Commit failed (details follow): >> '/svn/site/*!svn/me*' path not found >> [Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client >> 82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL >> /svn/site/*!svn/me* That's a v2 protocol problem. The v2 protocol is only used when both client and server are 1.7. If you add "SVNAdvertiseV2Protocol off" to the 1.7 Apache config file then clients should use the v1 protocol. Do the error messages really have two '*' characters in the URL or is that an email artifact? Is your 1.7 server a write-through proxy to a 1.6 master? That won't work unless you disable the v2 protocol because the 1.6 master will not understand the v2 protocol. Is there some proxy or filter between the client and server that is corrupting the ULR? -- Philip
Re: Assertion failed and crash with 1.7.1
Attila Nagy writes: > 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 reports that a mismatch between SQLite page size and ZFS block size can cause performance problems and that better performance is obtained when they match: http://osdir.com/ml/sqlite-users/2010-10/msg00582.html http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg20395.html If you build Subversion from source we could try changing the SQLite page size. -- Philip
Re: update --depth=empty ignored since 1.7
Mojca Miklavec writes: > I'm experiencing some weird behaviour with SVN 1.7. The following > sequence of commands fails to respect --depth=empty: > svn co --depth=empty http://foundry.supelec.fr/svn/metapost > svn up --depth=empty metapost/tags > > (you can use 'anonymous' as a username) The first command runs fine, > but the second one starts fetching all tags. If I try to open > repository in web browser, it reports that the server is using SVN > 1.4.2 (r22196) which is a bit old, but with SVN 1.6.16 the same > sequence of commands worked fine - depth=empty seems to be respected. That certainly looks like a 1.7 bug, I've raised issue 4046 http://subversion.tigris.org/issues/show_bug.cgi?id=4046 -- Philip
Re: Error when updating
Wabe W writes: >> This is reproducible? You checkout some revision R1 and update to R2 >> and see the error? >> >> Can you describe the changes between R1 and R2? > > I just did a checkout of the latest revision of the repository. So, if > I click update the chances are large that there is no newer revision. > But whether there is new revision or not, this doesn't influence the > fail of the update. The error you report is: 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\wc_db.c' line 11039: assertion failed (base_status == svn_wc__db_status_incomplete) That happens inside the function end_directory_update, which is called from close_edit only if the editor didn't open the root. You report that it doesn't happen immediately after a commit and that makes sense since the commit will likely leave a mixed revision working copy so the update will not run this bit of code. I'm surprised it happens when the update makes changes to the working copy, I can't see how close_edit is called in that case. You report that a commit makes the next update work. Does an update after the successful update work? Which Subversion protocol are you using (http:, https:, svn:, file:)? I assume you are using some sort of server. Which version of Subversion is the server running? Is it a googlecode server? Are you using serf or neon? -- Philip
Re: Error when updating
Philip Martin writes: > I'm surprised it happens when the update makes changes to the working > copy, I can't see how close_edit is called in that case. Oops! I meant to say I can't see how end_directory_update is called. -- Philip
Re: subversion questions
Nrupen Kantamneni writes: > Now from my mobile browser, I should be able to upload a document to > the server after downloading the file and making changes. That would > be more convenient for me to manage the files from where ever I am. > Hope I am clear in clarifying my use model Perhaps autoversioning: http://svnbook.red-bean.com/nightly/en/svn.webdav.autoversioning.html -- Philip
Re: Apparent "svn rm" scaling problem in 1.7.x
Stefan Sperling writes: > On Tue, Nov 01, 2011 at 11:31:35AM -0600, michael_rytt...@agilent.com wrote: > Note that I am not going to commit this as is. > It just tests whether the overhead of sorting paths in sqlite matters > much on NFS. > > Index: subversion/libsvn_wc/wc-queries.sql > === > --- subversion/libsvn_wc/wc-queries.sql (revision 1196149) > +++ subversion/libsvn_wc/wc-queries.sql (working copy) > @@ -1208,7 +1208,6 @@ WHERE wc_id = ?1 > > -- STMT_SELECT_DELETE_LIST > SELECT local_relpath FROM delete_list > -ORDER BY local_relpath > > -- STMT_FINALIZE_DELETE > DROP TABLE IF EXISTS delete_list I put in the ORDER BY to preserve the parents before children notification used by 1.6. I wonder if that notification order is important? A patch that we could commit without affecting the order is: Index: subversion/libsvn_wc/wc-queries.sql === --- subversion/libsvn_wc/wc-queries.sql (revision 1196106) +++ subversion/libsvn_wc/wc-queries.sql (working copy) @@ -1193,7 +1193,7 @@ CREATE TEMPORARY TABLE delete_list ( /* ### we should put the wc_id in here in case a delete spans multiple ### working copies. queries, etc will need to be adjusted. */ - local_relpath TEXT PRIMARY KEY NOT NULL + local_relpath TEXT PRIMARY KEY NOT NULL UNIQUE ) /* This matches the selection in STMT_INSERT_DELETE_FROM_NODE_RECURSIVE */ -- Philip
Re: Apparent "svn rm" scaling problem in 1.7.x
Stefan Sperling writes: > On Tue, Nov 01, 2011 at 06:29:59PM +0000, Philip Martin wrote: >> I put in the ORDER BY to preserve the parents before children >> notification used by 1.6. I wonder if that notification order is >> important? > > See r1196191. > It should preserve the 1.6.x order (via svn_path_compare_paths()). > >> A patch that we could commit without affecting the order is: >> >> Index: subversion/libsvn_wc/wc-queries.sql >> === >> --- subversion/libsvn_wc/wc-queries.sql (revision 1196106) >> +++ subversion/libsvn_wc/wc-queries.sql (working copy) >> @@ -1193,7 +1193,7 @@ >> CREATE TEMPORARY TABLE delete_list ( >> /* ### we should put the wc_id in here in case a delete spans multiple >> ### working copies. queries, etc will need to be adjusted. */ >> - local_relpath TEXT PRIMARY KEY NOT NULL >> + local_relpath TEXT PRIMARY KEY NOT NULL UNIQUE >> ) > > Interesting. Can you explain why this doesn't affect order? Because I retained ORDER BY in the select statement. > I guess this works because there is only one column in the table? > Do UNIQUE columns happen to be inserted, or selected, in sorted order? UNIQUE simple means that an index is created so the ORDER BY is fast. -- Philip
Re: Error when updating
Wabe W writes: >> I assume you are using some sort of server. Which version of Subversion >> is the server running? > It is 1.0.8 (2004) That's old (very old) and unsupported. The client should still work but I haven't built or used 1.0.x for years. >>Is it a googlecode server? Are you using serf or neon? > I sent the person that runs the server an e-mail regarding these questions. > It is a Linux server, that I know. It won't be a googlecode server. serf/neon is a client question. -- Philip
Re: svn 1.7.1 for Windows/64bit - cannot perform svn update
Tomáš Klinkovský writes: > starting from svn 1.7 I cannot make "svn update" anymore on Windows 7, > 64bit. > > C:\Users\tomas\Documents\xxx>svn --version > svn, version 1.7.1-SlikSvn-1.7.1-X64 (SlikSvn/1.7.1) X64 > compiled Oct 26 2011, 14:18:24 > > C:\Users\tomas\Documents\xxx>svn update > Updating '.': > svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db.c' line 11039: > assertion failed (base_status == svn_wc__db_status_incomplete) > > This problem is there even if I make a fresh checkout and then update. What version of mod_dav_svn is server using? This has been reported to happen when the server is running the very old 1.0.8 mod_dav_svn. -- Philip
Re: svn 1.7.1 for Windows/64bit - cannot perform svn update
Tomáš Klinkovský writes: > My server is also very old: > > $ svn --version > svn, version 1.0.9 (r11378) > compiled Oct 14 2004, 10:04:20 > > But I don't access it through Apache, I have the Subversion daemon > running and I use the "svn:" protocol. > > Can I provide any other help? I can reproduce the error. I've raised issue 4048: http://subversion.tigris.org/issues/show_bug.cgi?id=4048 -- Philip
Re: Error when updating
Wabe W writes: > So, we just have to update the server and see if the problem is solved? It's issue 4048, it may get fixed in a 1.7.x release: http://subversion.tigris.org/issues/show_bug.cgi?id=4048 -- Philip
Re: mod_dav_svn and Apache directive
Michaël Bruneel writes: > > DAV svn > SVNPath /srv/svnroot/myproject > Given and an URL '/foo/bar/zig/zag' mod_dav_svn treats '/foo/bar' as the path to the repository and '/zig/zag' as the path inside the repository. How would you Location work? Where does '/foo/bar/zig/zag' get divided? -- Philip
Re: Subversion repository config problem
"Tony Butt" writes: > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote: >> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100: >> > I tried to edit the log message of a commit made with svn+ssh://, using >> > http:// access, and failed. Now the strange thing, after changing a >> > different commit message for a test (using http:// access only, >> > successsfully), drafting this email, and re-checking the revprops file >> > in question, it was now owned by www-data - the apache user. >> > >> >> We make rev files read only intentionally. I don't remember offhand >> how revprop files would be affected, but in any case those are never >> changed either --- we only ever rename(2) new versions on top of old >> ones. >> >> And, anyway, I really don't understand your bottom line. Are you saying >> the new behaviour is non backwards compatible? That it should be >> changed? Or just that it's surprising? > The new behaviour is slightly different, and slightly incompatible in > our corner case. It was more surprising than anything else, and I wanted > to check that I didn't need to tweak the repository config in some way > to allow for this - possibly some subtlety with umasks that I was not > aware of. The fact that the files are read-only should have no effect on Subversion operations. It should be possible to use svn+ssh and http access simulataneously provided the repository Unix permissions are correct: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.multimethod -- Philip
Re: [1.7.1] UUID error replacing local file with file external
Neil Bird writes: > Am I just doing something wrong? You are trying to make a file external point to a file in a different repository, that is not supported. -- Philip
Re: Checkout including externals is getting the head revision instead of specified one
Bastian Holtermann / SOREL GmbH writes: > I got the problem that when I checkout some code that is using > externals with a special specified revision of that external to be > checked out svn checks out the head revision in stead of the specified > revision number. Agreed, that is a bug. I've raised issue 4053: http://subversion.tigris.org/issues/show_bug.cgi?id=4053 -- Philip
Re: Error found
Ulrich Eckhardt writes: > Am 10.11.2011 10:07, schrieb JESUS LUNAR PEREZ: >> Please take the time to report this on the Subversion mailing list >> with >> as much information as possible about what you were trying to do. > > >> But please >> first search the mailing list archives for the error message > > > Please consider those two parts of the quest, too. Without knowing > what you did, there is no way for a developer to reproduce the error, > unless they happen to come across it by chance. Reporting a known > error over and over without adding any information is only causing > useless work and not getting any bugs fixed. Indeed. It looks like issue http://subversion.tigris.org/issues/show_bug.cgi?id=4042 but with the limited information provided we can only guess. -- Philip
Re: merge problem. impossible to revert deleted file
Gunnar Dalsnes writes: > REM change this to the dir you are running the script from > set wd=c:/temp/test > > svnadmin create repo > > svn mkdir file:///%wd%/repo/trunk -m test > > svn co file:///%wd%/repo/trunk trunk1 > svn co file:///%wd%/repo/trunk trunk2 trunk2 is an empty directory at r1 > > svn copy trunk1 file:///%wd%/repo/branch -m branch > > svn co file:///%wd%/repo/branch branch > > pushd branch > md dir1 > pushd dir1 > echo > file2.txt > popd > svn add * > svn commit -m test > > popd > > pushd trunk1 > svn update > md dir1 > pushd dir1 > echo > file1.txt > popd > svn add * > svn commit -m test > > popd > > pushd trunk2 > > svn merge file:///%wd%/repo/branch@4 > > REM tree conflict > > svn resolve --accept=working dir1 Did you miss a step? trunk2 is still an empty directory at r1, how can that cause a conflict. > > svn up > > REM Updating '.': > REMA dir1\file1.txt > > REM It says dir1\file1.txt is added, but it's nowhere to be seen > dir dir1 > svn status dir1 > > svn resolve --accept=working dir1 > svn revert dir1\file1.txt > > REM Nope, file is still deleted. Impossible to undelete it. > popd > > popd > > ---end script--- > > > Another small issue: > svn merge don't seem to like backslash in file urls: > C:\temp\test\trunk2>svn merge file:///C:\temp\test\trunk2/repo/branch@4 > svn: E180001: Unable to connect to a repository at URL > file:///C:%5Ctemp%5Ctest > %5Ctrunk2/repo/branch' > svn: E180001: Unable to open an ra_local session to URL > svn: E180001: Unable to open repository > file:///C:%5Ctemp%5Ctest%5Ctrunk2/repo/ > branch' > > Otoh, svn co and svn mkdir etc. seems to work with backslash in file urls. > > > thanks, > Gunnar Dalsnes > -- Philip
Re: WC database corruption (1.7.1)
Neil Bird writes: > Having just done a couple of commits (after an update), I did some > work on a file then went to commit again (no 2nd. update) and > TortoiseSVN reported no changes. > > A command line 'svn status .' is giving me: > > svn: E200030: database disk image is malformed > svn: E200030: database disk image is malformed > > Er. Can I recover from this? Do you want any diagnostics from it > (the SQLite d/b)? Never seen that before. If you have the sqlite3 tool then you can try sqlite3 .svn/wc.db "pragma integrity_check" which may give more information. -- Philip
Re: WC database corruption (1.7.1)
Neil Bird writes: > "*** in database main *** > On tree page 40898 cell 60: 2nd reference to page 325 > On tree page 40898 cell 60: Child page depth differs > On tree page 40898 cell 61: Child page depth differs" > "rowid 14277 missing from index sqlite_autoindex_PRISTINE_1" > "rowid 14278 missing from index sqlite_autoindex_PRISTINE_1" > "wrong # of entries in index sqlite_autoindex_PRISTINE_1" > "rowid 45935 missing from index I_NODES_PARENT" > "rowid 45935 missing from index sqlite_autoindex_NODES_1" > "rowid 45936 missing from index I_NODES_PARENT" > "rowid 45936 missing from index sqlite_autoindex_NODES_1" > "rowid 469 missing from index I_NODES_PARENT" > "rowid 469 missing from index sqlite_autoindex_NODES_1" > "rowid 470 missing from index I_NODES_PARENT" > "rowid 470 missing from index sqlite_autoindex_NODES_1" > "rowid 471 missing from index I_NODES_PARENT" > "rowid 471 missing from index sqlite_autoindex_NODES_1" > "rowid 472 missing from index I_NODES_PARENT" > "rowid 472 missing from index sqlite_autoindex_NODES_1" > "wrong # of entries in index I_NODES_PARENT" > "wrong # of entries in index sqlite_autoindex_NODES_1" Interesting! I've never seen a corrupt SQLite database before. It seems as if the corruption is restricted to the indices so it may be recoverable. It may be as simple as sqlite .svn/wc.db "reindex nodes" sqlite .svn/wc.db "reindex pristine" but I don't know if that will work. If it doesn't then it may be possible to copy, drop, replace the tables. This may not work either as the index corruption may simply be the visible effect of larger corruption. sqlite3 .svn/wc.db "select sql from sqlite_master where name='NODES'" sqlite3 .svn/wc.db "select sql from sqlite_master where name='I_NODES_PARENT'" will show you the SQL for the table and index that need to be recreated. Make a backup copy of wc.db before going further! Create a duplicate table NODES_COPY: sqlite3 .svn/wc.db "CREATE TABLE NODES_COPY ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, op_depth INTEGER NOT NULL, parent_relpath TEXT, repos_id INTEGER REFERENCES REPOSITORY (id), repos_path TEXT, revision INTEGER, presence TEXT NOT NULL, moved_here INTEGER, moved_to TEXT, kind TEXT NOT NULL, properties BLOB, depth TEXT, checksum TEXT REFERENCES PRISTINE (checksum), symlink_target TEXT, changed_revision INTEGER, changed_date INTEGER, changed_author TEXT, translated_size INTEGER, last_mod_time INTEGER, dav_cache BLOB, file_external TEXT, PRIMARY KEY (wc_id, local_relpath, op_depth) )" Copy NODES into NODES_COPY sqlite3 .svn/wc.db "insert into NODES_COPY select * from NODES" Drop and recreate NODES: sqlite3 .svn/wc.db "drop table NODES" sqlite3 .svn/wc.db "CREATE TABLE NODES ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, op_depth INTEGER NOT NULL, parent_relpath TEXT, repos_id INTEGER REFERENCES REPOSITORY (id), repos_path TEXT, revision INTEGER, presence TEXT NOT NULL, moved_here INTEGER, moved_to TEXT, kind TEXT NOT NULL, properties BLOB, depth TEXT, checksum TEXT REFERENCES PRISTINE (checksum), symlink_target TEXT, changed_revision INTEGER, changed_date INTEGER, changed_author TEXT, translated_size INTEGER, last_mod_time INTEGER, dav_cache BLOB, file_external TEXT, PRIMARY KEY (wc_id, local_relpath, op_depth) )" sqlite3 .svn/wc.db "create index I_NODES_PARENT on NODES (wc_id, parent_relpath, op_depth)" Copy NODES_COPY into NODES: sqlite3 .svn/wc.db "insert into NODES select * from NODES_COPY" Drop table NODES_COPY: sqlite3 .svn/wc.db "drop table NODES_COPY" Then you need to do something similar for PRISTINE, although this time there is no extra index: sqlite3 .svn/wc.db "select sql from sqlite_master where name='PRISTINE'" Create PRISTINE_COPY Copy PRISTINE into PRISTINE_COPY Drop and recreate PRISTINE Copy PRISTINE_COPY into PRISTINE Drop PRISTINE_COPY -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
"Jens Geyer" writes: > I can confirm that. > Deleting is only possible if the user has write permnissions on the > ENTIRE path. > > / top/subdir/mypath > > In order to delete mypath, the user needs write permission on > > / > /top/subdir > /top/subdir > /top/subdir/mypath > > With an 1.6.x server, write access to /top and above were not necessary. > > I could not find any documentation about this changed behavior. Next, it > is not really what we want. I don't want to give all users write access > on the entire tree up to the rootfolder just to enable them to svn > delete their own files and folders. I can't reproduce this, or your other authz problem, on my Linux machine: $ cat repo/conf/svnserve.conf [general] auth-access = write anon-access = password-db = passwd authz-db = authz $ cat repo/conf/authz [/A/B] pm = rw [/] * = r $ svn ls -R --username pm svn://localhost/repo A/ A/B/ X/ X/Y/ $ svn cp -mm --username pm svn://localhost/repo/X/Y svn://localhost/repo/A/B/C Committed revision 12. $ svn rm -mm --username pm svn://localhost/repo/A/B/C Committed revision 13. $ svn rm -mm --username pm svn://localhost/repo/A/B svn: E220004: Access denied $ svn cp -mm --username pm svn://localhost/repo/X/Y svn://localhost/repo/A/C svn: E220004: Access denied I wonder if there is an upper/lower case problem somewehere in your authz file? Or perhaps in the Subversion authz code? -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Stefan Sperling writes: > On Thu, Nov 10, 2011 at 05:25:27PM +0000, Philip Martin wrote: >> I wonder if there is an upper/lower case problem somewehere in your >> authz file? Or perhaps in the Subversion authz code? > > If so, this is likely due to the change in case-awareness we made in 1.7: > file:///home/stsp/svn/svn-site/publish/docs/release-notes/1.7.html#case-sensitive-authz http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Bostjan Skufca writes: > Well, in my case, it is all lower-case all the time. Is there any other way > to double check this? I checked with "svn ls ..." every component of path > to be lower case, and it was. authz file is also in lower case completely. > Still, delete as described before does not work. Here is a working setup on my system: svnadmin create repo svn mkdir -mm --parents file://$PWD/repo/A/B svn mkdir -mm --parents file://$PWD/repo/X/Y cat - > repo/conf/svnserve.conf < repo/conf/passwd < repo/conf/authz <
Re: svn copy doesn't honour "--quiet" in 1.7.1 ??
"Zibetti Paolo" writes: > With Subversion version 1.6.x, I could add the "--quiet" switch to the > "svn copy" command to suppress all output in case the command succeeds. > > With Subversion version 1.7.1 "svn copy --quiet ..." always prints > informational messages such as "Committed revision 42." > Other commands such as "svn commit", on the contrary, honour the > "-quiet" switch as expected. > > Is this an intended behaviour or a bug ? That looks like an unintended change in behaviour. I don't see any discussion around the time the change (r988627) was made. -- Philip
Re: merge problem. impossible to revert deleted file
Gunnar Dalsnes writes: >>> >>> REM tree conflict >>> >>> svn resolve --accept=working dir1 >> Did you miss a step? > No, nothing is missed, but it seems this line is useless (but > harmless). The problem appears regardless. >> trunk2 is still an empty directory at r1, how can >> that cause a conflict. > Yes, just ignore that line. I thought that was the conflict you were complaining about. I misunderstood your email. >>> svn up >>> >>> REM Updating '.': >>> REMA dir1\file1.txt >>> >>> REM It says dir1\file1.txt is added, but it's nowhere to be seen >>> dir dir1 >>> svn status dir1 >>> >>> svn resolve --accept=working dir1 >>> svn revert dir1\file1.txt >>> >>> REM Nope, file is still deleted. Impossible to undelete it. So here's my simple version: svnadmin create repo svn mkdir -mm file://`pwd`/repo/T svn cp -mm file://`pwd`/repo/T ^/B svn mkdir -mm file://`pwd`/repo/T/D svn mkdir -mm file://`pwd`/repo/B/D svn import -mm repo/format file://`pwd`/repo/B/D/f svn co file://`pwd`/repo/B@2 wc svn merge ^/T wc svn up wc svn st wc What I see is: svn st wc M wc R + C wc/D > local add, incoming add upon update D wc/D/f Summary of conflicts: Tree conflicts: 1 The merge creates an added directory wc/D (copied from /T/D in the repo). This conflicts with the directory D added by the update (which is /X/B in the repo) so a tree conflict is created. Note that wc/D is marked as replaced. After accepting the working state: svn resolve --accept working wc/D I see: svn st wc M wc R +wc/D D wc/D/f This is equivalent (ignoring the mergeinfo property) to svn co file://`pwd`/repo/B svn rm wc/D svn cp ^/T/D wc/D You can't revert wc/D/f without reverting the replace of wc/D. -- Philip
Re: merge problem. impossible to revert deleted file
Philip Martin writes: > The merge creates an added directory wc/D (copied from /T/D in the > repo). This conflicts with the directory D added by the update (which > is /X/B in the repo) so a tree conflict is created. Note that wc/D is Typo: /X/B should be /B/D. > marked as replaced. -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Bostjan Skufca writes: > Nope, first step already fails (commit 3) if there are "[/]\n* = r" lines > present in authz file. > > It works if I create authz file like this (note the usage of rw everywhere): > [/A/B] > pm = rw > > [/X/Y] > pm = rw > - > > > It DOES NOTwork if I create authz file like this: > [/A/B] > pm = rw > > [/X/Y] > pm = r > - > > > Any further ideas? Use "--log-file log.txt" when you start svnserve and then try the failing copy. On my Linux machine with: $ cat repo/conf/authz [/A/B] pm = rw [/] pm = r $ svn cp -mm svn://localhost/repo/X svn://localhost/repo/A/B/C Committed revision 22 $ cat log.txt 9486 2011-11-14T09:48:08.909530Z 127.0.0.1 - repo open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) /X/Y SVN/1.7.1-dev - 9486 2011-11-14T09:48:08.910096Z 127.0.0.1 - repo get-latest-rev 9486 2011-11-14T09:48:08.910211Z 127.0.0.1 - repo get-latest-rev 9486 2011-11-14T09:48:08.910339Z 127.0.0.1 - repo get-mergeinfo (/X/Y) inherited 9486 2011-11-14T09:48:08.910587Z 127.0.0.1 - repo reparent /X/Y 9486 2011-11-14T09:48:08.910675Z 127.0.0.1 - repo reparent /A/B 9486 2011-11-14T09:48:08.910743Z 127.0.0.1 - repo reparent /X/Y 9486 2011-11-14T09:48:08.911190Z 127.0.0.1 pm repo check-path /X/Y@21 9486 2011-11-14T09:48:08.911633Z 127.0.0.1 pm repo reparent /A/B 9486 2011-11-14T09:48:08.911712Z 127.0.0.1 pm repo check-path /A/B/C@21 9486 2011-11-14T09:48:08.930591Z 127.0.0.1 pm repo commit r22 -- Philip
Re: mod_dav_svn and Apache directive
Michaël Bruneel writes: > IMHO, given and URL '/', mod_dav_svn > should be able to understand the regular expression and treat '/' as > both the path to the repository and the path inside the repository. It > should not use raw '(?!viewvc)' data as it does now. That's only one case out of many. What about things like? Take that last one: "/foo/bar/zig/zag" matches "/foo/(?!xxx)/zig" but what is the path to the repository and what is the path inside the repository? What about SVNParentPath? Are multiple regepxs allowed? Which things should be supported? How should they behave? What is the advantage of supporting them? -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Bostjan Skufca writes: > On error, this is the log: > -- > 32537 2011-11-14T11:27:47.115320Z - testuser1 svn open 2 cap=(edit-pipeline > svndiff1 absent-entries depth mergeinfo log-revprops) /X/Y SVN/1.7.1 - > 32558 2011-11-14T11:27:52.216951Z - testuser1 svn open 2 cap=(edit-pipeline > svndiff1 absent-entries depth mergeinfo log-revprops) /X/Y SVN/1.7.1 - > 32558 2011-11-14T11:27:52.217898Z - testuser1 svn get-latest-rev > 32558 2011-11-14T11:27:52.218009Z - testuser1 svn get-latest-rev > 32558 2011-11-14T11:27:52.218086Z - testuser1 svn get-mergeinfo (/X/Y) > inherited > 32558 2011-11-14T11:27:52.238038Z - testuser1 svn reparent /X/Y > 32558 2011-11-14T11:27:52.238109Z - testuser1 svn reparent /A/B > 32558 2011-11-14T11:27:52.238140Z - testuser1 svn reparent /X/Y > 32558 2011-11-14T11:27:52.238178Z - testuser1 svn check-path /X/Y@19 > 32558 2011-11-14T11:27:52.238221Z - testuser1 svn reparent /A/B > 32558 2011-11-14T11:27:52.238256Z - testuser1 svn check-path /A/B/E@19 > ---------- > > On 14 November 2011 10:49, Philip Martin wrote: > >> Bostjan Skufca writes: >> >> > Nope, first step already fails (commit 3) if there are "[/]\n* = r" lines >> > present in authz file. >> > >> > It works if I create authz file like this (note the usage of rw >> everywhere): >> > [/A/B] >> > pm = rw >> > >> > [/X/Y] >> > pm = rw >> > - >> > >> > >> > It DOES NOTwork if I create authz file like this: >> > [/A/B] >> > pm = rw >> > >> > [/X/Y] >> > pm = r >> > - Your errorlog shows the username "testuser1" but the authz file uses the username "pm". -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Bostjan Skufca writes: > Authz is correct, I just changed pm to testuser1 because user already > existed and because it is bad to use auth credentials which have been sent > to mailing list on a public server:) But it makes it harder for us to work out whether you are doing things correctly. I installed Subversion 1.7.1 on my Windows box and the setup I showed works properly. I expect you have made a mistake with a username or path, but since you made arbitrary changes it's hard to say. Perhaps you could zip up a test repository that shows the problem and make it available? -- Philip
Re: line 1310: assertion failed
vincze béla writes: > using tortoise svn 1.7.1.22161 64bit on Win7. on updating a certain > folder, i've got the following crash message: > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 1310: assertion failed (added_status == svn_wc__db_status_added || > added_status == svn_wc__db_status_copied || added_status == > svn_wc__db_status_moved_here) > > also tried the latest nightly build (1.7.99.22265), with the very same > result. any suggestions are welcome on how to fix the problem. Not seen that particular error message before. Is this a working copy that was checked out using the 1.7 client or was it checked out using a 1.6 client and upgraded? If it was upgraded was it upgraded using 1.7.0 or 1.7.1? -- Philip
Re: AW: Unable to delete directory in repository, server version 1.7.1
Bostjan Skufca writes: > This does not work: > > svn cp svn://127.0.0.1/X/Y ^/A/B/C -m Test > Authentication realm: Test repo > Password for 'testuser1': > svn: E220004: Access denied The difference is that you are doing: svnserve -dr svn svn cp svn:/localhost/X/Y ^/A/B/C while my example was: svnserve -dr . svn cp svn://localhost/svn/X/Y ^/A/B/C It's got nothing to do with the authz files or the OS, it's how you invoke svnserve. I've raised issue 4060: http://subversion.tigris.org/issues/show_bug.cgi?id=4060 -- Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Ethan Bradford writes: > I upgraded a tree from 1.6.x directly to 1.7.1 and I'm getting this, so the > bug (or a similar one) definitely persists. > > I've got very big trees, so checkouts take most of a day, so redoing the > checkout isn't so convenient. What did the 1.6 working copy look like? Was it a sparse working copy? Did it have any local modifications? Any switched subdirectories? Any uncommitted moves, copies or deletes? Do you have the sqlite3 tool available to query the 1.7 working copy? sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0" -- Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Ethan Bradford writes: >> Do you have the sqlite3 tool available to query the 1.7 working copy? >> >> sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0" >> > > I installed sqlite3 to check this. The answer it gets is 0. Fine. Next: sqlite3 .svn/wc.db "select * from work_queue" There may be multiple lines. You should see something like: 6|(file-install A/f 1 0 1 1) "A/f" is just an example, in your case it will be the path of a file in your wc. So sqlite3 .svn/wc.db "select * from nodes where local_relpath='A/f'" You may see a checksum like: $sha1$7ab6a41b5d9bc8fad70cc0314c142c91feab4686 or it may be missing. If present: sqlite3 .svn/wc.db "select * from pristine where checksum like '%ab6a41b5d9bc8fad70cc0314c142c91feab4686" or sqlite3 .svn/wc.db "select * from pristine where checksum='\$sha1\$ab6a41b5d9bc8fad70cc0314c142c91feab4686" they should be the same (one escapes the '$' characters, the other drops them). -- Philip
Re: WC database corruption (1.7.1)
Neil Bird writes: >> Copy NODES_COPY into NODES: >> sqlite3 .svn/wc.db "insert into NODES select * from NODES_COPY" > > Oops. “Error: database disk image is malformed”. > > Which is a bit odd, since we copied NODES to NODES_COPY OK, and have > since re-created NODES! Odd indeed. Some sort of lazy, copy-on-write copy perhaps? I think that means that the corruption extends beyond the indices into the nodes table, and that makes it very hard to recover. -- Philip
Re: error report
Frank Liu - Orite Group writes: > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\workqueue.c' > line 672: assertion failed (checksum != NULL) That's the same error as reported in this thread: http://mail-archives.apache.org/mod_mbox/subversion-users/20.mbox/%3c87d3ctd7if@stat.home.lan%3E so the same questions apply. -- Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Ethan Bradford writes: >> sqlite3 .svn/wc.db "select * from work_queue" > > 3|(file-install 59 > DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1) > >> sqlite3 .svn/wc.db "select * from nodes where > local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'" > > 1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158|| > > So there's no checksum (according to other entries, it would be the field > just after "infinity"). That's very odd. Do you know which version of Subversion is running on the server? Running something like "curl -D - REPO_URL" might help find out. Are there other files with no checksum? sqlite3 .svn/wc.db "select count(*) from nodes where checksum is null and kind='file'" If there are other files then is there any pattern in the filenames? All in the same directory? All modified in the same commit? etc. sqlite3 .svn/wc.db "select local_relpath from nodes where checksum is null and kind='file'" Can you describe the recent activity in the working copy? Do you normally update the whole working copy or do you update subtrees? Did you commit changes in the Belarusian directory just before the update? The NODES row shows that the update was trying to install revision 3936 of the file. The filename is "BelarusianForceFreq.txt[MOVED]"; has this file been moved/copied within the repository? The last modified revision of the file is 3323, would you have committed that revision from this working copy? Do you know the revision before the update? It's possible that you can identify it using sqlite3 .svn/wc.db "select revision from nodes where revision != 3936" or perhaps sqlite3 .svn/wc.db "select revision from nodes where parent_relpath='DBBuild/Wordlists/Belarusian'" or perhaps you can guess the approximate revision based on dates? If you can identify the (approx?) revision before the update then running "svn log -vq URL" will allow you to see the sort of changes the update would have been making. I want to know what the update did to this file, did it just modify the content of the file, or add the file, or replace another file of the same name? Perhaps the whole directory was being added? Thanks for your help so far! -- Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Ethan Bradford writes: > I don't know what the server version is. cURL won't accept an svn: URL. Ah! svnserve. Then "telnet server.com 3690" will get the handshake which will tell us something. > Using the repo browser I can see the whole history. There are just two > versions of this file, none more recent than 3323. I think 3936 is a red > herring -- that was perhaps the tip revision for the whole repository when > the update was attempted. (The current tip is 4013.) Yes. 3936 is the revision to which you were updating. > I hate to confess to such absent mindedness, but I may have "svn delete"ed > 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. The nodes row was presence=normal. I wonder if the update was creating a tree conflict? Unlikely if there are no more recent changes than 3323. sqlite3 .svn/wc.db "select tree_conflict_data from actual_node" >> Thanks for your help so far! >> > > I'm happy to help, and I appreciate your time. Just to be clear, I > wouldn't dream of taking so much of your time just to solve my local > problem. You're digging into this to figure out the bug with change to the > 1.7.1 version (or maybe "svn update" within the 1.7.1 version), right? Yes. > Since I will likely need to do another checkout anyhow, I'm happy to try > experiments which might be destructive to my local copy. We may be able to recover it. Please make a copy of the wc.db file first. The following instructions assume there is no tree conflict. First we look at the workqueue, to confirm there is just one row. sqlite3 .svn/wc.db "select * from work_queue" Next look at the parent dir: sqlite3 .svn/wc.db "select op_depth, local_relpath, presence from nodes where local_relpath='DBBuild/Wordlists/Belarusian'" to confirm there is just one row with op-depth=0 and presence=normal or presence=incomplete. If the presence is something else then stop, the instuctions below do not apply. If presence is normal then set the parent dir to presence=incomplete: sqlite3 .svn/wc.db "update nodes set presence='incomplete' where local_relpath='DBBuild/Wordlists/Belarusian'" Now remove the corrupt file row: sqlite3 .svn/wc.db "delete from nodes where local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'" sqlite3 .svn/wc.db "delete from actual_node where local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'" Remove the now unversioned file (except you say it doesn't exist so skip this step). rm 'DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]' Remove the workqueue: sqlite3 .svn/wc.db "delete from work_queue" Run cleanup to remove locks: svn cleanup The working copy should be fixed; the next update will pull the missing file. -- Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Philip Martin writes: >> I hate to confess to such absent mindedness, but I may have "svn delete"ed >> 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_depth>0 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: "Couldn't open rep-cache database" (post commit FS processing)
Aleksandr Sidorenko 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)
Aleksandr Sidorenko 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, -- Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Aleksandr Sidorenko 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)
"Bert Huijben" 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. -- Philip
Re: "Couldn't open rep-cache database" (post commit FS processing)
Aleksandr Sidorenko 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)
Aleksandr Sidorenko 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: Assertion failed and crash with 1.7.1
Attila Nagy 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: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Sergey Skvortsov writes: > 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. Yes, POST requests are handled differently. You should be able to work around the problem by disabling the v2 protocol using: SVNAdvertiseV2Protocol off -- Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
[Adding dev] Philip Martin writes: > Sergey Skvortsov writes: > >> 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. > > Yes, POST requests are handled differently. You should be able to work > around the problem by disabling the v2 protocol using: > > SVNAdvertiseV2Protocol off The config is nested Locations with SVNParentPath: ... SVNParentPath /home/svn ... SVNParentPath /home/svn/foo This works apart from v2 commits to the nested Location. The reason it fails is that the POST gets directed to the containing Location, and that happens because of the root_dir setting in mod_dav_svn's dir_conf_t setup in mod_dav_svn.c:merge_dir_config: /* Prefer our parent's value over our new one - hence the swap. */ newconf->root_dir = INHERIT_VALUE(parent, child, root_dir); All the other fields use INHERIT_VALUE(child, parent, ...). This code was added in the first commit to the dav-mirror branch and has not been changed since. If I change it to prefer the child value for root_dir then POSTs go to the right Location and commits work. Changing it doesn't break my simple mirror setup. I don't understand why the code prefers the parent root_dir. I can't think of any reason why mirroring would make a difference. Can anyone explain? -- Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Philip Martin writes: > [Adding dev] Gah! Got the address wrong. I'll start a thread on dev. -- Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Stefan Sperling writes: > How do we avoid ambiguity when handling requests to nested Locations? > How can a client access a folder /bar inside a repository at Location /svn > if another repository exists at a nested Location /svn/bar? Yes, I was surprised too! If we assume that /svn and /svn/foo are directories that contain repositories then there can be no overlap: ... SVNParentPath /svn ... SVNParentPath /svn/foo /svn/repo/ and /svn/foo/repo/ cannot overlap. The only way there could be a problem is if /svn/foo were itself a repository, but the admin can ensure that is not the case. -- Philip
Re: Assertion failed and crash with 1.7.1
Attila Nagy writes:
> On 11/16/11 18:40, Philip Martin wrote:
>> Attila Nagy 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.
>>
> I will try this. Should this be true even for 10+ million files?
It depends on the ratio of changed files to total files. If there is
only one changed file then the single propget will be faster. If most
of the files are changed then the recursive propget will be faster.
--
Philip
Re: "svn commit" does not work with SVNParentPath in location and 1.7-client (HTTPv2)
Stefan Sperling writes: > Yes, of course it works with SVNParentPath. But I suspect that is > a result of implementation rather than concious design. Perhaps, but the line that stops it working looks like an outright bug. newconf->root_dir = INHERIT_VALUE(child, parent, root_dir); The order of parent and child in Subversion's INHERIT_VALUE macro only has an effect when nesting one Subversion location in another. When not nested the parent root_dir is NULL and the child value will be used whatever the order in INHERIT_VALUE. I can't see how it would ever be correct to inherit the parent root_dir value. This bug only comes to light because 1.7 uses the root_dir value when processing POST requests; 1.6 doesn't use POST requests so the wrong value had no effect. -- Philip
