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_NAMEwhatever 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.)
