Hello John! Sorry for confusing you - I just posted the links I had already looked upon, to save your time.
> The first link proposes that a file to be committed changed between the > time the commit process started and when the file was really > transmitted. As this is a live file system, and 13 hours of waiting, > this is highly possible with at least one file. Not sure how to get > around that. It will take hours to verify this case. Well, that's with a file *already existing* in the repository. You're talking about the first time import, right? > The second link looks unrelated. Ok. > The third link looks like a file moved between the commit start and end, > but they say it was a APR library miss match, which is not possible in > my case (both subversion and apache compiled at the same time against > the same APR libraries). Ok. That was just a guess. > It would be nice if the fsvs error could report the file or directory > that failed, so I could add it to my ignore list. The last file listed > during the import list on my system most definitely did not change, as > it is one of my apps object files and I didn't change it. The error was given for close_edit() - which is *after* all the file changes. In fact, this is the last call before the transaction is completed. If you're using FSFS and a filesystem which allows no files > 2GB, the commit might be aborted because the single revision gets very big. Or, another problem might be that you're using an ext2 or ext3 without dir-index for the repository paths ... fsfs creates 2 files for each entry in a single directory: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends You could also take a look at that thread: http://thread.gmane.org/gmane.comp.sysutils.backup.fsvs.general/138 > As a work around, I have rsynced the target system's / to my repository > server's hard drive. I ignored the /proc and /sys directories. I'm now > starting the import from the svn server to the svn server. This will > prevent anything from changing in the image during the import, and might > take less time. This should be no problem for fsvs - I took care of this problem. Some other ideas for you: 1) Use the "-d" debugging switch, perhaps with a "tail -5000 > logfile". That should give much more information. 2) Try to commit parts, ie. "fsvs ci usr/share", "fsvs ci usr/doc", "fsvs ci usr", etc. That should be much faster, and the revision files are smaller. HTH! Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
