Open Issues

Open Issues

This document contains uncategorized heap of open issues and discussed issues.

On Jan 26th we discussed them with Garett Rooney.

Setup Issues

Firewalls

Users have problem to access svn repositories in firewalled environments because:
  • many HTTP proxies do not support WebDAV extensions
  • many svn repositories does not support https access
  • svn client does not directly support SOCKS proxies

Jan 26th Conclusion

HTTPS is preferred way. Garret will talk to tigris.org operations team to enable HTTPS for teh site. SOCKS are supported by Neon library. The support is not exported into Subversion options.

Non-interactive Certificate accept

How is the cmd-line client to be configured so that the certificate will be acepted by the server

$ svn up
Error validating server certificate for 'https://svn.collab.net:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svn.collab.net
 - Valid: from Sep 22 21:21:47 2003 GMT until Sep 21 21:21:47 2007 GMT
 - Issuer: CollabNet Chicago CA, Chicago, IL, US
 - Fingerprint: d9:2a:03:7d:82:b4:21:cb:97:6c:21:33:a8:13:1d:0f:ef:f2:21:39
(R)eject, accept (t)emporarily or accept (p)ermanently?  
svn up --non-interactive
svn: PROPFIND request failed on '/repos/svn/trunk'
svn: PROPFIND of '/repos/svn/trunk': Server certificate verification failed: issuer is not trusted (https://svn.collab.net)

Command line configuration

Is there any documentation for the cmd-line client configuration files (related to above issue) available?

Jan 26th Conclusion

It can not be achieved by CLI parsing. For demo it's OK as it can be workarounded by populating certifcate caches ahead using CLI in interactive mode.

The certificate cache uses a standard certificate format.

Proxy settings in config files

We have to write the user specified proxy settings into some servers config file. As long we don't want to change the SVN config files we will generate our own and give them over to the cmd line adapter.
  • are there some another (not proxy specific) options in the servers config file we shouldn't ignore (http_timeout,...) ?
  • if yes how should they be included into our config file?

Use Cases Analysis

Properties

Is there any information how intesively is the properties concept used by subversion users? Is it important to have already in the prototype some support for properties (adding, modifying, explicit change info for every property, ...) and if yes, then how deep should the prototype cover the issue?

What about hiding whether change is in file or in it's property?

Jan 26th Conclusion

System properties are a must. User defined properties are most commonly used by tools.

Locking

The same as with properties. Drop it in the first version?

Jan 26th Conclusion

It's not common. It was added later on to catch VSS users.

CVS and Subversion Cohabitation

For unversioned project there could appear both CVS -> Import and Subversion -> Import actions. But what should appear for project versioned under CVS? Should it contain Subversion -> Import? Probably not.

In all other contexts CVS and Subversion submenus visibility should be purely driven by isManaged(). Note in NB 5.0 CVS menu item appears even for unmanaged but with all actions disabled (with exception of project where is the Import).

Parsing svn output

Encoding

What's output encoding?
svn cat $FILE_NAME
svn propget $PROP_NAME $FILE_NAME
whatever command.

Jan 26th Conclusion

All content is binary (for text file it undergoes linefeeds conversion). File and property names are stored in UTF-8 but converted into local encoding. If not convertible it's fatal error.

Localization

Is there any localization?
On unixes export LANG=C?

Jan 26th Conclusion

Speculation. It can be addressed by parsing --xml output format.

svnClientAdapter Maturity

   Annotation: Can not status /home, guessing it...
        org.tigris.subversion.svnclientadapter.SVNClientException: Not implemented yet
        at org.tigris.subversion.svnclientadapter.AbstractClientAdapter.notImplementedYet(Unknown Source)
        at org.tigris.subversion.svnclientadapter.commandline.CmdLineClientAdapter.getStatus(Unknown Source)
[catch] at org.netbeans.modules.subversion.FileStatusCache.scanFolder(FileStatusCache.java:422)

Errors

Is the error output/"message" format for different errors consistent enough to create a (more) generic parsing algorithm?

Jan 26th Conclusion

Look at source code into lib_server. There is typical error - lock error - that can be fixed behing scane by cleanup command. Just be sure that no paralel task accessing same WC runs.

Cancelling a running task

What happens if a running task is cancelled on the client only?
It isn't something to be ignored, so what are we supposed to do for a kind of recovery (clean-up)?
Are there any "hints" (smells) that a clean-up should be started (automatically)?

Jan 26th Conclusion

Generally it OK. There used to be problems while cancelling long download using JavaHL APIs.

Progress information

Is there any progress information available while processing a task from the cmd-line?

Jan 26th Conclusion

It's not available on any (even protocol) level. In same cases such as update can be workarounded using status followed by actual update.

Release specials

Are there some specific issues/differences in the output between releases (1.2, 1.3,...) a parser should recognize?

Jan 26th Conclusion

Use 1.3 as lower boundary.

Generating auth cache files

How to generate appropriate credentials in the disk cache? (for successful authorized access into repository)
Are there some specific issues/differences in generating auth cache files between releases (1.2, 1.3, ...)
  • The auth/ caching area is permission-protected so that only the user (owner) can read data from it, not the world at large. The operating system's own file permissions are protecting the password.
  • On Windows 2000 and later, the Subversion client uses standard Windows cryptography services to encrypt the password on disk. Because the encryption key is managed by Windows and is tied to the user's own login credentials, only the user can decrypt the cached password. (Note: if the the user's Windows account password is changed, all of the cached passwords become undecipherable. The Subversion client will behave as if they don't exist, prompting for passwords when required.)

Project Features

About this Project

VersionControl was started in November 2009, is owned by tpavek, and has 102 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close