Hello Stuart, It might be that Tortoise SVN interferes - some versions of it used to temporary block access to the files below .svn, so first thing to try is to disable TortoiseSVN background daemon process. Similar issues are known to be caused by antivirus software.
Could it be that your working copy resides on a network share? Or is it a normal local drive? Alexander Kitaev, TMate Software, http://subgit.com/ - Svn to Git Migration! http://svnkit.com/ - Java [Sub]Versioning Library! http://hg4j.com/ - Java Mercurial Library! http://sqljet.com/ - Java SQLite Library! On 26 June 2014 18:50, Stuart Rossiter <stuart.p.rossi...@gmail.com> wrote: > Hi, > > I've been using SVNKit to programmatically do some commits for a while > now (great library!). > > I'd previously been using v.1.7.8 against a SVN v1.6.16 server (part of a > Trac 0.12 installation) with no problems. I also used TortoiseSVN v1.7 (on > Windows) to manage the working copy. > > I recently upgraded to TortoiseSVN v1.8.7 and, because that's using the > 1.8 working copy format, upgraded SVNKit to v1.8.5. Now (*perhaps* > coincidentally) all my SVNKit commits are failing with E204899 errors > talking about being unable to rename internal SVN files in .svn\tmp > directories similar to the below: > > Cannot rename file 'RootDir\.svn\tmp\file.xml.tmp' to > 'RootDir\DirA\DirB\file.xml' > > (Where the rename target is an SVN-controlled file that has changed for > this commit.) > > My understanding is that SVNKit 1.8 should work fine with a 1.6 server. Is > TortoiseSVN possibly interfering in some way? > > If it's relevant, the file it is trying to rename to is one I > programmatically write to just before the commit; i.e., it's an > SVN-controlled file which I overwrite using standard Java I/O operations. > None of my code has changed from when it worked. > > Any ideas would be much appreciated. > > Stuart > > >
