Sorry for resurrecting this but just wanted to let you know that it appears the doMove isn't quite backwards compatible with 1.6. By your description of what you changed, it looks like it might be an issue with doCopy as well, but I haven't tested.
Using a 1.6 working copy and svnkit org.tmatesoft.svnkit:svnkit:1.7.4-v1 (maven central): 1. wc.doAdd a new folder inside working copy 2. mc.doMove an existing svn folder into that newly added folder (before any commit) An exception is created, sorry I didn't save it but I think it couldn't find the folder I just added. Same code runs fine on a 1.7 wc. Switched my dependency back to 1.3.5 and the same code executes successfully on the 1.6 wc. Sorry for being so vague, this isn't really a big deal for me, but just wanted to give you guys an FYI. Let me know if you want me to come up with a more specific test case. AlexanderKitaev wrote: > > Hello Mark, > > SVNMoveClient was introduced in the 1.3.x version line in order to > workaround some limitations of the standard move. So there are (and > were) two ways to perform move - first is with the > SVNCopyClient.doCopy - this is a standard way which works exactly the > same way as the native client, and second is with SVNMoveClient.doMove > - it lets one move unversioned files as well, or to move files between > working copies. > > In version 1.7 of SVNKit, standard move (with doCopy) fixes most of > the limitations of the old one, so standard doCopy works well. This is > why SVNMoveClient,doMove was left as it is and it only worked with the > old working copies, treating files in the new working copies as > unversioned. > > I've just changed it in trunk, so now when new working copy format is > detected, then doMove just calls doCopy, otherwise it executes old > doMove. > > Thanks! > > 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 6 April 2012 19:10, Mark Herman <[email protected]> wrote: >>> Please consider using SVNCopyClient.doCopy(...) method with "isMove" >>>parameter set to "true". >> >> Thanks for the quick response, doCopy with isMove works correctly for me. >> Here is the code that doesn't work: >> >> SVNClientManager cm = ...; >> cm.getUpdateClient().doCheckout(url, co, SVNRevision.UNDEFINED, >> SVNRevision.HEAD, SVNDepth.UNKNOWN, true); >> cm.getMoveClient().doMove(orig, newFile); >> >> Here is what worked for me: >> >> SVNClientManager cm = ...; >> cm.getUpdateClient().doCheckout(url, co, SVNRevision.UNDEFINED, >> SVNRevision.HEAD, SVNDepth.UNKNOWN, true); >> SVNCopySource[] sc = {new SVNCopySource(SVNRevision.HEAD, >> SVNRevision.HEAD, orig)}; >> cm.getCopyClient().doCopy(sc,newFile,true,true,true ); >> >> So is the copy client the new move client? > > > -- View this message in context: http://old.nabble.com/RC-5-Move-still-broken-tp33643515p33983804.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
