dreaded "Decompression of svndiff data failed" question
Hi all, I've searched the list and could not find an answer to this. I've run into the dreaded "Decompression of svndiff data failed" problem. Running http://www.szakmeister.net/fsfsverify/utility trying to fix it I end up with a string of errors. So far I've seen: - Error InvalidCompressedStream: Invalid compressed instr stream at offset (Error -3 while decompressing: incorrect header check) - Error InvalidCompressedStream: Invalid compressed data stream at offset (Error -3 while decompressing: incorrect data check) - Error InvalidWindow: The window header at offset xxx appears to be corrupted The offset change on [almost] all runs, so for the heck of it I scripted it to run 500 times (with and without the -f flag on each run). After 500 iterations it is still in error and keeps reporting a new offset on each subsequent run. I feel a bit like a goof asking this, but do you guys have any input on this? My guts tell me it's just looping somehow and if I set it to run for another 500 runs it would probably still be doing the same although with different numbers. The script also reports copying in an incresingly larger chunk of data (went from 600k to about 3MB now during those 500 runs). Anyone have any experience with anything taking this many runs or should I just give up already and re-create it saving as much as I can? I'm using svn 1.5.1 and FSFS. Thanks for your time, /Martin -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: dreaded "Decompression of svndiff data failed" question
On Thu, 23 Jun 2011 22:34:54 +0200, Stefan Sperling wrote: On Thu, Jun 23, 2011 at 08:50:05AM +0200, martin wrote: Hi all, I've searched the list and could not find an answer to this. I've run into the dreaded "Decompression of svndiff data failed" problem. Running http://www.szakmeister.net/fsfsverify/utility trying to fix it I end up with a string of errors. So far I've seen: - Error InvalidCompressedStream: Invalid compressed instr stream at offset (Error -3 while decompressing: incorrect header check) - Error InvalidCompressedStream: Invalid compressed data stream at offset (Error -3 while decompressing: incorrect data check) - Error InvalidWindow: The window header at offset xxx appears to be corrupted We have so far never been able to pin down the cause of such corruption problems. It could be a bug in Subversion (and you should be upgrading to avoid the ones that are already known), but it might just as well be a bug in some dependency Subversion is using (such as APR), or a bug in your operating system, or your disk controller or the disk itself having problems. If you'd like to share your corrupt revision file (privately if you like) I'd be happy to take a look at it. If you are lucky it's an instance of this problem: http://subversion.tigris.org/issues/show_bug.cgi?id=3705 fsfsverify can fix some instances of this but not all. I've fixed two such files manually so far which fsfsverify could not fix. And even if it's something else, maybe we can figure out what went wrong. And maybe if we see enough corrupt revision files we'll eventually be able to pin it down to a bug in Subversion and fix it. But the last time I was looking at a corrupted revision file it simply contained corrupted zip data. zlib could not decompress it anymore and nobody knew why. The file was simply broken and we could not reconstruct it within reasonable effort. So keep backups :) Thanks for all the feedback so far, It's an old legacy system I inherited and the earlier guys only did a hotcopy not verify, so on further investigation I found about 20 errors in total in all it's history (fatal ones). It's about half / half with the above error and else the checksum error. The latter I can at least get to a stage where I can 'skip' it and re-commit again. For the former I'm stuck with fsfsverify just looping, and the error revision had a zip file added to it just like yours. I'll have a look into it and see if I can share the corrupt file. Regarding hardware it's on a virtual server which hosts about 20 other guests (and none of those have any data corruption), so I don't think it's hw-related. It's not highly loaded nor are the VM host or any guests. It's running off CentOS and have about 66k revisions. I've tried to see if I can find a pattern in it, and from the about 20 errors one certain user is either the one comitting or the error occur when others merge in his data. I have 2 out of 20 errors which does not follow this pattern. Of course it could just be coincidence, but seems rather suspecious to me. Also, this guy was absent from ~3000 forthgoing revisions and no errors in the meantime, then he started comitting again and at exactly the same time errors started to occur (not his own commit but when someone merged his in later). He's using windows 7 but doesn't seem to have any malware or the like on his system. Also, there is no [seemingly] clear pattern about it having to be a zip-file. Ordinary text-commits seem to trigger it as well, although the majority is because of zip-files. I'm mostly inclined to believe it's something network-related, but the 'evidence' I have point in another direction. Again, I appreciate your time thinking about this, /Martin If I make any progress I'll be sure to let you guys know. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
using SVN mounted folders
Hello, Not quite sure where to go with those questions. Maybe they are known bugs, maybe they are known limitations? I have some portions of my hard-disk mounted as folders on others. E.g: C:\mycheckout is not a normal folder, but a mounted partition. A long time ago I was told that the problems with mounted NFS folders would be solved in SVN 1.7. I upgraded, though I use TortoiseSVN. I also updated my repositories (via TortoiseSVN) It appears that some commands like showing a log, do now work on NFS mounted folders. First think I noted is, that the root folder itself is now shown as "obstructed" for those checkouts. I tried "clean up", or reverting all. Still obstructed. Second, I noted that "apply patch" complains that is not a directory (not sure if that is SVN or tortoise related?) If anyone could shed some light, if any of this is known? if I should report any of that, or what the chances are of it being fixed, and how soon? Many thanks Martin p.s.: I am not subscribed, please keep cc me on replies
missing key from subversion-1.14.4.KEYS?
Hi, Is there a missing public key in the subversion-1.14.4.KEYS file currently available via https://subversion.apache.org/download.cgi - trying to verify the artifacts seems to be failing... > gpg --verify subversion-1.14.4.tar.gz.asc subversion-1.14.4.tar.gz [ ... ] gpg: Can't check signature: No public key ... until I was able to find a key for rinrab and import that too. Cheers, Gary -- THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED If this message was misdirected, Cirata Ltd. and its subsidiaries, ("Cirata") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of Cirata, unless the author is authorized by Cirata to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by Cirata. Although Cirata operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
Howto Disable Localistation?
Hi, I have a question: Is it possible to disable the localization? As a developer I prefer the english texts but unfortunately svn translate everything to the language of my OS. Help would be welcome! Br Martin
Possible Bug in merging from foreign repository
Hello, I tried to merge form a foreign repository path in a local repository path using current svn version 1.6.13 but it fails. Assuming you have a local empty svn directory: svn merge http://llvm.org/svn/llvm-project/dragonegg/trunk I get the following output: --- Merging (from foreign repository) r74898 through r83829 into '.': Allvm-debug.cpp Allvm-backend.cpp C gcc-patches Adarwin ... Aexports.map Gllvm-backend.cpp svn: Attempt to add tree conflict that already exists at 'gcc-patches' svn: Error reading spooled REPORT request response Do I something wrong? Should I report a bug? Thanks in advance, Martin
Secure Connection Truncated/Insufficient system resources
Hi, I'm getting a lot of errors when performing svn checkouts or updates. On the client side they appear as follows: Error: REPORT of '/svn//!svn/vcc/default': Could not read chunk size: Error: Secure connection truncated In the Apache SSL error log on the server the corresponding message is: [Fri Oct 29 13:10:15 2010] [error] [client ] Provider encountered an error while streaming a REPORT response. [500, #0] [Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred while driving the update report editor [500, #721450] [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file 'E:\\repositorydb\\revs\\20\\20795': Insufficient system resources exist to complete the requested service. After searching the mailing list archives and google for similar issues I tried the following changes: 1) Added an exclusion on the client side for my workspace folder to the Antivirus software 2) Set "SVNPathAuthz Off" in the server config 3) Set "Timeout" to 5 in the server config 4) Set "KeepAliveTimeout" to 25 in the server config Unfortunately none of them have worked. The "Insufficient system resources" message suggests a problem with the server but I don't see anything hogging memory or CPU and available disk space is fine. The repository is quite large if that makes a difference (278 Gb on the server). Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003 Client: TortoiseSVN 1.6.11 on Windows 7 Any ideas on what else I can try or advice on how I can further debug the problem? Also, what do those numbers at the end of the error lines, e.g. "[500, #721450]" mean? Regards, Martin Bagnall
RE: Secure Connection Truncated/Insufficient system resources
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: 29 October 2010 14:43 > To: Bagnall, Martin > Cc: users@subversion.apache.org > Subject: Re: Secure Connection Truncated/Insufficient system resources > > On Fri, Oct 29, 2010 at 2:35 PM, Bagnall, Martin > wrote: > > In the Apache SSL error log on the server the corresponding message > is: > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider > > encountered an error while streaming a REPORT response. [500, #0] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure > occurred > > while driving the update report editor [500, #721450] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read > file > > 'E:\\repositorydb\\revs\\20\\20795': Insufficient > system > > resources exist to complete the requested service. > > > > > > > The "Insufficient system resources" message suggests a problem with > the > > server but I don't see anything hogging memory or CPU and available > disk > > space is fine. The repository is quite large if that makes a > difference (278 > > Gb on the server). > > Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large > binary files in there? Yes, there are a lot of binary files in there. None are particularly large by themselves but there are many of them. > > Maybe the "insufficient resource" is related to the number of open > file handles? I don't know how this works on Windows (or how you can > configure it), but on *nix you have things like "ulimit" to limit the > maximum number of file descriptors a process can have open > simultaneously. I'm not sure how they work on Windows either but I'll take a look - thanks. > > Is there anything special about revision 20795, the one that is > referenced in the "insufficient system resources" message? Is it a > very large rev file in the repository (the file > 'E:\\repositorydb\\revs\\20\\20795')? I've checked the revision (and others referenced in similar errors, some from other repositories) and they all seem to involve a lot of files - again, none of the files are particularly large by themselves but there's a great deal of them associated with each commit. > > Cheers, > Johan > > > > > Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003 > > > > Client: TortoiseSVN 1.6.11 on Windows 7
RE: Secure Connection Truncated/Insufficient system resources
No, the repository isn't packed. I'll try out the registry fix and see what happens - thanks for the information. Upgrading to Windows 2008 is an option but I'd like to be sure that the OS version is the issue before doing that. From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com] Sent: 29 October 2010 17:10 To: Johan Corveleyn Cc: Bagnall, Martin; users@subversion.apache.org Subject: Re: Secure Connection Truncated/Insufficient system resources > > > > The "Insufficient system resources" message suggests a problem with the > > server but I don't see anything hogging memory or CPU and available disk > > space is fine. The repository is quite large if that makes a difference (278 > > Gb on the server). > > Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large > binary files in there? One would wish this to be true. I have many >300GB... > Maybe the "insufficient resource" is related to the number of open > file handles? I don't know how this works on Windows (or how you can > configure it), but on *nix you have things like "ulimit" to limit the > maximum number of file descriptors a process can have open > simultaneously. > > Is there anything special about revision 20795, the one that is > referenced in the "insufficient system resources" message? Is it a > very large rev file in the repository (the file > 'E:\\repositorydb\\revs\\20\\20795')? Is the repository packed? I also was fairly regularly seeing this error after I packed a large number of repositories on a windows server. (Not sure that was related since I did see it less frequently before the packing. SAN vendors were changed and I also bumped up the mod_dav version a few minor revs near same time.) The error is not always on the same repository nor even on the same revision or pack file. In most cases when this error occurs I was unable to login to a new session on the server. It seems that Windows 2003 (and before) has some fixed size memory buffers that can cause this problem. You can take a look at: http://support.microsoft.com/kb/935649 (There are other kb articles that apply as well. Just google for the mentioned registry keys.) Reconfiguring the mentioned registry keys seems to have helped this server. It does require a reboot and the usual disclaimer that making changes with regedit could completely disable your machine applies... Server 2008 supposedly dynamically allocates these paged memory pools, so upgrading may also help. Kevin R.
SVN mixed public\restricted access, please help!
Hi All, Ok I am trying to achieve a repository that at its base level everyone has read-only access without a username. But then at subsequent levels I would like to remove their access so they have none. I thought this could be accomplished with 1.6 with the addition of "~" and "$anonymous" but I have yet been able to get a working configuration. First off I tried setting up my apache just like this for my repo. Code: DAV svn SVNParentPath /var/svn # our access control policy AuthzSVNAccessFile /path/to/access/file # try anonymous access first, resort to real # authentication if necessary. Satisfy Any Require valid-user # how to authenticate a user AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file with this in my SVNAccessFile Code: [openclinica:/subdir] @clients = rw @svn-admin = rw [/] @svn-admin = rw I could not achieve a non authenticated user to gain access unless i added either "* = r" or "$anonymous = r" to the [/] in the access file. so now my file looks like this. Code: [openclinica:/subdir] @clients = rw @svn-admin = rw [/] @svn-admin = rw $anonymous = r Now I try to remove access to my subdir for the anonymous users by adding "~$anonymous = r" so my file now looks like this. Code: [openclinica:/subdir] @clients = rw @svn-admin = rw ~$anonymous = r [/] @svn-admin = rw $anonymous = r which apparently does nothing as anonymous users can still access my subdir and it does not force anyone to login. So then I tried the following. Code: [openclinica:/subdir] @clients = rw @svn-admin = rw $anonymous = [/] @svn-admin = rw $anonymous = r Which did not allow anonymous users to access my subdir, unfortunately it does not allow my authenticated users to access the subdir either. I have tried all these configuration with the "Satisfy Any" in apache enabled and disabled. Please help!! This was posted on svnforum.org http://www.svnforum.org/2017/viewtopic.php?p=32748#32748 Thanks, Shaun -- Shaun Martin Systems Administrator Akaza Research smar...@akazaresearch.com Office: (781) 547-8413 www.akazaresearch.com <http://www.akazaresearch.com/> www.openclinica.org <http://www.openclinica.org/> Open Source Platform for Clinical Research
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: Questions about svn:externals
Hi, Am 19.01.2011 10:02, schrieb David Aldrich: 1) Subversion allows you to commit a change within the > directory that uses the svn:external property. > This change will not be committed to the referenced > (source) directory/repo. You mean: not to the repository, where the other repository is linked into via svn:external? I can't imagine a circumstance where one would want I work with several "mixed" repositories (they use the same libs, referenced as externals), and it runs as I described. Mostly - my experience - the externals are used for link (shared) libraries or some other ressources used in several project or other places in a trunk (last thing prevents doubles). > to do this, so how can we prevent such commits being made? IMHO there is no way to prevent external commits - it would be contrary to the principles of svn, I think. The only way is: "svn export" the contents, after that svn:ignore the dir. 2) What would happen if the developer did not have read access > to the repo that is referenced in the svn:external? Would a checkout of the project that uses the external complete without error, > except that the external code would not appear? Hm, I think: the checkout will break. But I never checked this. Give it a try ;-) -- Greetings, Martin Rabl
Re: Questions about svn:externals
Hi again, never to old to learn something ... ;-) Am 19.01.2011 10:26, schrieb Martin Rabl: Am 19.01.2011 10:02, schrieb David Aldrich: > to do this, so how can we prevent such commits being made? IMHO there is no way to prevent external commits - it would be contrary to the principles of svn, I think. The only way is: "svn export" the contents, after that svn:ignore the dir. It is only on way, but not the best. You can fix an external onto a revision. Prepend the Revision with -r REVNO before the Url in the svn:external-Definition, so it looks like -r 1234 http://svn.somethingelse.org/repository/trunk/ somethingdir -- Greetings, Martin Rabl
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
JavaHL bindings - post-commit error messages
Hello, is there a way to receive get post-commit error messages on performing a commit with the JavaHL bindings? According to the SVN book: "If the post-commit hook returns a nonzero exit status, [...] anything that the hook printed to stderr will be marshalled back to the client, making it easier to diagnose hook failures." Best regards, Martin
Re: JavaHL bindings - post-commit error messages
Hi, Am Dienstag, den 16.08.2011, 11:14 -0400 schrieb Mark Phippard: > On Tue, Aug 16, 2011 at 11:09 AM, Martin Kutter > wrote: > > is there a way to receive get post-commit error messages on performing a > > commit with the JavaHL bindings? > > Subclipse uses JavaHL and I believe it shows these messages. Have you > registered a call back to receive the Notifications? > > http://subversion.apache.org/docs/javahl/1.6/org/tigris/subversion/javahl/Notify2.html > A quick test (set up a empty local repo with failing post-commit hook with some message on STDERR, add a folder to the wc and commit) reveals that Subclipse (1.6.18) does not show post-commit errors. I'll test-drive the notifications API though. Thanks, Martin
Re: JavaHL bindings - post-commit error messages
On Wed, 17 Aug 2011 19:56:13 +0200, Martin Kutter wrote: > Hi, > > Am Dienstag, den 16.08.2011, 11:14 -0400 schrieb Mark Phippard: >> On Tue, Aug 16, 2011 at 11:09 AM, Martin Kutter >> wrote: >> > is there a way to receive get post-commit error messages on performing >> > a >> > commit with the JavaHL bindings? >> >> Subclipse uses JavaHL and I believe it shows these messages. Have you >> registered a call back to receive the Notifications? >> >> http://subversion.apache.org/docs/javahl/1.6/org/tigris/subversion/javahl/Notify2.html >> Subclipse does not show post-commit error messages (at least not ). It also looks like JavaHL (1.6.17) does not transmit post-commit error messages not even in notify callbacks. Is this a bug? Steps to reproduce: 1. Create svn repo with failing post-commit hook and output on stderr 2. Test with svn command line client, checkout, perform some change, commit. Expected output is like this: D:\Martin\workspace\test>svn commit -m 'test' Adding site Committed revision 19. Warning: post-commit hook failed (exit code 1) with output: "Ausgabe auf STDERR" 3. make some change to the wc, and run the JUnit test below (with paths changed to match your system) Test fails, output is 1.6.17 (r1128011) Acttion: 17 ChangelistName: null ContentState: 1 ErrMsg: null Kind: 2 LockState: 1 MimeType: null Path: D:/Martin/workspace/test/site PathPrefix: D:/Martin/workspace PropState: 1 Revision: -1 Lock: null MergeRange: null Source: D:/Martin/workspace/test/site Commited revision: 18 Here's the test code: package org.tigris.subversion.javahl; import static org.junit.Assert.*; import java.util.ArrayList; import java.util.List; import org.junit.Test; public class SVNClientTest { private List notifications = new ArrayList(); @Test public void testCommit() { SVNClientInterface client = new SVNClient(); System.out.println(client.getVersion()); Notify2 notify = new Notify2() { @Override public void onNotify(NotifyInformation info) { System.out.println("Acttion: " + info.getAction()); System.out.println("ChangelistName: " + info.getChangelistName()); System.out.println("ContentState: " + info.getContentState()); System.out.println("ErrMsg: " + info.getErrMsg()); System.out.println("Kind: " + info.getKind()); System.out.println("LockState: " + info.getLockState()); System.out.println("MimeType: " + info.getMimeType()); System.out.println("Path: " + info.getPath()); System.out.println("PathPrefix: " + info.getPathPrefix()); System.out.println("PropState: " + info.getPropState()); System.out.println("Revision: " + info.getRevision()); System.out.println("Lock: " + info.getLock()); System.out.println("MergeRange: " + info.getMergeRange()); System.out.println("Source: " + info.getSource()); notifications.add(info); } }; client.notification2(notify); String[] paths = new String[] { "D:/Martin/workspace/test" }; String[] changeLists = new String[] {}; try { long result = client.commit(paths, "test", Depth.infinity, false, false, null, null); if (result > 0) { System.out.println("Commited revision: " + result); } } catch (ClientException e) { e.printStackTrace(); } List errors = new ArrayList(); for (NotifyInformation info : notifications) { if (info.getErrMsg() != null) errors.add(info.getErrMsg()); } assertNotSame(0, errors.size()); } } Martin
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
svn 1.7 info MUCH slower than previous versions?
Hi, I'm using Microsoft Source Server ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms680641(v=vs.85).aspx) to store source information about specific code revisions stored in subversion. It's basically a bunch of perl scripts, and part of it is running a 'svn info -R ' command to get a list of current revisions. Pre-1.7 this took about 10 seconds or so for the 56000 source files; with 1.7 however it's more on the order of 10+ minutes - a 50x slowdown... Is this a known problem? Are there any good workarounds for this? Cheers, Martin Hoffesommer
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 +, 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 +, 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