On Tue, Feb 27, 2018 at 4:09 PM, Myria <myriac...@gmail.com> wrote: > Not to mention that the two revisions complained about are unrelated, and > 2/3 the repository history apart. > > One thing that's interesting is that the commit the svnsync failed on is a > gigantic commit. It's 1.8 GB. Maybe that svnsync is failing because of a > Subversion bug with huge files...?
Hmm. Could 2 GB filesize limites be involved? When someone starts encountering this kind of issue with such large commits, it leads me to think "what the heck was in that commit"? There are various tools more likely to break when hammered that hard, wuch as pre-commit hooks written carelessly in Python that try to preload a hash with the contents of the file and just say "holy sone of a !@#$, I'm out of resources!!!". Been there, done that, had to explain the concept of reading a text file with a loop to the programmer in question. Also, I'd like to think outside the box at such a point and say "can that commit be skipped? is there anything in it that we actually need? can we just do an export/import to a new repo, discard the old repo's history, and get back to work?" And, what has been a useful tool to re-arrange and discard undesired branches and tags and history with, "can we do a git-svn export, flush history we don't need", and publish it back up to the new canonical Subversion repository"? I've use that approach now for several Subversion upgrades effectively, especially to allow some sanitization of the Subversion history. I know such history clean up is often discouraged, that the history is considered the critical component of the source control system, but there are many environments where legacy history is no longer needed. I wonder if this is one, and the questionable commit itself could be dumped. > I started an svnadmin verify on my incomplete local copy last night, and no > problems were reported when it finished this morning. I'll try again with > this -M option you mention. > > I'll also start an svnsync from a Linux machine. > > I'm going to see how hard it would be to just copy the 43 GB repository > directly. We'd have to shut down Subversion service during the copy, so it > might be a while before I have a chance to. Would you? If you can use a "rsync" based operation, such as mounting the share on the Linux system via CIFS and using "rsync", you should be able to verify that no operations occur during the filesystem based replication and re-run the "rsync" command when completed, to catch any dangling operations. If the Subversion server is busy, you might have to block "write" operations for a while to support consistent replication. With tools like CygWin, the files could also be rsynced and copied locally on the Windows box, then sent over to the Linux box. or an external USB used, or many other tools. >> >> >> >> -- >> Philip
