Am 05.03.2012 um 14:34 schrieb Pavel Sanda:
> Stephan Witt wrote:
>>> Stephan, do you still have some time to look on this? I mean
>>> a) some routine to check existence of parental .svn for 1.7 SVN
>>> b) in case a) succeeds external svn call to check file being under SVN
>>> control
>>> (a&b perhaps just as fallback to current current check routines)
>>> c) perhaps RC_ for this business (enabled by default and not in UI, but as
>>> a emergency help)?
>>>
>>> In case a) is written in general way (bool checkparentdirs(".svn"))
>>> the doors for basic git support in LyX are opened (I guess one weekend
>>> coding & debugging).
>>
>> Yes, I have some time to look on this.
>>
>> Would a possible solution to make the builtin check for SVN (in local
>> directory) first,
>> if that fails to check the version of the svn client with "svn --version
>> --quiet" and
>> a) cache the result and if svn 1.7 or better is found
>
> What is the gain of a) instead of directly calling b)?
We don't ask for svn client version again and again. If it is 1.6.x we're done
with it.
>> b) use the external svn call to check the status of the files?
>
> It would work but it implies external svn call(s) for each opened files no
> matter whether the file
> is under the control :-/ I'm not much happy, but you are the boss now...
I don't like hard-coding the knowledge how subversion developers organize their
meta-data.
The overhead of forking a process and loading the shared code for the svn
client is not too high, IMHO.
The traversal to the root of the file system is done by the svn client too.
And if there is some .svn directory upstairs we have to fork anyway.
Alternatively we may code and link against the subversion library... (as Georg?
suggested).
To avoid superfluous lookups it would be better to configure the list of VCS to
check for.
Stephan
