Re: SVN log --xml version omits line count
On Tue, 5 Mar 2024 at 19:01, Daniel Sahlberg wrote: > > Den tis 5 mars 2024 kl 18:09 skrev sebb : >> >> I would expect svn log --xml to include all the same info as the >> non-xml version, but that is not the case. The number of lines changed >> is not visible in the xml version. > > > The figure is the number of lines in the log message, not the number of > changed lines in the commit. Duh! That makes sense now. >> >> >> Is that intentional? >> >> If so, why? > > > One could imagine that a parser of the text output would like to know the > number of lines to read before expecting the next log message. (Looking for > "" > could break down if someone has that exact string in a log message). Indeed, that had occurred to me as a potential parsing issue. > With XML, there is no need to know how long the log message is; a > well-behaved parser should be able to find out. > > Kind regards, > Daniel Thanks for the quick response. >> >> Sebb >> Sample outputs below >> - >> >> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE -r1914220 >> >> r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov >> 2023) | 6 lines >> >> Update copyright year to 2023. >> >> * NOTICE, >> * subversion/libsvn_subr/version.c (svn_version_extended): >> Bump copyright year to 2023. >> >> >> >> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE >> -r1914220 --xml >> >> >> >revision="1914220"> >> hartmannathan >> 2023-11-30T04:47:33.883414Z >> Update copyright year to 2023. >> >> * NOTICE, >> * subversion/libsvn_subr/version.c (svn_version_extended): >> Bump copyright year to 2023. >> >> >>
SVN log --xml version omits line count
I would expect svn log --xml to include all the same info as the non-xml version, but that is not the case. The number of lines changed is not visible in the xml version. Is that intentional? If so, why? Sebb Sample outputs below - $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE -r1914220 r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov 2023) | 6 lines Update copyright year to 2023. * NOTICE, * subversion/libsvn_subr/version.c (svn_version_extended): Bump copyright year to 2023. $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE -r1914220 --xml hartmannathan 2023-11-30T04:47:33.883414Z Update copyright year to 2023. * NOTICE, * subversion/libsvn_subr/version.c (svn_version_extended): Bump copyright year to 2023.
Re: Crashes in subversion with unexpected targets
On Fri, 21 Apr 2023 at 18:00, sebb wrote: > > On Thu, 20 Apr 2023 at 07:10, Daniel Sahlberg > wrote: > > > > Den tors 20 apr. 2023 kl 01:22 skrev sebb : > >> > >> On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg > >> wrote: > >> > > >> > Den ons 19 apr. 2023 kl 11:44 skrev sebb : > >> >> > >> >> I've seen some crashes in SVN where the target does not have the > >> >> expected type. > >> > > >> > > >> > Both asserts also on a recent trunk build, so at least it isn't resolved > >> > yet. > >> > > >> >> > >> >> > >> >> For example: > >> >> > >> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf > >> >> svn: E235000: In file > >> >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c' > >> >> line 96: assertion failed > >> >> (svn_uri__is_ancestor(pathrev->repos_root_url, url)) > >> >> Aborted (core dumped) > >> > > >> > > >> > The same assert has been reported previously > >> > (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) > >> > although with a different use case. > >> > > >> > From what I can see in GDB, Subversion seems to be able to open a WebDAV > >> > session with www.apache.org. It asks for the > >> > DAV:version-controlled-configuration which seems to return > >> > https://www.apache.org/repos/asf. Now, since > >> > https://www.apache.org/foundation/records/ is not a child of > >> > https://www.apache.org/repos/asf it triggers an assert. > >> > > >> > Is it correct that https://www.apache.org/foundation/records/ responds > >> > to WebDAV commands, and why does it reply with > >> > https://www.apache.org/repos/asf? > >> > >> No idea. The redirect works fine for the main purpose which is > >> displaying a PDF file from SVN. > > > > > > Which redirect? > > Actually it is a rewrite: > > https://github.com/apache/www-site/blob/main/content/foundation/records/.htaccess There is no indication on the index page that the PDF file is served from SVN so it does not matter that SVN access is not supported. But of course it should fail gracefully. > > Subversion handles a 301/302 redirect just fine. The headers looks like a > > file served directly from the web server. (Maybe there is a > > behind-the-scenes redirect somehow that doesn't show here, but then should > > the server really reply to DAV requests? > > > > [[[ > > C:\Users\dsg>curl -I https://www.apache.org/foundation/records/990-2016.pdf > > HTTP/1.1 200 OK > > Connection: keep-alive > > Content-Length: 329732 > > Server: Apache > > Last-Modified: Sat, 15 Apr 2023 10:22:29 GMT > > ETag: > > "1909150//infrastructure/site/trunk/content/foundation/records/990-2016.pdf" > > Cache-Control: max-age=604800, max-age=3600 > > Content-Type: application/pdf > > Via: 1.1 www.apache.org, 1.1 varnish, 1.1 varnish > > Expires: Mon, 17 Apr 2023 13:30:44 GMT > > Content-Security-Policy: default-src 'self' 'unsafe-inline' > > https://www.apachecon.com/ https://www.google.com/cse/ > > https://cse.google.com/ https://www.googleapis.com/generate_204 > > http://*.google.com/generate_204 https://afs.googlesyndication.com/ > > https://csp.withgoogle.com/ https://www.google.com/images/ > > https://ssl.gstatic.com/ui/ https://docs.google.com/forms/ > > https://www.youtube.com/embed/; script-src 'self' 'unsafe-inline' > > 'unsafe-eval' https://cse.google.com/ > > http://cse.google.com/adsense/search/async-ads.js > > https://www.google.com/cse/ https://partner.googleadservices.com/; > > style-src 'self' 'unsafe-inline' https://www.google.com/cse/; > > frame-ancestors 'none'; > > Strict-Transport-Security: max-age=31536000; preload > > Accept-Ranges: bytes > > Date: Thu, 20 Apr 2023 06:01:27 GMT > > Age: 0 > > X-Served-By: cache-hel1410029-HEL, cache-bma1680-BMA > > X-Cache: HIT, HIT > > X-Cache-Hits: 1, 1 > > X-Timer: S1681970487.818068,VS0,VE377 > > Vary: Accept-Encoding > > ]]] > > > > > > Kind regards, > > Daniel
Re: Crashes in subversion with unexpected targets
On Thu, 20 Apr 2023 at 07:10, Daniel Sahlberg wrote: > > Den tors 20 apr. 2023 kl 01:22 skrev sebb : >> >> On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg >> wrote: >> > >> > Den ons 19 apr. 2023 kl 11:44 skrev sebb : >> >> >> >> I've seen some crashes in SVN where the target does not have the expected >> >> type. >> > >> > >> > Both asserts also on a recent trunk build, so at least it isn't resolved >> > yet. >> > >> >> >> >> >> >> For example: >> >> >> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf >> >> svn: E235000: In file >> >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c' >> >> line 96: assertion failed >> >> (svn_uri__is_ancestor(pathrev->repos_root_url, url)) >> >> Aborted (core dumped) >> > >> > >> > The same assert has been reported previously >> > (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) >> > although with a different use case. >> > >> > From what I can see in GDB, Subversion seems to be able to open a WebDAV >> > session with www.apache.org. It asks for the >> > DAV:version-controlled-configuration which seems to return >> > https://www.apache.org/repos/asf. Now, since >> > https://www.apache.org/foundation/records/ is not a child of >> > https://www.apache.org/repos/asf it triggers an assert. >> > >> > Is it correct that https://www.apache.org/foundation/records/ responds to >> > WebDAV commands, and why does it reply with >> > https://www.apache.org/repos/asf? >> >> No idea. The redirect works fine for the main purpose which is >> displaying a PDF file from SVN. > > > Which redirect? Actually it is a rewrite: https://github.com/apache/www-site/blob/main/content/foundation/records/.htaccess > Subversion handles a 301/302 redirect just fine. The headers looks like a > file served directly from the web server. (Maybe there is a behind-the-scenes > redirect somehow that doesn't show here, but then should the server really > reply to DAV requests? > > [[[ > C:\Users\dsg>curl -I https://www.apache.org/foundation/records/990-2016.pdf > HTTP/1.1 200 OK > Connection: keep-alive > Content-Length: 329732 > Server: Apache > Last-Modified: Sat, 15 Apr 2023 10:22:29 GMT > ETag: > "1909150//infrastructure/site/trunk/content/foundation/records/990-2016.pdf" > Cache-Control: max-age=604800, max-age=3600 > Content-Type: application/pdf > Via: 1.1 www.apache.org, 1.1 varnish, 1.1 varnish > Expires: Mon, 17 Apr 2023 13:30:44 GMT > Content-Security-Policy: default-src 'self' 'unsafe-inline' > https://www.apachecon.com/ https://www.google.com/cse/ > https://cse.google.com/ https://www.googleapis.com/generate_204 > http://*.google.com/generate_204 https://afs.googlesyndication.com/ > https://csp.withgoogle.com/ https://www.google.com/images/ > https://ssl.gstatic.com/ui/ https://docs.google.com/forms/ > https://www.youtube.com/embed/; script-src 'self' 'unsafe-inline' > 'unsafe-eval' https://cse.google.com/ > http://cse.google.com/adsense/search/async-ads.js https://www.google.com/cse/ > https://partner.googleadservices.com/; style-src 'self' 'unsafe-inline' > https://www.google.com/cse/; frame-ancestors 'none'; > Strict-Transport-Security: max-age=31536000; preload > Accept-Ranges: bytes > Date: Thu, 20 Apr 2023 06:01:27 GMT > Age: 0 > X-Served-By: cache-hel1410029-HEL, cache-bma1680-BMA > X-Cache: HIT, HIT > X-Cache-Hits: 1, 1 > X-Timer: S1681970487.818068,VS0,VE377 > Vary: Accept-Encoding > ]]] > > > Kind regards, > Daniel
Re: Crashes in subversion with unexpected targets
On Wed, 19 Apr 2023 at 23:52, Daniel Sahlberg wrote: > > Den ons 19 apr. 2023 kl 11:44 skrev sebb : >> >> I've seen some crashes in SVN where the target does not have the expected >> type. > > > Both asserts also on a recent trunk build, so at least it isn't resolved yet. > >> >> >> For example: >> >> $ svn info https://www.apache.org/foundation/records/990-2016.pdf >> svn: E235000: In file >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c' >> line 96: assertion failed >> (svn_uri__is_ancestor(pathrev->repos_root_url, url)) >> Aborted (core dumped) > > > The same assert has been reported previously > (https://lists.apache.org/thread/s24v9f8klx8pwn9lk0oqxng1cpxg12vw) although > with a different use case. > > From what I can see in GDB, Subversion seems to be able to open a WebDAV > session with www.apache.org. It asks for the > DAV:version-controlled-configuration which seems to return > https://www.apache.org/repos/asf. Now, since > https://www.apache.org/foundation/records/ is not a child of > https://www.apache.org/repos/asf it triggers an assert. > > Is it correct that https://www.apache.org/foundation/records/ responds to > WebDAV commands, and why does it reply with https://www.apache.org/repos/asf? No idea. The redirect works fine for the main purpose which is displaying a PDF file from SVN. > I'm leaning towards an incorrect server configuration. Maybe, but the point is that svn should not crash. >> $ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt >> Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt': >> svn:eol-style >> native >> >> $ svn ps svn:mime-type text/plain >> https://dist.apache.org/repos/dist/dev/whimsy/test.txt >> svn: E235000: In file >> '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c' >> line 1634: assertion failed (! svn_path_is_url(relative)) >> Aborted (core dumped) > > > Setting a versioned property on a URL is not supported if I'm reading the SVN > Book correctly > (https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn.c.propset). It > is obviously wrong to hit an assertion, there should be an error message > instead if trying to operate on a URL. Exactly. > I did a very quick sketch and it seems easy enough (a few lines of code in > propset-cmd.c), but it is getting too late to get it into style and run all > testcases tonight. It would be nice if it did work, but at least it should not crash. > Feel free to add this as an issue in JIRA. Thanks. > For the record, if someone else sees this thread. svnmucc should be the > correct tool in this case, it will create a new revision adding the versioned > property to the URL target. > > Kind regards, > Daniel
Crashes in subversion with unexpected targets
I've seen some crashes in SVN where the target does not have the expected type. For example: $ svn info https://www.apache.org/foundation/records/990-2016.pdf svn: E235000: In file '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_client/util.c' line 96: assertion failed (svn_uri__is_ancestor(pathrev->repos_root_url, url)) Aborted (core dumped) $ svn pl -v https://dist.apache.org/repos/dist/dev/whimsy/test.txt Properties on 'https://dist.apache.org/repos/dist/dev/whimsy/test.txt': svn:eol-style native $ svn ps svn:mime-type text/plain https://dist.apache.org/repos/dist/dev/whimsy/test.txt svn: E235000: In file '/build/subversion-owKwd0/subversion-1.13.0/subversion/libsvn_subr/dirent_uri.c' line 1634: assertion failed (! svn_path_is_url(relative)) Aborted (core dumped) $ svn --version svn, version 1.13.0 (r1867053) compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu Whilst these are invalid usages, I don't believe they should crash with an assertion. Do I need to raise bugs for these? Or are they already known? Sebb
Re: svnpubsub/commit-hook.py:65 - variable url assigned but not used
On Fri, 14 May 2021 at 12:22, Daniel Shahaf wrote: > > sebb wrote on Thu, 13 May 2021 14:29 +00:00: > > On Thu, 13 May 2021 at 15:16, sebb wrote: > > > On Thu, 13 May 2021 at 15:11, Daniel Shahaf > > > wrote: > > > > > > > > sebb wrote on Wed, May 12, 2021 at 11:49:41 +0100: > > > > > As the subject says > > > > > > > > Assuming opener.open() actually returns a URL, I don't see the problem > > > > here. The variable documents the return type for anyone who may want > > > > to extend the function. > > > > > > The problem is that it is not clear whether the variable is supposed > > > to be used or not. > > Then add a comment, or return the variable, etc.. Or drop the variable entirely. > > > Is it misspelt? > > ITYM "misspelled" ;-) No, I am using British English. > > > AIUI the convention for intentionally unused variables is to prefix > > > the name with an underscore, as this no longer triggers the warning in > > > PyLint > > Last I checked, docs.python.org said (single) leading underscores designated > class members that weren't part of the class's public API. > > > Furthermore, the method does not actually return a URL. > > Then the variable could be renamed. Or dropped. > > The method behaves like the following: > > https://python.readthedocs.io/en/v2.7.2/library/urllib2.html#urllib2.urlopen > > Thanks. > > Also, all the above discussion applies to revprop-change-hook.py, too. > > Daniel
Re: svnwcsub.py does not work across different SVN trees
On Thu, 13 May 2021 at 15:03, Daniel Shahaf wrote: > > sebb wrote on Wed, May 12, 2021 at 10:47:15 +0100: > > It looks like svnwcsub.py is not always able to update the workspace > > Don't use made-up terminology. The terms "repository" and "working > copy" have specific meanings. Use those terms to refer to what they > mean. Don't use those terms to mean other things and don't use other > terms to mean those things. > > > if the source URL is updated in the configuration file. > > > > I am seeing an error of the form: > > > > svn: E195012: Path '/www/ace.apache.org' does not share common version > > control ancestry with the requested switch location. Use > > --ignore-ancestry to disable this check. > > svn: E195012: 'https://svn-master.apache.org/repos/infra/sites/ace' > > shares no common ancestry with '/www/ace.apache.org > > > > Is there any reason why the svn switch command does not include the > > suggested option? > > You mean, why svnwcsub.py doesn't pass that option? For starters, > because svnwcsub.py was written before that option existed. Any other reasons? > > Seems to me it ought to be possible to replace the checkout with a > > different SVN repo without needing to manually remove the existing > > checkout. > > -1. That would be data loss in case of a new svnwcsub deployment where > the target dir already exists and is non-empty. This project is > generally rather averse to the possibility of data loss. This is not about a new deployment, but about changing the URL for an existing WC.
Re: svnpubsub/commit-hook.py:65 - variable url assigned but not used
Furthermore, the method does not actually return a URL. The method behaves like the following: https://python.readthedocs.io/en/v2.7.2/library/urllib2.html#urllib2.urlopen On Thu, 13 May 2021 at 15:16, sebb wrote: > > The problem is that it is not clear whether the variable is supposed > to be used or not. > Is it misspelt? > > AIUI the convention for intentionally unused variables is to prefix > the name with an underscore, as this no longer triggers the warning in > PyLint > > On Thu, 13 May 2021 at 15:11, Daniel Shahaf wrote: > > > > sebb wrote on Wed, May 12, 2021 at 11:49:41 +0100: > > > As the subject says > > > > Assuming opener.open() actually returns a URL, I don't see the problem > > here. The variable documents the return type for anyone who may want > > to extend the function.
Re: svnpubsub/commit-hook.py:65 - variable url assigned but not used
The problem is that it is not clear whether the variable is supposed to be used or not. Is it misspelt? AIUI the convention for intentionally unused variables is to prefix the name with an underscore, as this no longer triggers the warning in PyLint On Thu, 13 May 2021 at 15:11, Daniel Shahaf wrote: > > sebb wrote on Wed, May 12, 2021 at 11:49:41 +0100: > > As the subject says > > Assuming opener.open() actually returns a URL, I don't see the problem > here. The variable documents the return type for anyone who may want > to extend the function.
svnwcsub.py - various pylint errors
pylint reports quite a few warnings and errors: svnwcsub.py:55:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:57:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:61:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:63:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:67:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:69:0: W0311: Bad indentation. Found 2 spaces, expected 4 (bad-indentation) svnwcsub.py:87:4: W0612: Unused variable 'output' (unused-variable) svnwcsub.py:115:12: W0612: Unused variable 'x' (unused-variable) svnwcsub.py:439:38: W0613: Unused argument 'event_arg' (unused-argument) svnwcsub.py:46:0: W0611: Unused import errno (unused-import) svnwcsub.py:58:0: W0611: Unused import time (unused-import) svnwcsub.py:65:0: W0611: Unused import functools (unused-import) svnwcsub.py:67:2: W0611: Unused import urlparse (unused-import) svnwcsub.py:69:2: W0611: Unused urllib.parse imported as urlparse (unused-import) svnwcsub.py:378:18: E0602: Undefined variable 'fname' (undefined-variable) (should be self.fname) Sebb
svnpubsub/commit-hook.py:65 - variable url assigned but not used
As the subject says
watcher.py no longer uses urlparse
As the subject says.
svnwcsub.py does not work across different SVN trees
It looks like svnwcsub.py is not always able to update the workspace if the source URL is updated in the configuration file. I am seeing an error of the form: svn: E195012: Path '/www/ace.apache.org' does not share common version control ancestry with the requested switch location. Use --ignore-ancestry to disable this check. svn: E195012: 'https://svn-master.apache.org/repos/infra/sites/ace' shares no common ancestry with '/www/ace.apache.org Is there any reason why the svn switch command does not include the suggested option? Seems to me it ought to be possible to replace the checkout with a different SVN repo without needing to manually remove the existing checkout. Sebb.
Re: svnpubsub/svnwcsub.py crashes if pidfile option is not supplied
On Tue, 11 May 2021 at 19:33, Daniel Shahaf wrote:
>
> sebb wrote on Tue, 11 May 2021 16:25 +00:00:
> > As the subject says, the code crashes as below unless --pidfile is provided
> >
> > File "./svnwcsub.py", line 559, in
> > main(sys.argv[1:])
> > File "./svnwcsub.py", line 548, in main
> > d = Daemon('/dev/null', os.path.abspath(options.pidfile),
> > File
> > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py",
> > line 367, in abspath
> > if not isabs(path):
> > File
> > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py",
> > line 54, in isabs
> > return s.startswith('/')
> > AttributeError: 'NoneType' object has no attribute 'startswith'
>
> Any chance of a patch? Feel free to just make --pidfile required, if
> making it properly optional is a larger diff than you have tuits for.
svnwcsub.patch
Description: Binary data
svnpubsub/svnwcsub.py crashes if pidfile option is not supplied
As the subject says, the code crashes as below unless --pidfile is provided
File "./svnwcsub.py", line 559, in
main(sys.argv[1:])
File "./svnwcsub.py", line 548, in main
d = Daemon('/dev/null', os.path.abspath(options.pidfile),
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py",
line 367, in abspath
if not isabs(path):
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py",
line 54, in isabs
return s.startswith('/')
AttributeError: 'NoneType' object has no attribute 'startswith'
Syntax error at svnpubsub/daemonize.py:59
The code reads: 58:except (ChildTerminatedAbnormally, ChildForkFailed, 59:DaemonTerminatedAbnormally, DaemonForkFailed), e: The ',' is invalid syntax; it should be 'as'. There is also an invalid comment at line 20: 19: # This software lives at: 20: #http://gstein.googlecode.com/svn/trunk/python/daemonize.py
Re: svnmucc: new commands: add and modify/update
On Fri, 24 Jul 2020 at 07:06, Daniel Shahaf wrote: > > Daniel Sahlberg wrote on Fri, 24 Jul 2020 05:53 +00:00: > > Den fre 24 juli 2020 01:46sebb skrev: > > > I am suggesting that 'add' functionality could be added to svnmucc itself. > > > This would make it more versatile, especially for use in shell scripts. > > > > Unless I'm mistaken, add is a purely local action within a working > > copy. And the point with svnmucc is that you work with a repository > > without having a wc. How should add work with svnmucc? > > It would work exactly like «svnmucc put $dirent $URL», except that it > would fail if $URL already exists, similar to open(O_EXCL) in C. Yes, please! Note that svn add is indeed local, but the commit will fail if the remote file exists.
Re: svnmucc: new commands: add and modify/update
On Thu, 23 Jul 2020 at 23:44, Daniel Shahaf wrote: > > sebb wrote on Thu, 23 Jul 2020 11:30 +0100: > > On Thu, 23 Jul 2020 at 00:59, Daniel Shahaf wrote: > > > > > > sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > > > > The SVN put command can add a new file or update an existing one. > > > > > > > > As part of a batch update it may be necessary to ensure that a > > > > particular file will be created and not updated - or vice versa. > > > > That is currently not at all easy to do, which is a shame as svnmucc > > > > is otherwise very useful for writing atomic updates that are not > > > > possible with the svn client. > > > > > > What can svnmucc(1) do that svn(1) can't? > > > > Atomic updates. > > > > AIUI an svnmucc script only succeeds if all the individual commands succeed. > > > > To do that with single commands would require reversion and/or retries. > > > > If the reason for an svn client failure is a network or server issue, > > it's going to be very difficult to tidy up. > > You're describing CVS, not Subversion. No: I'm not referring to tidying up the repository itself, but the application level inconsistency that can result if a related sequence of svn commits does not complete. The issue I am trying to solve is how to ensure related changes to a subversion repository either all occur or none do. For example, adding a new file to a directory, and updating a listing with details of that file. The file must not already exist. The listing is in a different part of the repository. Whilst it would probably be possible to create a sparse checkout of the different parts of the repository, this is not trivial. It seems like an ideal job for svnmucc. However svnmucc does not directly support svn 'add' functionality. Whilst this can also be worked round, it is quite tedious and easy to get wrong. I am suggesting that 'add' functionality could be added to svnmucc itself. This would make it more versatile, especially for use in shell scripts. (*) I am referring to application-level consistency here, not consistency of the repository itself.
Re: svnmucc: new commands: add and modify/update
On Thu, 23 Jul 2020 at 00:59, Daniel Shahaf wrote: > > sebb wrote on Wed, 22 Jul 2020 22:44 +0100: > > The SVN put command can add a new file or update an existing one. > > > > As part of a batch update it may be necessary to ensure that a > > particular file will be created and not updated - or vice versa. > > That is currently not at all easy to do, which is a shame as svnmucc > > is otherwise very useful for writing atomic updates that are not > > possible with the svn client. > > What can svnmucc(1) do that svn(1) can't? Atomic updates. AIUI an svnmucc script only succeeds if all the individual commands succeed. To do that with single commands would require reversion and/or retries. If the reason for an svn client failure is a network or server issue, it's going to be very difficult to tidy up. > > Would there be any support for extending svnmucc to add these operations? > > Either as options to put, or as separate commands. > > The standard solutions for your situation are: > > 1. > - Get HEAD's value as an integer > - Check file existence/inexistence in that revision > - Run 'svnmucc -r' > > 2. > svn co --depth=empty $URL wc > svn up --set-depth=infinity wc/foo > ⋮ > # (as posted in > https://mail-archives.apache.org/mod_mbox/subversion-users/202007.mbox/%3C20200712142604.128f80eb%40tarpaulin.shahaf.local2%3E) > > In what ways do they fall short? >
Re: svnmucc --revision 0 no longer works when creating a file
On Thu, 23 Jul 2020 at 01:17, Daniel Shahaf wrote: > > sebb wrote on Wed, 22 Jul 2020 22:34 +0100: > > On Wed, 22 Jul 2020 at 17:46, Nathan Hartman > > wrote: > > > > > > On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > > > > Use the machine-parseable E42 error codes. That's exactly what > > > > > they're for. (which-error.py and svn_error_symbolic_name() can be > > > > > used > > > > > to convert numbers to symbolic names.) > > > > > > > > Where are these error codes defined? > > > > I could not find any reference to them in the documentation. > > > > > > If you mean where in the source code: > > > > > > subversion/include/svn_error_codes.h > > > which is included by subversion/include/svn_error.h, which is further > > > included by subversion/svnmucc/svnmucc.c. > > > > > > Hope that helps, > > > > Thanks, but not really. > > > > If the error codes are intended to be machine-parseable then the > > programmer needs to have documentation of the values and their > > meanings. > > There needs to be at least a mention in the documentation that such > > codes exist and where to find the values. If there is such a mention, > > I could not find it. > > Doxygen docs of svn_error_t::apr_err. But how does one find that information? > > Also, I had a look at the file and it does not show the numeric > > values, > > I refer you again to which-error.py. Again, how is one supposed to know about this script? Also, I assume this requires Python. > > and whilst there is a text string associated with each one it > > does not detail when it might be used. > > Nor indeed do the strings agree with the actual messages generated by > > SVN as far as I can tell. > > No, they don't. The strings in that file are defaults, only used when > the line of code that raised an error didn't provide a more specific > string. > > > e.g. svn list reports the following: > > > > svn: warning: W160013: Path '/x' not found > > svn: E29: Could not list all targets because some targets don't exist > > Great. Run which-error.py on this and you'll find that the former code > is SVN_ERR_FS_NOT_FOUND. That's basically the svn API equivalent of > ENOENT, i.e., "There's no node by that name in the versioned > filesystem". Therefore, you'll want to write your script to handle > E160013 errors by ignoring them and continuing. I would need to know whether E29 can only be produced when a target does not exist. Otherwise it might look like the file does not exist when it does. > The complication here is that `svn list` supports multiple target > arguments, and has to handle the case that some but not all of them are > invalid. It does so by reporting the errors from individual targets as > W* codes rather than E* codes and adding a generic E29 error at the > end. You can either parse stderr despite this complication, or use the > API directly, in which case you'll sidestep this complication entirely > (you'll get just one integer, rather than two). What API are you referring to here? > Daniel
svnmucc: new commands: add and modify/update
The SVN put command can add a new file or update an existing one. As part of a batch update it may be necessary to ensure that a particular file will be created and not updated - or vice versa. That is currently not at all easy to do, which is a shame as svnmucc is otherwise very useful for writing atomic updates that are not possible with the svn client. Would there be any support for extending svnmucc to add these operations? Either as options to put, or as separate commands. Sebb.
Re: svnmucc --revision 0 no longer works when creating a file
On Wed, 22 Jul 2020 at 17:46, Nathan Hartman wrote: > > On Wed, Jul 22, 2020 at 12:10 PM sebb wrote: > > > Use the machine-parseable E42 error codes. That's exactly what > > > they're for. (which-error.py and svn_error_symbolic_name() can be used > > > to convert numbers to symbolic names.) > > > > Where are these error codes defined? > > I could not find any reference to them in the documentation. > > If you mean where in the source code: > > subversion/include/svn_error_codes.h > which is included by subversion/include/svn_error.h, which is further > included by subversion/svnmucc/svnmucc.c. > > Hope that helps, Thanks, but not really. If the error codes are intended to be machine-parseable then the programmer needs to have documentation of the values and their meanings. There needs to be at least a mention in the documentation that such codes exist and where to find the values. If there is such a mention, I could not find it. Also, I had a look at the file and it does not show the numeric values, and whilst there is a text string associated with each one it does not detail when it might be used. Nor indeed do the strings agree with the actual messages generated by SVN as far as I can tell. e.g. svn list reports the following: svn: warning: W160013: Path '/x' not found svn: E29: Could not list all targets because some targets don't exist But I could not find similar strings in the header file; e.g. the only string containing targets is: "Duplicate targets in svn:externals property" So I don't think the header file is suitable for writing software to analyse the error codes. > Nathan
Re: svnmucc --revision 0 no longer works when creating a file
On Sun, 12 Jul 2020 at 18:13, Daniel Shahaf wrote:
>
> sebb wrote on Sun, 12 Jul 2020 16:55 +0100:
> > On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
> > >
> > > sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > > > When I first started using svnmucc, it used to be the case that
> > > > svnmucc 'put' --revision 0 would fail if the target file already
> > > > existed. This no longer happens.
> > > >
> > >
> > > Is the file-to-be's parent directory the root directory?
> >
> > No, it's not.
> >
> > > If that isn't the case, then the new behaviour is correct.
> >
> > Why is that?
> >
>
> Because the target of the 'put' operation didn't exist at r0, and the
> base revision is specified to be a revision in which the target of the
> operation existed. (See svn_delta_editor_t::open_root()'s docstring.)
>
> Moreover, even that syntax it did work, it should arguably fail if the
> file had been created and subsequently deleted, which isn't the same
> semantics as the algorithm you posted.
>
> > > You might wish to post the error message.
> >
> > Just tried with a local SVN repo:
> >
> > $ svnmucc -mBug --revision 0 -- put /dev/null
> > file:///var/tools/svnrep/asf/x/b.tmp
> > svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
> > because it is not a directory
> >
> > That message is wrong, because /x/ *is* a directory.
>
> Runnable reproduction recipe, please.
>
> I wonder if the error is reported because /x isn't a directory _at r0_,
> per the above explanation. What happens if you try to put a file into
> the root directory? If you keep the target as-is but change the value
> of the --revision argument to the revision in which ^/x was created? To
> the revision just before that?
>
> > The same error occurs regardless of whether b.tmp is present.
> >
> > > > The previous behaviour was very useful, so are there any plans to
> > > > reinstate it?
> > > >
> > >
> > > Patches welcome. (You'll have to propose a new syntax, of course.)
> >
> > --revision -1
>
> -1 actually already has a meaning (SVN_INVALID_REVNUM). More
> importantly, this approach makes it impossible to specify a base
> revision if any single operation is a "create exclusively" operation.
> Shouldn't the new syntax be per-operation, so people could combine
> "create exclusively" operations, "create or update" operations, and
> other kinds of operations in the same command line, _and_ have the
> option of specifying a base revision as well?
>
> > > > I don't think there is a straightforward way to guarantee the same
> > > > behaviour now.
> > > >
> > >
> > > Try:
> > >
> > > svn checkout --depth=empty $URL wc
> > > cd wc
> > > svn up --set-depth=infinite iota
> > > touch iota
> > > svn add iota
> > > svn commit -mm
> > > svn up --set-depth=empty iota
> > > svn cleanup# prune .svn/pristine
> >
> > Not exactly straightforward, but it does fail if the file has been
> > created meanwhile
> > However the error response still has to be analysed
> >
> > Also the script can fail in at least two places, depending on when the
> > file is created.
> >
>
> And why is that a problem?
>
> In the future, please provide all the needed information (reproduction
> recipes, error messages, the answer to "Why is it a problem?") up front.
> I don't intend to guess the missing parts and I don't have the
> brainwidth to prompt you every time.
>
> > > > The closest I could get is:
> > > >
> > > > 1) get current parent directory revision
> > > > 2) check if target file does not exist. This is not as easy as it
> > > > sounds, as the target directory may have too many files to list
> > > > efficiently, and any other file-based command may fail for a reason
> > > > other than a missing file.
> > >
> > > How is «svn info $URL/to/file@$REV» not sufficient? You can use
> > > $URL/to{,/file}@$REV if you want, too.
> >
> > Same issue: svn info only returns success if the file exists.
> > An error may mean the file did not exist or something else, so the
> > error text has to be analysed.
>
> Use the machine-parseable E42 error codes. That's exactly what
> they're for. (which-error.py and svn_error_symbolic_name() can be used
> to convert numbers to symbolic names.)
Where are these error codes defined?
I could not find any reference to them in the documentation.
> > > > 3) Put the file using the revision obtained in step 1.
> > > > AFAICT this is guaranteed not to replace an existing file.
> > > >
> > > > However it may fail to create the file if the target directory has
> > > > been updated in the meantime.
> > > >
> > > > It's only safe to repeat the attempted create if the command failed
> > > > due to an out of date revision.
> > > > So the failure reason will have to be analysed.
> > >
> > > What part of the above is a problem, and why?
> >
> > It requires analysing the error response, which is likely to be fragile.
>
> See above.
Re: svnmucc --revision 0 no longer works when creating a file
On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf wrote:
>
> sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > When I first started using svnmucc, it used to be the case that
> > svnmucc 'put' --revision 0 would fail if the target file already
> > existed. This no longer happens.
> >
>
> Is the file-to-be's parent directory the root directory?
No, it's not.
> If that isn't the case, then the new behaviour is correct.
Why is that?
> You might wish to post the error message.
Just tried with a local SVN repo:
$ svnmucc -mBug --revision 0 -- put /dev/null
file:///var/tools/svnrep/asf/x/b.tmp
svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
because it is not a directory
That message is wrong, because /x/ *is* a directory.
The same error occurs regardless of whether b.tmp is present.
> > The previous behaviour was very useful, so are there any plans to reinstate
> > it?
> >
>
> Patches welcome. (You'll have to propose a new syntax, of course.)
--revision -1
> > I don't think there is a straightforward way to guarantee the same
> > behaviour now.
> >
>
> Try:
>
> svn checkout --depth=empty $URL wc
> cd wc
> svn up --set-depth=infinite iota
> touch iota
> svn add iota
> svn commit -mm
> svn up --set-depth=empty iota
> svn cleanup# prune .svn/pristine
Not exactly straightforward, but it does fail if the file has been
created meanwhile
However the error response still has to be analysed
Also the script can fail in at least two places, depending on when the
file is created.
> > The closest I could get is:
> >
> > 1) get current parent directory revision
> > 2) check if target file does not exist. This is not as easy as it
> > sounds, as the target directory may have too many files to list
> > efficiently, and any other file-based command may fail for a reason
> > other than a missing file.
>
> How is «svn info $URL/to/file@$REV» not sufficient? You can use
> $URL/to{,/file}@$REV if you want, too.
Same issue: svn info only returns success if the file exists.
An error may mean the file did not exist or something else, so the
error text has to be analysed.
> > 3) Put the file using the revision obtained in step 1.
> > AFAICT this is guaranteed not to replace an existing file.
> >
> > However it may fail to create the file if the target directory has
> > been updated in the meantime.
> >
> > It's only safe to repeat the attempted create if the command failed
> > due to an out of date revision.
> > So the failure reason will have to be analysed.
>
> What part of the above is a problem, and why?
It requires analysing the error response, which is likely to be fragile.
svnmucc --revision 0 no longer works when creating a file
When I first started using svnmucc, it used to be the case that svnmucc 'put' --revision 0 would fail if the target file already existed. This no longer happens. The previous behaviour was very useful, so are there any plans to reinstate it? I don't think there is a straightforward way to guarantee the same behaviour now. The closest I could get is: 1) get current parent directory revision 2) check if target file does not exist. This is not as easy as it sounds, as the target directory may have too many files to list efficiently, and any other file-based command may fail for a reason other than a missing file. 3) Put the file using the revision obtained in step 1. AFAICT this is guaranteed not to replace an existing file. However it may fail to create the file if the target directory has been updated in the meantime. It's only safe to repeat the attempted create if the command failed due to an out of date revision. So the failure reason will have to be analysed.
Restriction on svnmucc targets in same repository?
Is there any restriction on svnmucc targets which can appear in a batch script? I assume that all targets must be in the same repository, but are there any further restrictions, e.g. must they have the same initial root directory path? I ask this because I am getting the following: svnmucc: E175013: Access to '/.../!svn/rvr/98024' forbidden The script is equivalent to: put file.txt top1/file.txt mv top2/d1/file2.txt top2/d2/file2.txt top1 and top2 are different top-level root folders in the same repository, i.e. svn info root/top1 gives the same UUID as svn info root/top2 Sebb
Re: What is the permissible character set for @group references in path-based auth?
On Sun, 15 Dec 2019 at 00:52, Branko Čibej wrote: > On 14.12.2019 14:08, sebb wrote: > > On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf > <mailto:d...@daniel.shahaf.name>> wrote: > > > > sebb wrote on Sat, 14 Dec 2019 09:12 +00:00: > > > The only documentation I could find [1] defines a key using > > : > > > > > > ::= (any character except ) > > > > > > However the character domain is not specified as far as I can tell. > > > > I don't know where you're quoting that from. It's not on the linked > > page or anywhere else that I can find. It's also patently false > > because '=' and ' ' > > can't be parts of a group name, because if they were then «@foo = > > rw» would > > be misparsed. > > > > > > I should have been clearer. > > I did not mean that a key consists of text-char only. > > > > The key is defined in BNF in the Formal Definition section (once opened). > > Follow the BNF through, and one of refs is : > > > > key => key-cont => key-char => text-char > > (where => means refers to) > > > > i.e. the key definition uses text-char. > > > > So in order to know what is allowed in a key, one needs to know what a > > character is. > > So what exactly is missing from the definition: "any character except > "? > > The character set. Is it ASCII or UTF-8 or something else? Can one use CR, NUL or DEL in keys? Have such characters been tested? > Subversion doesn't define the source character set. It does implicitly > expect it to be a superset of ASCII, and uses UTF-8 internally. That > document intentionally doesn't define what a "character" is except for > special codes that the parser recognizes as delimiters, depending on > context. > > -- Brane > >
Re: Bug in docs regarding case-sensitivity?
On Sat, 14 Dec 2019 at 13:33, Daniel Shahaf wrote: > sebb wrote on Sat, 14 Dec 2019 13:17 +00:00: > > On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf > wrote: > > > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > > > > The code comment here [1] and the wiki [2] both state that section > name > > > > matching is case-insensitive. > > > > > > > > However my reading of the document here [3] says this changed in > version 1.7. > > > > > > Thank you for taking the time to point out the specific text within > that > > > page you had in mind, to save us all looking for it. (It's the first > > > "No Entry" box.) > > > > > > > These docs don't seem consistent to me. > > > > > > The two documents describe different layers. [1] and [2] describe the > > > configuration parsing module (svn_config_*), whereas [3] — says that > > > the implementation of authz (≤1.6) did case conversions before or > after > > > calling svn_config_*(). > > > > > > > However [2] says: > > > > [2] is not normative. The C API docs are normative. The API errata, > release notes, and CVE advisories are all fair game. But the wiki serves > as the whiteboard in our virtual office; it isn't API documentation. > > However [1] says: "Section and option names are case-insensitive, but case is preserved." Is that still accurate? > > "This means that, for example, you cannot have two different sections > > named [Section] and [section];" > > This was true through 1.6.x. In 1.7.x, consumers of the svn_config_* > API can decide whether section-names should be case-sensitive or not. > See svn_config_read(): > > [[[ > /** Similar to svn_config_read2, but always passes @c FALSE to > * @a section_names_case_sensitive. > * > * @deprecated Provided for backward compatibility with 1.6 API. > */ > SVN_DEPRECATED > svn_error_t * > svn_config_read(svn_config_t **cfgp, > const char *file, > svn_boolean_t must_exist, > apr_pool_t *result_pool); > ]]] > > > which to me implies that the following is not allowed: > > > > [/public] > > * = r > > > > [/PuBliC] > > * = > > > > Whereas according to my reading of [3] that should be allowed. > > It's allowed, and works: > > % svnauthz accessof --path /foo =(printf '%s\n' '[/foo]' '*=r' > '[/FOO]' '*=' ) > r > % svnauthz accessof --path /FOO =(printf '%s\n' '[/foo]' '*=r' > '[/FOO]' '*=' ) > no > % > > In 1.6 it would be case insensitive. >
Re: Bug in docs regarding case-sensitivity?
On Sat, 14 Dec 2019 at 11:51, Daniel Shahaf wrote: > sebb wrote on Sat, 14 Dec 2019 09:20 +00:00: > > The code comment here [1] and the wiki [2] both state that section name > > matching is case-insensitive. > > > > However my reading of the document here [3] says this changed in version > 1.7. > > Thank you for taking the time to point out the specific text within that > page you had in mind, to save us all looking for it. (It's the first > "No Entry" box.) > > > These docs don't seem consistent to me. > > The two documents describe different layers. [1] and [2] describe the > configuration parsing module (svn_config_*), whereas [3] — says that > the implementation of authz (≤1.6) did case conversions before or after > calling svn_config_*(). > > However [2] says: "This means that, for example, you cannot have two different sections named [Section] and [section];" which to me implies that the following is not allowed: [/public] * = r [/PuBliC] * = Whereas according to my reading of [3] that should be allowed. > S. > > [1] > > > https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/config_file.c?view=markup#l1004 > > [2] > > > https://cwiki.apache.org/confluence/display/SVN/Configuration+File+Syntax > > [3] > > http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html >
Re: Missing access level value description
On Sat, 14 Dec 2019 at 11:41, Daniel Shahaf wrote: > [ moved to svnbook-dev@. Please remove users@ from replies. ] > > sebb wrote on Sat, 14 Dec 2019 09:23 +00:00: > > The document > > > > http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html > > > > says: > > > > "The value of each option describes the user's level of access to the > > repository path: either r (read-only) or rw (read/write)." > > > > However it's also possible to omit the value, which means no access. > > > > S. > > I think that's not a bug. Did I say it was? > You're quoting the introductory part of the > chapter, which is just that: an introduction, not a reference manual. > But it can be taken to mean that there are no other possible values. > The «foo =» syntax is described later on, in the section about > overriding permissions (look for the example with "/bug-142/secret"). > > What change would you suggest? > > "either r (read-only) or rw (read/write)." => "either r (read-only), rw (read/write) or omitted(no access)." Cheers, > > Daniel >
Re: What is the permissible character set for @group references in path-based auth?
On Sat, 14 Dec 2019 at 12:03, Daniel Shahaf wrote: > sebb wrote on Sat, 14 Dec 2019 09:12 +00:00: > > The only documentation I could find [1] defines a key using : > > > > ::= (any character except ) > > > > However the character domain is not specified as far as I can tell. > > I don't know where you're quoting that from. It's not on the linked > page or anywhere else that I can find. It's also patently false because > '=' and ' ' > can't be parts of a group name, because if they were then «@foo = rw» would > be misparsed. > > I should have been clearer. I did not mean that a key consists of text-char only. The key is defined in BNF in the Formal Definition section (once opened). Follow the BNF through, and one of refs is : key => key-cont => key-char => text-char (where => means refers to) i.e. the key definition uses text-char. So in order to know what is allowed in a key, one needs to know what a character is. > > [1] > https://cwiki.apache.org/confluence/display/SVN/Configuration+File+Syntax >
Missing access level value description
The document http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html says: "The value of each option describes the user's level of access to the repository path: either r (read-only) or rw (read/write)." However it's also possible to omit the value, which means no access. S.
Bug in docs regarding case-sensitivity?
The code comment here [1] and the wiki [2] both state that section name matching is case-insensitive. However my reading of the document here [3] says this changed in version 1.7. These docs don't seem consistent to me. S. [1] https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/config_file.c?view=markup#l1004 [2] https://cwiki.apache.org/confluence/display/SVN/Configuration+File+Syntax [3] http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
What is the permissible character set for @group references in path-based auth?
The only documentation I could find [1] defines a key using : ::= (any character except ) However the character domain is not specified as far as I can tell. [1] https://cwiki.apache.org/confluence/display/SVN/Configuration+File+Syntax
Inconsistent behaviour of info and status for missing/non-svn directory
I would expect status and info tp behave similarly for missing/non-svn directories. However info returns an error and status a warning. $ svn info /tmp/xxx/xxx;echo $? svn: E155007: '/tmp/xxx/xxx' is not a working copy 1 $ svn status /tmp/xxx/xxx;echo $? svn: warning: W155007: '/tmp/xxx/xxx' is not a working copy 0 Is this a known issue, or is it intended behaviour? S.
svnpubsub/client.py: RuntimeError: dictionary changed size during iteration
When running a version of watcher.py I got the following error: File ".../svnpubsub/client.py", line 251, in run_forever self._check_stale() File ".../svnpubsub/client.py", line 216, in _check_stale for client in asyncore.socket_map.values(): RuntimeError: dictionary changed size during iteration Is this a known issue? S.
Re: Bug in tools/server-side/svnpubsub/svnwcsub.py
On 25 May 2018 at 14:37, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > sebb wrote on Fri, 25 May 2018 14:14 +0100: >> The following fails because fname is not defined: >> >> self.read(fname) [1] >> >> it should be >> >> self.read(self.fname) > > Thanks for the report. OK. > With that change, the [DEFAULT] section doesn't get emptied by reload(). Seems to me that is a separate issue. > Would you like to send a patch that fixes that as well (in addition to the > NameError)? I've no idea how to patch that. I just know that my proposed fix stops the reload from failing. > Replies to dev@, please. Do you want me to raise a JIRA for the NameError? > Cheers, > > Daniel
Bug in tools/server-side/svnpubsub/svnwcsub.py
The following fails because fname is not defined: self.read(fname) [1] it should be self.read(self.fname) [1] http://svn.apache.org/viewvc/subversion/trunk/tools/server-side/svnpubsub/svnwcsub.py?view=markup#l378
SVN 1.9.7: issues with symlinks to subdir of working copy
I have a directory containing links to SVN directories that I want to update. In some cases the link is to the root of the workspace, and in some cases the link is to a subdir. $ mkdir TEST $ cd TEST $ svn co http://svn.apache.org/repos/asf/subversion/trunk subversion $ ln -s subversion top $ ln -s subversion/tools tools $ ls -l drwxr-xr-x 26 x x 884 12 Sep 14:48 subversion lrwxr-xr-x 1 x x 17 12 Sep 14:49 tools -> subversion/tools/ lrwxr-xr-x 1 x x 10 12 Sep 14:49 top -> subversion The following commands work fine: $ svn info ... $ svn log tools ... However for other commands there are some issues. $ svn status subversion top tools svn: warning: W155007: '/srv/TEST/tools/backup' is not a working copy $ svn -u status subversion top tools Status against revision: 1808117 ~ 1808117 top Status against revision: 1808117 svn: warning: W155007: '/srv/TEST' is not a working copy Note the strange path reference. $ svn update subversion top tools Updating 'subversion': At revision 1808117. Updating 'top': At revision 1808117. Skipped 'tools' Summary of updates: Updated 'subversion' to r1808117. Updated 'top' to r1808117. Summary of conflicts: Skipped paths: 1 Note: the output does not say why tools is skipped $ svn update tools Skipped 'tools' svn: E155007: None of the targets are working copies Whereas: $ cd tools /srv/TEST/tools $ svn update . Updating '.': At revision 1808117. These tests were done on $ svn --version svn, version 1.9.7 (r1800392) compiled Aug 10 2017, 21:32:31 on x86_64-apple-darwin16.3.0 Is this a known bug? I could not find anything in the database.
Re: Problems with selecting log revision by date: -r {yyyy-mm-dd}
On 3 December 2014 at 14:45, Johan Corveleyn jcor...@gmail.com wrote:
On Wed, Dec 3, 2014 at 2:45 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Stefan Sperling s...@elego.de writes:
On Wed, Dec 03, 2014 at 12:22:02PM +, sebb wrote:
svn co --depth files https://svn.apache.org/repos/asf/subversion/trunk
subversion
$ svn log -l 10 subversion
-- this works OK
$ svn log -r {2014-11-30} subversion
$ svn log -r {2014-11-30T00:00:00} subversion
Date search doesn't work on the ASF repository because svn:date properties
of revisions aren't monotonically increasing.
See the note at the very bottom of
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html#svn.tour.revs.dates
That's correct, but it is not the complete story. The date search does
return a revision even if that revision is not correct is some sense.
However the date search works on the whole repository
https://svn.apache.org/repos/asf
so the revision produced will often be one which didn't change
/subversion/trunk. That means that an empty log is shown just like
it is for this
svn log -r1643098 https://svn.apache.org/repos/asf/subversion/trunk
Even when a repository does have strictly mototonic dates using log with
a single date will often show a blank log on non-root paths within the
repository.
So perhaps the user should have specified a range, instead of just one date?
Like:
$ svn log -r {2014-11-30}:HEAD subversion
or:
$ svn log -r {2014-11-30}:{2014-11-31} subversion
Doh!
Thanks, that works.
--
Johan
Problems with selecting log revision by date: -r {yyyy-mm-dd}
I cannot get the examples in the manual to work.
They don't produce any output apart from the separator.
Is this a known bug?
How to reproduce:
svn co --depth files https://svn.apache.org/repos/asf/subversion/trunk
subversion
$ svn log -l 10 subversion
-- this works OK
$ svn log -r {2014-11-30} subversion
$ svn log -r {2014-11-30T00:00:00} subversion
This was tried on minotaur, using
svn, version 1.7.9 (r1462340)
compiled Jun 3 2013, 11:33:48
I have the same problems with the following version
svn, version 1.8.10 (r1615264)
compiled Aug 11 2014, 11:33:45 on x86_64-apple-darwin13.0.0
=
There's also a minor documentation error, the manual says:
If you want to include the 27th in your search, you can either specify
the 27th with the time ({2006-11-27 23:59}), or just specify the
next day ({2006-11-28}).
The phrase the next day should be the previous day or the day before
Re: Problems with selecting log revision by date: -r {yyyy-mm-dd}
On 3 December 2014 at 13:00, Stefan Sperling s...@elego.de wrote:
On Wed, Dec 03, 2014 at 12:22:02PM +, sebb wrote:
I cannot get the examples in the manual to work.
They don't produce any output apart from the separator.
Is this a known bug?
How to reproduce:
svn co --depth files https://svn.apache.org/repos/asf/subversion/trunk
subversion
$ svn log -l 10 subversion
-- this works OK
$ svn log -r {2014-11-30} subversion
$ svn log -r {2014-11-30T00:00:00} subversion
This was tried on minotaur, using
svn, version 1.7.9 (r1462340)
compiled Jun 3 2013, 11:33:48
I have the same problems with the following version
svn, version 1.8.10 (r1615264)
compiled Aug 11 2014, 11:33:45 on x86_64-apple-darwin13.0.0
=
There's also a minor documentation error, the manual says:
If you want to include the 27th in your search, you can either specify
the 27th with the time ({2006-11-27 23:59}), or just specify the
next day ({2006-11-28}).
The phrase the next day should be the previous day or the day before
Date search doesn't work on the ASF repository because svn:date properties
of revisions aren't monotonically increasing.
See the note at the very bottom of
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html#svn.tour.revs.dates
This says:
... If this ordering isn't maintained, you will likely find that
trying to use dates to specify revision ranges in your repository
doesn't always return the data you might have expected.
Although this may be strictly true, it's not immediately obvious that
nothing might be returned.
It would be helpful if the docs made it a lot clearer that date
selection may not work at all.
This should be stated at the start of the section, rather than a note
at the bottom.
Is the ASF repo unusual in not having monotonic dates? Or is this a
common occurrence (as I suspect)?
Further, it would help if SVN returned some indication that dates
cannot be used on the particular repository.
Though ideally of course it would be nice if the feature worked across
all SVN installations.
Re: Sequence of SVN commits cannot be replayed
On 24 March 2014 01:21, Daniel Shahaf d...@daniel.shahaf.name wrote: Daniel Shahaf wrote on Sun, Mar 23, 2014 at 02:34:35 +: sebb wrote on Sat, Mar 22, 2014 at 01:28:33 +: To reproduce the problem, start as follows: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4582 Then apply the following revisions in order: 4583 4586 4588 4592 4593 4599 I can't reproduce an error with latest svn-1.8.8 from ports on FreeBSD 9.1. I can reproduce Andreas' and Philip's results. I missed them on first scan because the OP specifically reported a conflict, so I only looked for conflicts. And I know 'svn up' reports conflicts, so I didn't run 'svn st'... I don't want to sound like I'm shifting the blame (and I'll readily admit that I was short on time when I did the checkout/update dance), but that's exactly why including output transcripts in bug reports is a good idea. Well, I got multiple conflict dialogs on both FreeBSD and WinXP when using svn up -r for some values of nnn I thought it would be the same for others. Daniel
Re: Sequence of SVN commits cannot be replayed
On 23 March 2014 11:18, Philip Martin philip.mar...@wandisco.com wrote: Daniel Shahaf d...@daniel.shahaf.name writes: sebb wrote on Sat, Mar 22, 2014 at 01:28:33 +: To reproduce the problem, start as follows: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4582 Then apply the following revisions in order: 4583 4586 4588 4592 4593 4599 I can't reproduce an error with latest svn-1.8.8 from ports on FreeBSD 9.1. I believe the problem is an svn:special file that contains a '\n' character: svn cat https://dist.apache.org/repos/dist/release/commons/dbcp/binaries/HEADER.html@4588 | od -c 000 l i n k . . / H E A D E R . h 020 t m l \r \n 026 I can reproduce on Linux: svnadmin create repo printf link foo\n x.x svnmucc -mm -U file://`pwd`/repo put x.x f propset svn:special '*' f Now svn co file://`pwd`/repo wc svn st wc M wc/f The reason is that create_special_file_from_stream() reads just the first line of the file to define the symlink while svn_wc__internal_file_modified_p() compares against the whole file. So what is the next stage in getting this inconsistency fixed ? Do I have to create a Bugzilla entry or will someone else take care of that? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Sequence of SVN commits cannot be replayed
On 22 March 2014 01:28, sebb seb...@gmail.com wrote: I think I have found a sequence of commits to SVN that cannot be replayed in a workspace. I was trying to change a file into a link, and made some mistakes in the process. These mistakes caused svnpubsub to leave the workspace incorrectly updated. [Svnpubsub uses svn switch to change the workspace.] I have since found that the same sequence of events cannot be replayed using svn update either, though the errors occur in a different way. To reproduce the problem, start as follows: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4582 Sorry, that has to be https, i.e. svn co https://dist.apache.org/repos/dist/release/commons/dbcp/@4582 Note that the original commits were made from a Windows OS. I have been unable to replay the sequence on either Windows or Unix without generating workspace conflicts. Then apply the following revisions in order: 4583 4586 4588 4592 4593 4599 This can be done with svn switch (as done by svnpubsub) or using svn update -r The resulting workspace should be the same as if one had invoked the following: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4599 But the process results in conflicts in the workspace. I assume this is due to the use of svn:special and the link feature. I would expect to be able to replay any sequence of updates so long as they are done in the correct order. But in this case some of the intermediate steps cause conflicts in the workspace. This was tested (on minotaur) with svn, version 1.7.9 (r1462340) See also INFRA-7429
Sequence of SVN commits cannot be replayed
I think I have found a sequence of commits to SVN that cannot be replayed in a workspace. I was trying to change a file into a link, and made some mistakes in the process. These mistakes caused svnpubsub to leave the workspace incorrectly updated. [Svnpubsub uses svn switch to change the workspace.] I have since found that the same sequence of events cannot be replayed using svn update either, though the errors occur in a different way. To reproduce the problem, start as follows: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4582 Then apply the following revisions in order: 4583 4586 4588 4592 4593 4599 This can be done with svn switch (as done by svnpubsub) or using svn update -r The resulting workspace should be the same as if one had invoked the following: svn co http://dist.apache.org/repos/dist/release/commons/dbcp/@4599 But the process results in conflicts in the workspace. I assume this is due to the use of svn:special and the link feature. I would expect to be able to replay any sequence of updates so long as they are done in the correct order. But in this case some of the intermediate steps cause conflicts in the workspace. This was tested (on minotaur) with svn, version 1.7.9 (r1462340) See also INFRA-7429
Re: Options for moving large files between repos
On 8 March 2012 13:54, Mark Phippard markp...@gmail.com wrote: On Mon, Feb 27, 2012 at 10:03 AM, sebb seb...@gmail.com wrote: I've currently got the CollabNet build (1.7.2) for Windows, and it does not include svnmucc as far as I can tell. As of the 1.7.4 release it will include it. Thanks! I've just reverted to the CollabNet build because I found that the WANdisco builds have a problem with redirected output. When the output of svn pl -v is redirected, the pathnames are printed together before the properties, making the output all but useless. I did not check if this bug affects other commands as well. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Options for moving large files between repos
On 26 February 2012 21:52, Stefan Sperling s...@elego.de wrote: On Sun, Feb 26, 2012 at 07:52:41PM +, sebb wrote: On 26 February 2012 16:05, Stefan Sperling s...@elego.de wrote: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svnmucc Is this available for all OSes? Yes. Things in tools/ are built by default with Subversion. Which package they end up in might depend on your OS, though. I've currently got the CollabNet build (1.7.2) for Windows, and it does not include svnmucc as far as I can tell. (Later) just downloaded 1.7.3 from CollabNet and Wandisco (for comparison) The CollabNet download is about twice the size, yet does not contain svnmucc. So I've abandoned the CollabNet build.
Options for moving large files between repos
The ASF is moving to using SVN for uploading releases [1] The process involves uploading the release artifacts (archives, sigs, hashes) to https://dist.apache.org/repos/dist/release/project There is a parallel development area at https://dist.apache.org/repos/dist/dev/project which can be used for release candidates (RC). The release manager (RM) can create RC files in the dev/ tree, and publish them by moving them to the release/ tree once the vote succeeds. Now release archives can be quite large, so one wants to minimise network transfers, and not have to checkout large workspaces either. One way which seems to work OK is to use a separate directory for each RC; this can then be renamed directly on the SVN server. Thus the RM only has to import the RC files once into the dev/ tree; all further copying is done on the server. However, many projects currently use a different layout for the release directory. A common layout is to use binaries/ source/ These directories may contain multiple concurrent release versions, and the existing release will anyway need to be retained for a few days during the release process to allow mirrors time to sync. In this case, there is no parent directory which can easily be renamed, so what are the options for minising network usage? One could rename each file individually on the server, but that would result in lots of separate commits, and would be tedious and error prone. Is there a way to rename multiple files as part of a single commit? Or some other method? [1] http://www.apache.org/dev/release.html#upload-ci
Re: Options for moving large files between repos
On 26 February 2012 16:05, Stefan Sperling s...@elego.de wrote: On Sun, Feb 26, 2012 at 03:51:44PM +, sebb wrote: Now release archives can be quite large, so one wants to minimise network transfers, and not have to checkout large workspaces either. Why would anyone need to get a working copy of anything? All moves/copies can be performed server-side. The RM can import the file into a directory, and others can download it. Because separate revisions (RCs) of the same release usually use unique filenames, there is currently no benefit in updating an existing working copy instead of downloading the release artefact. In this case, there is no parent directory which can easily be renamed, so what are the options for minising network usage? What network usage are you trying to minimise? RM to SVN server? Yes. Other developers to/from SVN server? No, they would have to download just once from the dev area. SVN server to release mirror servers? No. One could rename each file individually on the server, but that would result in lots of separate commits, and would be tedious and error prone. In this scenario, I have no better idea than renaming files individually. Is there a way to rename multiple files as part of a single commit? Yes, there is. See svnmucc: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svnmucc Is this available for all OSes? Is it documented anywhere? Whatever process is chosen needs to be easy to use for multiple RMs.
Restricting svn log --diff output to single file
The command svn log filename shows a list of revisions in which filename was changed. I would expect svn log --diff filename to only show the differences for that file. However, it shows the differences for all files changed in each revision. Is that really intentional? If so, how can I restrict the differences to just a single file? I am using: svn, version 1.7.2 (r1207936) compiled Nov 29 2011, 22:11:2 Try the following examples: $ svn log -l2 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/@848689 -qv r848689 | sussman | 2004-02-11 22:01:13 + (Wed, 11 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848664 | kfogel | 2004-02-09 22:51:34 + (Mon, 09 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS M /subversion/branches/1.0.x/packages/win32-innosetup/Pre.rtf M /subversion/branches/1.0.x/packages/win32-innosetup/Readme.txt M /subversion/branches/1.0.x/packages/win32-innosetup/W32notes.txt A /subversion/branches/1.0.x/packages/win32-innosetup/is_main.pas (from /subversion/trunk/packages/win32-innosetup/is_main.pas:848450) D /subversion/branches/1.0.x/packages/win32-innosetup/isx_main.pas M /subversion/branches/1.0.x/packages/win32-innosetup/svn.iss M /subversion/branches/1.0.x/packages/win32-innosetup/templates/paths_inno_src.iss M /subversion/branches/1.0.x/packages/win32-innosetup/tools/mk_distro.pl M /subversion/branches/1.0.x/packages/win32-innosetup/tools/mk_htmlhelp.bat M /subversion/branches/1.0.x/packages/win32-innosetup/tools/svnpath/main.c $ svn log -l2 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/@848689 --diff Index: STATUS === --- STATUS (revision 848688) +++ STATUS (revision 848689) snip/ Index: STATUS === --- STATUS (revision 848663) +++ STATUS (revision 848664) snip/ Index: packages/win32-innosetup/isx_main.pas (deleted) === Index: packages/win32-innosetup/Pre.rtf === --- packages/win32-innosetup/Pre.rtf(revision 848663) +++ packages/win32-innosetup/Pre.rtf(revision 848664) snip/
Re: Restricting svn log --diff output to single file
On 20 January 2012 15:36, Stephen Butler sbut...@elego.de wrote: On Jan 20, 2012, at 16:27 , sebb wrote: The command svn log filename shows a list of revisions in which filename was changed. I would expect svn log --diff filename to only show the differences for that file. However, it shows the differences for all files changed in each revision. Is that really intentional? If so, how can I restrict the differences to just a single file? I am using: svn, version 1.7.2 (r1207936) compiled Nov 29 2011, 22:11:2 Try the following examples: $ svn log -l2 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/@848689 -qv [...] $ svn log -l2 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/@848689 --diff Have you tried the full path to the file? The following works for me: $ svn log -l2 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/STATUS@848689 --diff Sorry, was trying lots of things and posted the wrong example, I did try with the file name: svn log -l14 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/STATUS@848689 -qv r848689 | sussman | 2004-02-11 22:01:13 + (Wed, 11 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848664 | kfogel | 2004-02-09 22:51:34 + (Mon, 09 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS M /subversion/branches/1.0.x/packages/win32-innosetup/Pre.rtf M /subversion/branches/1.0.x/packages/win32-innosetup/Readme.txt M /subversion/branches/1.0.x/packages/win32-innosetup/W32notes.txt A /subversion/branches/1.0.x/packages/win32-innosetup/is_main.pas (from /subversion/trunk/packages/win32-innosetup/is_main.pas:848450) D /subversion/branches/1.0.x/packages/win32-innosetup/isx_main.pas M /subversion/branches/1.0.x/packages/win32-innosetup/svn.iss M /subversion/branches/1.0.x/packages/win32-innosetup/templates/paths_inno_src.iss M /subversion/branches/1.0.x/packages/win32-innosetup/tools/mk_distro.pl M /subversion/branches/1.0.x/packages/win32-innosetup/tools/mk_htmlhelp.bat M /subversion/branches/1.0.x/packages/win32-innosetup/tools/svnpath/main.c r848663 | kfogel | 2004-02-09 22:41:36 + (Mon, 09 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848660 | sussman | 2004-02-09 17:15:44 + (Mon, 09 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848649 | dlr | 2004-02-06 19:41:36 + (Fri, 06 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848644 | dlr | 2004-02-06 07:22:41 + (Fri, 06 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848642 | blair | 2004-02-06 00:49:19 + (Fri, 06 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848641 | kfogel | 2004-02-05 22:53:41 + (Thu, 05 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848640 | sussman | 2004-02-05 22:07:00 + (Thu, 05 Feb 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848605 | kfogel | 2004-01-27 20:50:59 + (Tue, 27 Jan 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848604 | josander | 2004-01-27 20:29:18 + (Tue, 27 Jan 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848600 | kfogel | 2004-01-27 18:29:48 + (Tue, 27 Jan 2004) Changed paths: M /subversion/branches/1.0.x/STATUS r848598 | kfogel | 2004-01-27 17:08:24 + (Tue, 27 Jan 2004) Changed paths: D /subversion/branches/1.0-stabilization A /subversion/branches/1.0.x (from /subversion/branches/1.0-stabilization:848597) r848575 | kfogel | 2004-01-24 17:46:46 + (Sat, 24 Jan 2004) Changed paths: M /subversion/branches/1.0-stabilization/Makefile.in M /subversion/branches/1.0-stabilization/STATUS M /subversion/branches/1.0-stabilization/build/ac-macros/swig.m4 M /subversion/branches/1.0-stabilization/packages/rpm/mandrake-9.0/Makefile M /subversion/branches/1.0-stabilization/packages/rpm/mandrake-9.1/Makefile M /subversion/branches/1.0-stabilization/packages/rpm/mandrake-9.2/Makefile M /subversion
Re: Restricting svn log --diff output to single file
On 20 January 2012 16:07, Stefan Sperling s...@elego.de wrote: On Fri, Jan 20, 2012 at 03:54:37PM +, sebb wrote: Note that r848598 involves a directory copy. The diff command: $ svn log -l14 http://svn.apache.org/repos/asf/subversion/branches/1.0.x/STATUS@848689 --diff behaves properly up to that point, but then I get: r848598 | kfogel | 2004-01-27 17:08:24 + (Tue, 27 Jan 2004) | 1 line Rename branches/1.0-stabilization to branches/1.0.x, as Brane suggested. Index: 1.0-stabilization/Makefile.in === --- 1.0-stabilization/Makefile.in (revision 848574) +++ 1.0-stabilization/Makefile.in (revision 848575) snip other file diffs/ So it looks as though diff is broken when handling directory copies. This is a known problem. It has already been fixed in trunk, and the fix has been nominated for backport. It will likely be included in 1.7.3. OK, thanks. In case it helps anyone else in the meantime, I've managed to get round the bug by using svn log --diff --stop-on-copy url-path-to-file@version for each section of the files history (i.e. between copies) The relevant urls and versions can be found from: svn log -qv filename | grep (from which shows all the copy commands, for example: A /subversion/branches/1.0.x (from /subversion/branches/1.0-stabilization:848597) Unfortunately it also shows individual file copies which aren't relevant, but this can be worked round.
Re: Help! Subversion Exception!
On 18 October 2011 16:33, Daniel Shahaf d...@daniel.shahaf.name wrote: Les Mikesell wrote on Tue, Oct 18, 2011 at 10:18:24 -0500: I think there is a bigger question regarding why there are so many corrupt 1.6 workspaces around that nothing so far had noticed. Should people be concerned about that even if they aren't upgrading yet? How can you tell if a workspace is corrupt? (you mean working copy) Make a copy of it and upgrade that. Or, failing that, check all md5's in the working copy. But I expect the former option is far simpler for most people. By checking MD5, do you mean calculate and compare the hashes for the working copy and corresponding base files? If so, is that something that the upgrade process could (should) do before making any changes? That would also be useful as a stand-alone tool.
Re: Help! Subversion Exception!
On 18 October 2011 17:53, Philip Martin philip.mar...@wandisco.com wrote: sebb seb...@gmail.com 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. I've obviously misunderstood some of the postings then. I thought there were some reports (in other threads) of issues after the upgrade completed. -- Philip
Re: svn 1.7 assertion failed
On 17 October 2011 16:15, Les Mikesell lesmikes...@gmail.com wrote: 2011/10/17 Ulrich Eckhardt ulrich.eckha...@dominolaser.com: svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c' line 672: assertion failed (checksum != NULL) win7 64 Is there a way to recover? This has been reported ad nauseam. Please do as the message box tells you to, i.e. tell as much as possible about what you did and please first search the web before being the onehundredandtwentieth to report the same issue. In the hundredandtwenty responses recommending searches, I haven't seen any links to a definitive solution. Is there one that could be posted in answer to the next bazillion of these instead of telling them to search for something that may not exist? Perhaps someone should create a Wiki page with all the details; can then link to that in replies? -- Les Mikesell lesmikes...@gmail.com
Re: svn 1.7 assertion failed
On 17 October 2011 16:34, Daniel Shahaf d...@daniel.shahaf.name wrote: Do people who post here the error message with zero additional information expect support? Or do they just do what the error message says without considering whether users@ is a tech support forum or a Please send your crash reports here address? Not sure how this relates to my Wiki suggestion. If a developer creates a Wiki page with what to do and some common causes/fixes, that would be easy to use in a reply. Instead of explaining each time, it would only be necessary to quote the Wiki URL. One line. And the Wiki can easily be updated as more causes/fixes are discovered. Yes, it will take a few minutes to set up, but once available, any/all users of the list can reply to new posters very quickly. sebb wrote on Mon, Oct 17, 2011 at 16:18:56 +0100: On 17 October 2011 16:15, Les Mikesell lesmikes...@gmail.com wrote: 2011/10/17 Ulrich Eckhardt ulrich.eckha...@dominolaser.com: svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c' line 672: assertion failed (checksum != NULL) win7 64 Is there a way to recover? This has been reported ad nauseam. Please do as the message box tells you to, i.e. tell as much as possible about what you did and please first search the web before being the onehundredandtwentieth to report the same issue. In the hundredandtwenty responses recommending searches, I haven't seen any links to a definitive solution. Is there one that could be posted in answer to the next bazillion of these instead of telling them to search for something that may not exist? Perhaps someone should create a Wiki page with all the details; can then link to that in replies? -- Les Mikesell lesmikes...@gmail.com
copy tag shows repo revision, not tag revision - why?
When copying a tag (URL - URL), the log message shows the repo revision at the time of the copy, rather than the last commit revision of the tag. This occurs if no revision is specified, or if the revision is specified as HEAD. The only way to get the log message to show the last commit revision of the tag seems to be to specify it on the svn copy command; this is tedious and error-prone. Is there any simpler way to ensure that the log message shows the last committed version of the source tag? This is with svn client svn, version 1.6.16 (r1073529)
Session storage of credentials in JavaHL
Subclipse can use either JavaHL or SVNKit. When using Subclipse with SVNKit, users credentials are stored for the duration of the Eclipse session (assuming credentials are not permanently stored). However, Subclipse+JavaHL does not store the credentials at all - they have to be entered every time. This is quite annoying; it would be a lot easier if JavaHL behaved like SVNKit in this regard. Is this an enhancement that is already planned for JavaHL? If not, could it please be added to JavaHL?
svn client authentication agent
Is there a way to use an authentication agent to provide passwords to the svn client? It would be useful to be able to specify the password for multiple operations without having to store it on disk. For example, like GPG2 is able to do, and Putty with Pageant. The advantage is that the password is dropped as soon as the agent is stopped, whereas with disk storage it is considerably harder to remove the password. An alternative might be to allow passwords to be stored on removable media, but as far as I can tell it's not possible to store passwords separately from the rest of the configuration information. Thoughts?
