Java Doc for SVNMoveClient.java in  » Source-Control » tmatesoft-SVN » org » tmatesoft » svn » core » wc » Java Source Code / Java DocumentationJava Source Code and Java Documentation

• move versioned items to other versioned ones within the same Working Copy, what even allows to replace items scheduled for deletion, or those that are missing but are still under version control and have a node kind different from the node kind of the source (!);
• move versioned items belonging to one Working Copy to versioned items that belong to absolutely different Working Copy;
• move versioned items to unversioned ones;
• move unversioned items to versioned ones;
• move unversioned items to unversioned ones;
• revert any of the kinds of moving listed above;
• complete a copy/move operation for a file, that is if you have manually copied/moved a versioned file to an unversioned file in a Working copy, you can run a 'virtual' copy/move on these files to copy/move all the necessary administrative version control information.

If options is null, then this SVNMoveClient will be using a default run-time configuration driver which takes client-side settings from the default SVN's run-time configuration area but is not able to change those settings (read more on ISVNOptions and SVNWCUtil ).

If options is null, then this SVNMoveClient will be using a default run-time configuration driver which takes client-side settings from the default SVN's run-time configuration area but is not able to change those settings (read more on ISVNOptions and SVNWCUtil ).

If authManager is null, then this SVNMoveClient will be using a default authentication and network layers driver (see SVNWCUtil.createDefaultAuthenticationManager ) which uses server-side settings and auth storage from the default SVN's run-time configuration area (or system properties if that area is not found).
Parameters:
  authManager - an authentication and network layers driver
Parameters:
  options - a run-time configuration options driver

dst should not exist. Furher it's considered to be versioned if its parent directory is under version control, otherwise dst is considered to be unversioned.

If both src and dst are unversioned, then simply moves src to dst in the filesystem.

If src is versioned but dst is not, then exports src to dst in the filesystem and removes src from version control.

If dst is versioned but src is not, then moves src to dst (even if dst is scheduled for deletion).

If both src and dst are versioned and located within the same Working Copy, then moves src to dst (even if dst is scheduled for deletion), or tries to replace dst with src if the former is missing and has a node kind different from the node kind of the source. If src is scheduled for addition with history, dst will be set the same ancestor URL and revision from which the source was copied. If src and dst are located in different Working Copies, then this method copies src to dst, tries to put the latter under version control and finally removes src.
Parameters:
  src - a source path
Parameters:
  dst - a destination path
throws:
  SVNException - if one of the following is true:

• dst already exists
• src does not exist

In that case when you have your files copied/moved in the filesystem, you can not perform standard (version control) copying/moving - since the target already exists and the source may be already deleted. Use this method to overcome that restriction.
Parameters:
  src - a source file path (was copied/moved to dst)
Parameters:
  dst - a destination file path
Parameters:
  move - if true thencompletes moving src to dst,otherwise completes copying src to dst
throws:
  SVNException - if one of the following is true:

• move = true and srcstill exists
• dst does not exist
• dst is a directory
• src is a directory
• src is not under version control
• dst is already under version control
• if src is copied but not scheduled foraddition, and SVNKit is not able to locate the copieddirectory root for src

dst could exist in that case if it has been a WC directory that was scheduled for deletion during the previous move operation. Furher dst is considered to be versioned if its parent directory is under version control, otherwise dst is considered to be unversioned.

If both src and dst are unversioned, then simply moves src back to dst in the filesystem.

If src is versioned but dst is not, then unmoves src to dst in the filesystem and removes src from version control.

If dst is versioned but src is not, then first tries to make a revert on dst - if it has not been committed yet, it will be simply reverted. However in the case dst has been already removed from the repository, src will be copied back to dst and scheduled for addition. Then src is removed from the filesystem.

If both src and dst are versioned then the following situations are possible:

• If dst is still scheduled for deletion, then it is reverted back and src is scheduled for deletion.
• in the case if dst exists but is not scheduled for deletion, src is cleanly exported to dst and removed from version control.
• if dst and src are from different repositories (appear to be in different Working Copies), then src is copied to dst (with scheduling dst for addition, but not with history since copying is made in the filesystem only) and removed from version control.
• if both dst and src are in the same repository (appear to be located in the same Working Copy) and:
  • if src is scheduled for addition with history, then copies src to dst specifying the source ancestor's URL and revision (i.e. the ancestor of the source is the ancestor of the destination);
  • if src is already under version control, then copies src to dst specifying the source URL and revision as the ancestor (i.e. src itself is the ancestor of dst);
  • if src is just scheduled for addition (without history), then simply copies src to dst (only in the filesystem, without history) and schedules dst for addition;
  then src is removed from version control.