No announcement yet.

No log entries for new commits

  • Filter
  • Time
  • Show
Clear All
new posts

  • No log entries for new commits


    After losing a Subversion database from a ransomware attack I found a copy of it from 2013. I also have my working copy, which is up-to-date. So the best I can do is commit all the changes since 2013, with the history since then lost.

    However, after committing the changes there are no new log entries. The changes have been committed correctly (e,g, if I do a checkout, everything is current), but the most recent log entry is from 2013. The new commits have added revisions 3845 to 3872 to the revs and revprops directories in the database, I've run "svnadmin verify" on it and it runs to revision 3872 and finds no errors.
    Can anyone suggest what is wrong with the log?

    The database server is running VisualSVN Server Manager 2.5.8 on Windows XP.

    My local machine with the working copy is running this on Windows XP:
    TortoiseSVN 1.6.7, Build 18415 - 32 Bit , 2010/01/22 17:55:06
    Subversion 1.6.9,
    apr 1.3.8
    apr-utils 1.3.9
    neon 0.29.3
    OpenSSL 0.9.8k 25 Mar 2009
    zlib 1.2.3

    Thanks for any help.

  • #2
    I'm a little surprised that you could commit directly from the more advanced working copy into a "back in time" repo. I would have expected that the commit would complain.

    I would have copied out all of the files/directories, checked out a fresh working copy from the "back in time" repo, then copied the new stuff into the fresh working copy replacing the old stuff (and removing stuff that wasn't in the new copy but was in the fresh working copy (essentially a tree comparison), then add/checkin from there.

    If you dump revisions 3845-3872, what do the headers say for time stamps?


    • #3
      Sorry, I left out that detail. I did it exactly as you suggested - a full checkout from the 2013 database and then copied all the files changed since then into it (but not any .svn files), and then committed all the changed files.

      The mystery deepens. To simplify things I've started with the 2013 database again and done a full checkout. The first thing to note is that the last file number in revs and revprops is 3844, but if I ask Tortoise for a log at the base working directory the last entry is 3843. The timestamp in file 3843 in revprops (and 3844) is from 2013.

      Now, if I make a change to a file and commit it, it adds revision 3845 to the log (so 3844 is missing), but the entry displayed is not for the change I just made. From somewhere it has grabbed a revision from 2014 for different files and with a different comment to show in the log, but the new file 3845 in revprops has the comment I just typed and a timestamp of today. I can tell that the 2014 revision the log shows is real, but I don't know where it's coming from. If I do a recursive binary search of the database for strings in log comments up to revision 3843 it finds them, but a search does not find the comment the log shows for the new revision. I've also searched my working directories and can't find them. Each time I commit a change it adds another log entry from 2014 instead of the one I committed. They must be coming from somewhere, but they don't appear to be in the database.

      I think the first thing to fix is the inconsistency that's skipping log entry 3844. Is that possible?


      • #4
        Also, if I select Edit Log Message in the log for a revision today, the message in the edit window is what I entered today, yet in the log it shows the 2014 message.


        • #5
          1. Check the "hooks" directory for any live/active hooks.
          2. Go back to the original, unmodified repository copy and check to see what's in the "db\txn-protorevs" and "db\transactions" directories. Hint: they should be empty.

          What format is the repository in? Check the "format" and "db\format" files and report back.


          • #6
            1. In "hooks" there are nine .tmpl files, including a number for commits, plus "pre-revprop-change". (There's a database for another project there with only five; it's missing pre- post- lock ones. They may have been created at different times or with a different version.)

            2. There is no "db\txn-protorevs" directory. "db\transactions" is empty.

            There is no "db\format" directory. There is a "format" file in the database's root directory. It contains '3' and a line-feed.


            • #7
              What's in the "pre-revprop-change" hook? That script can change the date information!


              • #8
                The one with the .tmpl extension is:

                if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi

                echo "Changing revision properties other than svn:log is prohibited" >&2
                exit 1

                The one without an extension is:

                if [ "$PROPNAME" = "svn:log" ]; then exit 0; fi
                if [ "$PROPNAME" = "svn:date" ]; then exit 0; fi
                exit 1

                I'm sure the 2014 log entries it's taken out of the aether (I have no better explanation at present) and added to the 2013 database are real and the dates are correct. The messages for them include numbers of problem reports that were issued close to the dates on the entries. The dates/times also increase with each entry, so I can't help wondering where they will stop if I keep doing commits. Maybe the entire history of changes up to the ransomware attack is buried somewhere.

                One thing seems clear. Either Tortoise or the server is using different methods to display the log and edit a message selected from the log, since the messages in each are different from the same entry.
                Last edited by Nebula00; 03-09-2017, 10:19 PM.


                • #9
                  Ah, sorry - I thought that you meant that the "pre-revprop-change" hook was "live". If it's name is "pre-revprop-change.tmpl" then it can't be part of the problem.

                  You are running Windows XP. I have to start wondering if VisualSVN Server V 2.5.8 (from Dec 25, 2012) might have a problem with getting the proper date from the XP? You might want to update that to V2.7.14 - the last version to support Windows XP - it's at least 3 years more recent (Dec 16, 2015)...


                  • #10
                    I don't know what is meant by a "live" hook.

                    I'll think about getting the latest version of the server, assuming it's compatible with the existing databases. I'd rather not because I don't know what new problems I might get, but I might have to if I can't get this working. I remember having a lot of trouble getting it to work across the network and having to use HTTP for some reason.


                    • #11
                      In general, hooks don't fire unless they have the correct name. The reason for the ".tmpl" is to signify that they are templates and NOT going to run. Renaming them will cause them to fire - at least on Linux. On Windows they might need some additional glue - depends very much on your specific Windows installed environment. But with a ".tmpl" name it won't run so can't be a problem.
                      Additionally, the lack of a pre-revprop-change hook means that the dates can't be changed after they get captured by an update.


                      • #12
                        If I create a new, blank repository, can I add all the files and their histories in this troublesome repository to it? In other words, is there a utility that can rebuild the repository from scratch, one revision at a time? Maybe the rebuilt one would work properly. If this can be done, what is the process?


                        • #13
                          If you want to load up a new repository, the way to do this is via two built-in commands: "svnadmin dump" and "svnadmin load". Typically they are piped together after creating the empty/new repo:

                          [FONT=courier new]svnadmin create /path/to/new/repo
                          svnadmin dump /path/to/old/repo | svnadmin load /path/to/new/repo --force-uuid[/FONT]

                          The "--force-uuid" will mean that the new repository will have the same UUID as the old one. You should do this so that the working copies won't have to be thrown away. If you can suffer throwing away the working copies (a new checkout would be required), then don't use the option.


                          • #14
                            I first tried the "svnadmin dump" on its own to see what the dump looked like on stdout. There was plenty of text but also a lot of strange characters and the server's "bell" was ringing a lot. There are binary files in the repository, which I presume were responsible for that. When I do the pipe, will the binary files be faithfully reproduced in the new repository? (The command will be executed from a Windows XP command prompt.)


                            • #15
                              I tried it anyway, since I can always start again. There was some error that caused the pipe to be closed, so I did it in two operations with '>' to a file and '<'. The load went through to the last revision and seemed to work. Then I checked out all files from 'trunc' of the new repository, but the first commit of a change had the same problem. The log showed an entry from 2014 as before.