Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2007-02-16 17:57:31
Size: 1368
Editor: 85
Comment:
Revision 5 as of 2007-02-16 18:32:19
Size: 3148
Editor: 85
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Here on this page we will publish different user qeustions and answers to them that a visitor may find interesting for himself.
Line 18: Line 20:
absolute and canonical path differs and there is no way to say file is a absolute and canonical path differs and there is no way to say whether a file is a
Line 29: Line 31:
{{{
Line 30: Line 33:
}}}
Line 36: Line 40:
{{{#!java
Line 37: Line 42:
}}}
----
'''
Q:
Can the current SVNKit version be forced to create pre-1.4 format working copies?
My problem is I need to support the older working copy format (pre svn 1.4.x)
and I assumed the new SVNKit automatically generates (and upgrades) working
copies to this latest format. I thought the most recent 1.0.x release would
do the trick.
'''
Line 38: Line 53:
A:
Yes, you can configure SVNKit to use the pre-1.4 WC format by putting
the following code somewhere in the startup function:

{{{#!java
    SVNAdminAreaFactory.setSelector(new ISVNAdminAreaFactorySelector() {
        public Collection getEnabledFactories(File path, Collection factories, boolean writeAccess) throws SVNException {
            Collection enabledFactories = new TreeSet();
            for (Iterator factoriesIter = factories.iterator(); factoriesIter.hasNext(); ) {
                SVNAdminAreaFactory factory = (SVNAdminAreaFactory)factoriesIter.next();
                if (factory.getSupportedVersion() == SVNAdminAreaFactory.WC_FORMAT_13)
                    enabledFactories.add(factory);
                }
             }
             return enabledFactories;
         }
    });
}}}
            
As you can see in this code snippet '''ISVNAdminAreaFactorySelector''' gives
you an ability to switch off the 1.4 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.

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.4 format working copies? My problem is I need to support the older working copy format (pre svn 1.4.x) and I assumed the new SVNKit automatically generates (and upgrades) working copies to this latest format. I thought the most recent 1.0.x release would do the trick.

A: Yes, you can configure SVNKit to use the pre-1.4 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 SVNException  {
   3             Collection enabledFactories = new TreeSet();
   4             for (Iterator factoriesIter = factories.iterator(); factoriesIter.hasNext(); ) {
   5                 SVNAdminAreaFactory factory = (SVNAdminAreaFactory)factoriesIter.next();
   6                 if (factory.getSupportedVersion() == SVNAdminAreaFactory.WC_FORMAT_13)
   7                     enabledFactories.add(factory);
   8                 }
   9              }
  10              return enabledFactories;
  11          }
  12     });

As you can see in this code snippet ISVNAdminAreaFactorySelector gives you an ability to switch off the 1.4 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.


SVNKit_FAQ (last edited 2012-01-03 18:09:05 by ip-109-80-120-205)