No announcement yet.

No log entries for new commits

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Windows and pipes... not always a good combination. Especially earlier Windows like XP. And, yes, the binary files end up encoded in the dumps so that would cause the beeps if you put it to stdout. Dumping to a file and then loading is fine - it just takes up a lot more space. But glad it worked.

    So, I've got to ask, that Windows XP system clock, is it still in 2014? Does the mobo need a new CR2032? And, just for reference, it's 2017: what's up with still using XP?


    • #17
      Well, it didn't really work because the rebuilt repository has the same log problems as before.

      I don't think the system clock has caused any incorrect dates. The 2014 dates were the dates of real past log entries that it is grabbing from somewhere. I kept making changes to one file (adding a blank line, committing, deleting the blank line, committing, etc.). After each commit the log showed either no entry (ie the number was skipped) or an actual past log entry from 2014 and later, always increasing chronologically, even though the repository I started with is a copy from 2013. They went all the way to October 2016, which was shortly before the ransomware attack.
      Examples (I've just picked out a few that can't identify what sort of software I work on):
      3910 2:11:10 PM, Monday 24 October 2016 Added option for user-defined display format
      3902 2:05:08 PM, Wednesday 16 July 2014 Updated copyright notice (year and address)
      3893 12:11:32 PM. Thursday 26 June 2014 Added command-line options to display/create directories

      Those log entries are real. They just didn't happen in the repository or working directory I'm working with, which is the repository as at 2013 with full checkout to a new working directory. These entries appeared in the log only after commits done last Friday. It is quite spooky that it is grabbing entries from a repository that no longer exists.

      If I try to edit one of those log messages the edit box shows the dummy message from the commit I just did, not the message shown in the log. And when I click OK I get "DAV request failed" and a list of possible reasons, such as a failed or missing "pre-revprop-change hook".
      Last edited by Nebula00; 03-21-2017, 01:17 AM.


      • #18
        FWIW, if you really want to change a log entry then you *do* have to have a pre-revprop-change hook to enable it. That's the only hook that must be in place to enable anything.

        Have you restarted the XP system since when you recovered the repository? Have you stopped and restarted the VisualSVN service? I have zero experience running a VisualSVN server - I wonder if perhaps this is an old bug that is haunting your XP system?! Perhaps the VisualSVN server has cached information about the missing revisions and is therefore very, very confused. I suspect you should consult directly with the VisualSVN folks about this issue. See how to clear their cache? One way to do this would be to completely uninstall VisualSVN, remove all directories and HIVE entries that concern it, then re-install it fresh. Obviously you cannot go down this path unless you have all required installation media and required licenses. Again, it might be simpler to communicate directly with the VisualSVN folks.


        • #19
          I don't think I can afford the additional time I'd need to get to the bottom of the problem, so I'm going to go to plan B, which is to start with a fresh repository, export all the files from the 2013 one and use them as the base files for the new one, then update the new one with the latest versions of anything that's changed. That will become the "working" repository on the server, but its history will begin from now. The 2013 one is still there as a read-only reference for pre-2013 history. Thanks for your help and suggestions over the past few weeks.


          • #20
            Just FYI, if you load into a new repo and then set its UUID (svnadmin setuuid) then it should behave properly assuming that the UUID was causing a bug to hit an uncleared cache. If you use this "new" repo with a different name then that should completely break the connection with any caching that might be in the VisualSVN product. Just a final thought...