Hi, Erik, > Von: Erik Huelsmann [mailto:ehu...@gmail.com] > > Hi Markus, > > On Fri, May 13, 2011 at 11:20 AM, Markus Schaber <m.schaber@3s- > software.com> wrote: > > Hi, > > > > What is the safest future-compatible way to check for an incompatible > > / unknown working copy format which was written by a future subversion > > version? (e. G. WC-NG by SVN 1.7?) > > > > My idea was to run status with depth=empty on the workingcopy root, > > and check for SVN_ERR_WC_UNSUPPORTED_FORMAT error code. > > > > Is there a function specifically designed for this purpose? > > No. The current library functions are forward compatible for the entire > 1.x range. The working copy storage is considered to be an internal > artifact, meaning you're supposed to use the libraries (e.g. > through the python bindings) to access the working copy data.
Yes, I intend to use the libraries (rsp. the subset exposed by the SharpSNV wrapper) for everything. That's why I'm looking for an API call to gather that information. > Why do you want to know if a working copy changed its storage type? When the user opens a CoDeSys project which was created or modified by a newer (future) CoDeSys version, that project may have an embedded working copy which was created (or upgraded to) a newer format. When detecting this, I want to inform the user that the working copy has a future, incompatible format. That means he either has to use a newer version of our software (which knows how to handle that working copy as it includes the newer client version), or he has to disconnect the project from subversion (which turns it into an unversioned project by dropping the working copy). One possibility is to create some versioning scheme and save it into the project meta data, the other possibility is to let Subversion itself detect whether it can handle the working copy. (I blindly assume that Subversion 1.6.16 is not able to downgrade an existing workingcopy from future, incompatible formats back to 1.6 :-). Regards, Markus
