This is with stock SVN version 1.9.6 (r1800392) as packaged in Debian GNU/Linux 'testing' distro, compiled Jul 22 2017, 06:41:45 on x86_64-pc-linux-gnu. (I dist-upgraded from the Debian package tree this morning, FWIW.)
I think I've encountered a data corruption bug due to a race condition somewhere in the working copy library. I don't have a reliable reproduction recipe, but here's what I did:
1) Start an SVN commit.
2) While the commit is in progress, edit and save a
change to one of the files that's being committed.
3) The commit completes successfully, or "successfully", but...
...now the repository has the file contents from before my edit of (2), the working copy has the file contents from *after* my edit of (2), but SVN reports no local modifications when I do 'svn status'. That's... bad, right? :-)
The transcript below, from after the above steps, gives more detail. What the transcript shows should be impossible:
$ svn up
Updating '.':
At revision 6916.
$ svn status -q
### no output, so no local mods that SVN is aware of ###
$ svn info org/main.org
Path: org/main.org
Name: main.org
Working Copy Root Path: /home/kfogel/private
URL: https://svn.red-bean.com/kfogel-private/trunk/org/main.org
Relative URL: ^/trunk/org/main.org
Repository Root: https://svn.red-bean.com/kfogel-private
Repository UUID: c51825e8-60e0-0310-a34c-dea7275b9f40
Revision: 6916
Node Kind: file
Schedule: normal
Last Changed Author: kfogel
Last Changed Rev: 6916
Last Changed Date: 2017-07-27 01:01:45 -0500 (Thu, 27 Jul 2017)
Text Last Updated: 2017-07-27 01:01:36 -0500 (Thu, 27 Jul 2017)
Checksum: ab3e79907b1107753ec961826fb22d9975bc6e4e
$ svn ls -v org/main.org
6916 kfogel 35258 Jul 27 01:01 main.org
$ svn cat -r6916 org/main.org > org/main.org-from-repository-r6916
$ sha1sum org/main.org
25d8f1383a453908782a1e550dad84b0bcafc0c9 org/main.org
$ sha1sum org/main.org-from-repository-r6916
ab3e79907b1107753ec961826fb22d9975bc6e4e org/main.org-from-repository-r6916
$ diff -u org/main.org org/main.org-from-repository-r6916
--- org/main.org 2017-07-27 01:01:36.259540030 -0500
+++ org/main.org-from-repository-r6916 2017-07-27 01:03:19.472775400 -0500
@@ -9,6 +9,7 @@
To: Karl Fogel <kfogel_at_opentechstrategies.com>
Date: Wed, 26 Jul 2017 20:29:40 -0400
Message-ID: <CAMUFnfbmGrDF+X1BKKA4HO4JFt3XBfb-jjd7LumDjrefgQ5QZA_at_mail.gmail.com>
+ - Erie Meyer email
- Baltimore Hotel fix
- Record United ORD<->LGA flight information
United Confirmation Number FGD887
$ svn --version
svn, version 1.9.6 (r1800392)
compiled Jul 22 2017, 06:41:45 on x86_64-pc-linux-gnu
Copyright (C) 2017 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme
The following authentication credential caches are available:
* Plaintext cache in /home/kfogel/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)
$ svn ci -m "Nothing to commit, because SVN mistakenly thinks there are no local mods."
### no commit happens ###
$ cd org
$ svn status main.org
$ mv main.org was-local-main.org
$ svn up
Updating '.':
Restored 'main.org'
At revision 6916.
$ diff -u main.org was-local-main.org
--- main.org 2017-07-27 01:19:02.779501081 -0500
+++ was-local-main.org 2017-07-27 01:01:36.259540030 -0500
@@ -9,7 +9,6 @@
To: Karl Fogel <kfogel_at_opentechstrategies.com>
Date: Wed, 26 Jul 2017 20:29:40 -0400
Message-ID: <CAMUFnfbmGrDF+X1BKKA4HO4JFt3XBfb-jjd7LumDjrefgQ5QZA_at_mail.gmail.com>
- - Erie Meyer email
- Baltimore Hotel fix
- Record United ORD<->LGA flight information
United Confirmation Number FGD887
$
Of course, it would be very difficult to reproduce this -- the file save probably has to happen at exactly the wrong moment during the commit. But maybe it's possible to find it just knowing that it's possible. In the meantime, I've saved a copy of the relevant top-level .svn/ directory and of the working copy subdirectory in which the bug occurred (from right before the "cd org" step above), in case those would help.
I'm not subscribed to dev@ these days, so please keep me CC'd on any followups.
Best regards,
-Karl
Received on 2017-07-27 08:22:03 CEST