Am 21.10.2011 um 23:30 schrieb Lars Gullik Bjønnes: > Stephan Witt <st.w...@gmx.net> writes: > > | Am 21.10.2011 um 21:38 schrieb Lars Gullik Bjønnes: >> >>> Stephan Witt <st.w...@gmx.net> writes: >>> >>> | Am 21.10.2011 um 14:09 schrieb Pavel Sanda: >>>> >>>>> Buenas Noticias wrote: >>>>>> Ok. Subversion 1.7 is incompatible with LyX. >>>>> >>>>> maybe i was wrong and problem is not with lyx per se. >>>>> can you please try again with completely new repo (checkout from 1.7) >>>>> or upgrade as stated by Enrico? >>>> >>> | It's LyX having a problem. There is no local .svn meta-directory anymore. >>>> >>> | The attached patch is a possible solution. >>> >>> Hmm are you sure? At top level in the wc there should be some .svn >>> equivalent thing. >> > | Yes, this is true. But > | 1) it's not nice to traverse up IMHO > > You do not really have a choice... > You have to traverse up from where the file is. If not I do not see how > you can support svn 1.7. Would be same with git, you have to traverse > up.
Yes, in principle someone has to traverse up and look for the SVN meta-directory. I was talking about LyX doing the lookup in parent directories itself. > > | 2) the entries file contains only one single line (contents is not 42 but > 12) I wanted to say: you have to use much more complicated code to test for the presence of a given file in SVN than looking in the entries file. SVN now is using a SQLite database for that, AFAICS. So one should better using the subversion client to do the grunt work. The bonus is the backwards compatibility. This code is working with old and new checkouts. >> >>> But you have to reverse-traverse the dir structure to look for it, if it >>> is not in the current directory. >> > | Another much more tested patch is attached. > | Using "svn status -v" I could avoid the need to collect stderr (again). > > But this is just traversing up with indirection. :-) Of course. But I don't have to code it myself. The drawback of the new method is the fork of a child process for every lyx-file we open. A possible solution is a preference variable to enable/disable the VC-feature being enabled by default and the option to disable it (e.g. for every VC-backend separately). Stephan
