Main

Here on this page we will publish different user qeustions and answers to them that a visitor may find interesting for himself.

Q: I'm encountering performance issues refreshing a working copy accessed through a symbolic link.

For example I have a symbolic link named 'myProjects' in my home directory which links to /media/projects. When I use the command 'svn status myProjects/projectName' the operation is a lot slower than when I use 'svn status /media/projects/projectName'. Is this a known issue, can it be resolved?

A: Yes, this is a known problem. SVNKit supports versioned symbolic links and in order to resolve them uses expensive native program calls (ls). In case some of the working copy directory parents is a symbolic link, such calls are performed for every file in the working copy (because their absolute and canonical path differs and there is no way to say whether a file is a symbolic link or not, but calling ls command for it).

There are two workarounds for this problem:

1. Put your working copy or refer to it by it's "real" path, not by the one that includes symbolic link, that is what you already doing.

2. Disable versioned symbolic links support in SVNKit. To do that set the following System property:

-Dsvnkit.symlinks=false

(above is an option that you should add to the command line you're using to start your application)

at runtime you may call:

   1 SVNFileType.setSymlinkSupportEnabled(false);

Q: Can the current SVNKit version be forced to create pre-1.5 format working copies?

My problem is I need to support the older working copy format (pre svn 1.5.0) and I assumed the new SVNKit automatically generates (and upgrades) working copies to this latest format. I thought the most recent 1.2.x release would do the trick.

A: Yes, you can configure SVNKit to use the pre-1.5 WC format by putting the following code somewhere in the startup function:

   1     SVNAdminAreaFactory.setSelector(new ISVNAdminAreaFactorySelector() {
   2         public Collection getEnabledFactories(File path, Collection factories, boolean writeAccess) throws                
   3                                                                                            SVNException  {
   4             Collection enabledFactories = new TreeSet();
   5             for (Iterator factoriesIter = factories.iterator(); factoriesIter.hasNext(); ) {
   6                 SVNAdminAreaFactory factory = (SVNAdminAreaFactory)factoriesIter.next();
   7                 int version = factory.getSupportedVersion();
   8                 if (version == SVNAdminAreaFactory.WC_FORMAT_13 || version == SVNAdminAreaFactory.WC_FORMAT_14) {
   9                     enabledFactories.add(factory);
  10                 }
  11              }
  12              return enabledFactories;
  13          }
  14     });

As you can see in this code snippet ISVNAdminAreaFactorySelector gives you an ability to switch off the 1.5 fromat admin area factory.

There is also a system property svnkit.upgradeWC, when set to false it will disable upgrade of existing working copies to the new format, but it still will be used for new directories, so first option (providing custom interface implementation) is preferable.

Since 1.2.0 version SVNKit provides an ability to downgrade working copy format. The following code snippet shows a way to achieve that:

   1     SVNClientManager clientManager = SVNClientManager.newInstance();
   2     SVNWCClient wcClient = clientManager.getWCClient();
   3     File wc = new File("/path/to/working/copy");
   4     wcClient.doSetWCFormat(wc, SVNAdminAreaFactory.WC_FORMAT_14);

Q: I wonder if the methods of SVNRepository (like checkout() an update()) are atomic?

Is it possible (not probable) that another SVN client commit changes just while (not before or after) I am checking out or updating through these methods ?

A: SVNKit commit operations are atomic. That means that if you have two or more different clients committing (no matter whether they are all SVNKit clients or only one of them), they will be synchronized on the back end. In case of svn:// and http:// protocols commit finalizations are handled by the server itself (svnserve or mod_dav_svn), SVNKit client only sends necessary data and commands to the server, but the final step - writing to the repository - is undertaken by the server as you call ISVNEditor.closeEdit(). In case of the file:/// protocol SVNKit behaves like Subversion - it gets a write lock on a repository before making a transaction immutable the same way Subversion does it.

When updating via svn:// or http://: on the back end it is handled by the server itself, SVNKit receives data and commands to update, but what is happening on the back end, SVNKit doesn't matter (if something is wrong it's up to the server to deal with it). file:/// protocol update is implemented in a similar manner as in Subversion - it's a read operation and does not need any locks. Once it got the revision to update against it doesn't matter whether any commits are being performed: commits can create new repository files, but can not modify or delete existing ones, - you know each revision creates a new rev file in an FSFS repository. So your update will be absolutely consistent, although it doesn't mean that you will always get the latest revision when updating to HEAD revision - it may occur that after you started an update against a HEAD revision, someone started a new commit. But I believe it's true for Subversion, too.

So, the answer to your question is yes, it's possible and it's ok.

Q: In case of heavy editing through calls of the editor's methods it is possible, that another SVN client took a commit meanwhile?

I am concerned about the use of the SVNCommitEditor object: In case of heavy editing through calls of the editor's methods it is possible, that another SVN client took a commit meanwhile? Does this cause trouble for the editor itself? I think a final (and atomic) commit is done by the editor through the call of its .closeEdit() method, not during the editing, or isn't it? To which revision does this refer, the HEAD revision at initialization of the editor or the HEAD revision at the .closeEdit() call?

A: No, it doesn't cause any trouble for the editor itself. Until a call to ISVNEditor.closeEdit() is made each transaction lives in it's own directory on the back end. And even if someone committed a new revision after you started your transaction but before you finished it, when you call ISVNEditor.closeEdit() SVNKit (in file:///) tries to merge all changes committed ever since. And if it sees that someone has changed the same files it aborts, notifying a user with an exception. However if it succeeds to merge all changes committed since the transaction was started a new revision it results to will also contain all previous modifications. It means it "refers" to the real HEAD revision, which may be equal or greater than transaction start point revision. That is a new transaction will be absolutely consistent. In other protocols the picture is the same but this work is handled by the server itself.

Q: Is there any way to distinguish svn moves from svn copies using the low level API?

A: Yes, there is. Here is a short example demonstrating how to do that:

   1 public class Tests {
   2 
   3     public static void main(String[] args) {
   4         try {
   5             DAVRepositoryFactory.setup();
   6             SVNRepositoryFactoryImpl.setup();
   7             FSRepositoryFactory.setup();
   8             String url = args[0];
   9             SVNRepository repository = SVNRepositoryFactory.create(SVNURL.parseURIEncoded(url));
  10             
  11             repository.log(null, 0, -1, true, false, -1, false, null, new ISVNLogEntryHandler() {
  12 
  13                 public void handleLogEntry(SVNLogEntry logEntry) throws SVNException {
  14                     Map changedPaths = logEntry.getChangedPaths();
  15                     for (Iterator changedPathsIter = changedPaths.keySet().iterator(); changedPathsIter.hasNext();) {
  16                         String changedPath = (String) changedPathsIter.next();
  17                         SVNLogEntryPath logEntryPath = (SVNLogEntryPath) changedPaths.get(changedPath);
  18                         
  19                         if (logEntryPath.getType() == SVNLogEntryPath.TYPE_ADDED && logEntryPath.getCopyPath() != null) {
  20                             SVNLogEntryPath copySourcePath = (SVNLogEntryPath) changedPaths.get(logEntryPath.getCopyPath());
  21                             if (copySourcePath != null && copySourcePath.getType() == SVNLogEntryPath.TYPE_DELETED) {
  22                                 System.out.println("Path " + changedPath + " was moved from " + 
  23                                         logEntryPath.getCopyPath() + " in revision " + logEntry.getRevision());
  24                                 
  25                             }
  26                         }
  27                     }
  28                 }
  29             });
  30             
  31             System.exit(0);
  32         } catch (Exception e) {
  33             e.printStackTrace();
  34         }
  35     }
  36 }    

Q: Do you have an idea how to get the revision numbers and the corresponding dates of a file?

A: Here is a short example demonstrating how to do that with the low-level API:

   1 public class Tests {
   2 
   3     public static void main(String[] args) {
   4         try {
   5             DAVRepositoryFactory.setup();
   6             SVNRepositoryFactoryImpl.setup();
   7             FSRepositoryFactory.setup();
   8         
   9             String url = args[0];
  10             String filePathRelativeToURL = args[1];
  11             SVNRepository repository = SVNRepositoryFactory.create(SVNURL.parseURIEncoded(url));
  12             
  13             final Map fileRevisionsToDates = new HashMap();
  14             repository.getFileRevisions(filePathRelativeToURL, 0, -1, false, new ISVNFileRevisionHandler() {
  15                public void applyTextDelta(String path, String baseChecksum) throws SVNException {
  16                }
  17 
  18             
  19                public void closeRevision(String token) throws SVNException {
  20                }
  21 
  22                public void openRevision(SVNFileRevision fileRevision) throws SVNException {
  23                    fileRevisionsToDates.put(new Long(fileRevision.getRevision()), 
  24                            fileRevision.getRevisionProperties().getStringValue(SVNRevisionProperty.DATE));
  25                }
  26 
  27                public OutputStream textDeltaChunk(String path, SVNDiffWindow diffWindow) throws SVNException {
  28                    return null;
  29                }
  30 
  31                public void textDeltaEnd(String path) throws SVNException {
  32                }
  33             });
  34             
  35             for (Iterator revisionsIter = fileRevisionsToDates.keySet().iterator(); revisionsIter.hasNext();) {
  36                 Long revision = (Long) revisionsIter.next();
  37                 String dateStamp = (String) fileRevisionsToDates.get(revision);
  38                 System.out.println("file revision: " + revision + ", date stamp: " + dateStamp);
  39             }
  40             
  41             System.exit(0);
  42         } catch (Exception e) {
  43             e.printStackTrace();
  44         }
  45     }
  46 }    

Q: What is the difference between the two "standalone" downloads - one_with_jna and one_with_no_jna?

A: SVNKit uses JNA library to optionally perform certain low-level file system operations using native OS calls. In particular, JNA is used to improve performance of operations related to symbolic links. Also, it enables credentials encryption on Windows (to store and read encrypted cached credentials to and from SVN_CONFIG/auth/ files).

The reason we provide a distribution without JNA library included is that JNA library is LGPL licensed and some of the users would like to have an ability to download SVNKit with no LGPL components included.

Q: What is Trilead library for?

A: Trilead library is used to establish SSH connections, i.e. to support working with repository over svn+ssh protocol.