RE: Server side svn:auto-props, how to set it correctly?
editor pops up and I enter all of the lines like: *.c = svn:eol-style=native *.cpp = svn:eol-style=native >> Do I also have to handle case here? >> I.e. for each file pattern do I have to figure out all case >> permutations too? >> Ex: >> *.cpp = svn:eol-style=native >> *.cpP = svn:eol-style=native >> *.cPp = svn:eol-style=native >> *.cPP = svn:eol-style=native >> *.Cpp = svn:eol-style=native >> *.CpP = svn:eol-style=native >> *.CPp = svn:eol-style=native >> *.CPP = svn:eol-style=native >> >> Or is it just the svn_apply_autoprops.py that uses case sensitive >> pattern recognition? >> I noticed a file not getting the property set when I used it... >> It was named in all caps. > >Paths in Subversion are case-sensitive. All patterns are case-sensitive >too. You'll either have to add all case permutations, as you showed >above, or teach your users some discipline in naming files. OK, I see. But I have an additional clarification question: In my local .subversion/config file (on Windows) I have this comment in the auto-props section. BTW it is the same on an Ubuntu machine: [auto-props] ### The format of the entries is: ### file-name-pattern = propname[=value][;propname[=value]...] ### The file-name-pattern can contain wildcards (such as '*' and ### '?'). All entries which match (case-insensitively) will be <<== ### applied to the file. Note that auto-props functionality ### must be enabled, which is typically done by setting the ### 'enable-auto-props' option. To me this indicates that the auto-props patterns are case-insensitive. Or is this a old artifact that has not been updated since it is just a comment? Or maybe the server side auto-props are case sensitive while the client side is not? PS: I usually communicate with this list via the Gmane news mirror, but today I have found that the gmane.org domain itself seems to have vanished from the Internet! Too bad if this is not a temporary issue. Looks not so good if the DNS name disappears rather than the server not responding. DS
Re: Reference to non-existent node
On Mon, Feb 12, 2018 at 8:41 AM, Davor Josipovic wrote: > It seems to me there is a bug in libapache2-mod-svn/stable,stable,now > 1.9.5-1+deb9u1 amd64 [installed]. > > I described it > here:https://superuser.com/questions/1293699/svn-error-occurred-while-committing-the-transaction > > I assume this is the correct place to report? > > I concerns the error 160014 "Reference to non-existent node". Some changes I > can not commit through https://, but I can commit directly through the > file:// protocol. > > Any idea's? Yes, this is the correct place to report such an issue. But to maximize your chances of people helping you, can you please copy the relevant contents / context to the mailinglist here, instead of forcing people to click a link? -- Johan
Re: Reference to non-existent node
Here you go (copy from the link): Can someone help me debug this issue? Everything works (i.e. I can commit, checkout, etc.) but this one commit always fails as described below. I tried checking out in a new repository, and committing, but same issue. Note also that this is a very large repository (500GB), and a very large commit (36k files totaling 10GB). This is the `apache2` error log: [Sat Feb 10 03:25:16.262765 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Could not DELETE /svn/repo/!svn/txn/463-e8. [500, #0] [Sat Feb 10 03:25:16.265881 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] could not abort transaction. [500, #2] [Sat Feb 10 03:25:16.265905 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Transaction '463-e8' cleanup failed [500, #2] [Sat Feb 10 03:25:16.265923 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0' [500, #2] [Sat Feb 10 03:25:16.265940 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove file '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0': No such file or directory [500, #2] [Sat Feb 10 03:25:30.640591 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Could not MERGE resource "/svn/repo/!svn/txn/463-e8" into "/svn/repo/repofolder". [500, #0] [Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] An error occurred while committing the transaction. [500, #160014] [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in filesystem '/mnt/vc/svn/repo/db' [500, #160014] The client side gives: done Committing transaction... svn: E175012: Commit failed (details follow): svn: E175012: Connection timed out svn: E200042: Additional errors: svn: E175002: Unexpected server error 500 'Internal Server Error' on '/svn/repo/!svn/txn/463-e8' First I thought this was a permission issue. So I did this on the server: su - www-data -s /bin/bash -c "svnadmin rmtxns /mnt/vc/svn/repo/ 463-e8" Transaction '463-e8' removed. No error whatsoever. Apache runs as `www-data`. Following permissions are set: chown www-data:www-data /mnt/vc -R chmod 0774 /mnt/vc -R I have run `svnadmin verify` and found no problems. `dmesg` doesn't show anything new. The apache svn config is pretty much default. KeepAlive On MaxKeepAliveRequests 0 # Set to 10h. Timeout 36000 SVNCompressionLevel 5 SVNInMemoryCacheSize 16384 SVNCacheTextDeltas On SVNCacheFullTexts On SVNAllowBulkUpdates Prefer DAV svn SVNParentPath /mnt/vc/svn SVNListParentPath On # Allow large request LimitXMLRequestBody 0 Extra info: Server: Debian 9.3 apache2/stable,stable,now 2.4.25-3+deb9u3 amd64 [installed] libapache2-mod-svn/stable,stable,now 1.9.5-1+deb9u1 amd64 [installed] Server svn client: 1.9.5-1+deb9u1 Client: svn 1.9.7 **EDIT:** I copied the working copy to the repository server. Then I tried to commit, but had the same error. I then relocated the working copy to direct repository location: `svn relocate file:///mnt/vc/svn/repo`. Commit worked this time. So it has to do something with `dav_svn`? On 18 February 2018 at 20:39, Johan Corveleyn mailto:jcor...@gmail.com>> wrote: On Mon, Feb 12, 2018 at 8:41 AM, Davor Josipovic mailto:dav...@live.com>> wrote: > It seems to me there is a bug in libapache2-mod-svn/stable,stable,now > 1.9.5-1+deb9u1 amd64 [installed]. > > I described it > here:https://superuser.com/questions/1293699/svn-error-occurred-while-committing-the-transaction > > I assume this is the correct place to report? > > I concerns the error 160014 "Reference to non-existent node". Some changes I > can not commit through https://, but I can commit directly through the > file:// protocol. > > Any idea's? Yes, this is the correct place to report such an issue. But to maximize your chances of people helping you, can you please copy the relevant contents / context to the mailinglist here, instead of forcing people to click a link? -- Johan
Re: Reference to non-existent node
Here you go (copy from the link): Can someone help me debug this issue? Everything works (i.e. I can commit, checkout, etc.) but this one commit always fails as described below. I tried checking out in a new repository, and committing, but same issue. Note also that this is a very large repository (500GB), and a very large commit (36k files totaling 10GB). This is the `apache2` error log: [Sat Feb 10 03:25:16.262765 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Could not DELETE /svn/repo/!svn/txn/463-e8. [500, #0] [Sat Feb 10 03:25:16.265881 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] could not abort transaction. [500, #2] [Sat Feb 10 03:25:16.265905 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Transaction '463-e8' cleanup failed [500, #2] [Sat Feb 10 03:25:16.265923 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0' [500, #2] [Sat Feb 10 03:25:16.265940 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove file '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0': No such file or directory [500, #2] [Sat Feb 10 03:25:30.640591 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Could not MERGE resource "/svn/repo/!svn/txn/463-e8" into "/svn/repo/repofolder". [500, #0] [Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] An error occurred while committing the transaction. [500, #160014] [Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in filesystem '/mnt/vc/svn/repo/db' [500, #160014] The client side gives: done Committing transaction... svn: E175012: Commit failed (details follow): svn: E175012: Connection timed out svn: E200042: Additional errors: svn: E175002: Unexpected server error 500 'Internal Server Error' on '/svn/repo/!svn/txn/463-e8' First I thought this was a permission issue. So I did this on the server: su - www-data -s /bin/bash -c "svnadmin rmtxns /mnt/vc/svn/repo/ 463-e8" Transaction '463-e8' removed. No error whatsoever. Apache runs as `www-data`. Following permissions are set: chown www-data:www-data /mnt/vc -R chmod 0774 /mnt/vc -R I have run `svnadmin verify` and found no problems. `dmesg` doesn't show anything new. The apache svn config is pretty much default. KeepAlive On MaxKeepAliveRequests 0 # Set to 10h. Timeout 36000 SVNCompressionLevel 5 SVNInMemoryCacheSize 16384 SVNCacheTextDeltas On SVNCacheFullTexts On SVNAllowBulkUpdates Prefer DAV svn SVNParentPath /mnt/vc/svn SVNListParentPath On # Allow large request LimitXMLRequestBody 0 Extra info: Server: Debian 9.3 apache2/stable,stable,now 2.4.25-3+deb9u3 amd64 [installed] libapache2-mod-svn/stable,stable,now 1.9.5-1+deb9u1 amd64 [installed] Server svn client: 1.9.5-1+deb9u1 Client: svn 1.9.7 **EDIT:** I copied the working copy to the repository server. Then I tried to commit, but had the same error. I then relocated the working copy to direct repository location: `svn relocate file:///mnt/vc/svn/repo`. Commit worked this time. So it has to do something with `dav_svn`? On 18 February 2018 at 20:39, Johan Corveleyn mailto:jcor...@gmail.com>> wrote: On Mon, Feb 12, 2018 at 8:41 AM, Davor Josipovic mailto:dav...@live.com>> wrote: > It seems to me there is a bug in libapache2-mod-svn/stable,stable,now > 1.9.5-1+deb9u1 amd64 [installed]. > > I described it > here:https://superuser.com/questions/1293699/svn-error-occurred-while-committing-the-transaction > > I assume this is the correct place to report? > > I concerns the error 160014 "Reference to non-existent node". Some changes I > can not commit through https://, but I can commit directly through the > file:// protocol. > > Any idea's? Yes, this is the correct place to report such an issue. But to maximize your chances of people helping you, can you please copy the relevant contents / context to the mailinglist here, instead of forcing people to click a link? -- Johan
Re: Server side svn:auto-props, how to set it correctly?
On Sun, Feb 18, 2018 at 8:56 AM, Bo Berglund wrote: > editor pops up and I enter all of the lines like: > *.c = svn:eol-style=native > *.cpp = svn:eol-style=native >>> Do I also have to handle case here? >>> I.e. for each file pattern do I have to figure out all case >>> permutations too? >>> Ex: >>> *.cpp = svn:eol-style=native >>> *.cpP = svn:eol-style=native >>> *.cPp = svn:eol-style=native >>> *.cPP = svn:eol-style=native >>> *.Cpp = svn:eol-style=native >>> *.CpP = svn:eol-style=native >>> *.CPp = svn:eol-style=native >>> *.CPP = svn:eol-style=native > To me this indicates that the auto-props patterns are case-insensitive. > Or is this a old artifact that has not been updated since it is just a > comment? > > Or maybe the server side auto-props are case sensitive while the client side > is not? > > PS: > I usually communicate with this list via the Gmane news mirror, but today I > have found that the gmane.org domain itself seems to have vanished from the > Internet! > Too bad if this is not a temporary issue. > Looks not so good if the DNS name disappears rather than the server not > responding. > DS Yes, it is. *Life* is case sensitive. Personally, I'd be startled to see mixed case in a three-letter suffix, But Subversion is, in many ways, based on CVS, which was originally written for UNIX and was, indeed, case sensitive in file name handling. So I'm not surprised at all by this.
