Re: New Benchmark Tool for LyX & Results.

[John McCabe-Dansted]

On Thu, Jul 14, 2011 at 6:27 AM, Tommaso Cucinotta  wrote:
> Il 13/07/2011 20:32, John McCabe-Dansted ha scritto:
> one trivial questions (sorry to ask):
> 1) are you sure power management was disabled on your machine while running
> these benchmarks ?

Powermanagement was probably ondemand. The results are repeatable
however, and the jumps in time are usually accompanied by jumps in
memory usage, which shouldn't be affected by power management.

> 2) are you sure the compile-flags with which the various revisions were
> compiled are all the same ?

Apparently not; the reason that r38562 was faster was presumably
because it was so close to 2.0.0 that configure defaults to "release".
That explains that result. However, it didn't affect memory much,
which was the major jump in this benchmark. Since my snapshots are
primarily used for bisecting bugs, I haven't manually disabled the
debug options, creating a separate set of snapshots for benchmarks
would clearly be ideal.

r38163 has similar configure options to earlier versions. Debugging is
enabled, which means that the severity of the performance regressions
may or may not apply to release versions. Most of the debug options
shouldn't affect memory use much though I guess some do a little; but
not enough to explain the doubling of memory use.

$ grep d.with 38024/config.log | head -n1
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
xp@xp-desktop:/mnt/big/keytest/lyx.cache$ grep d.with 38163/config.log
| head -n1
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

> 3) do you get anything different if you launch lyx with something like "chrt
> -f 1 lyx " ? Just to rule out some random process that interfered
> with the program maybe activated by cron or similar (ok, we still have xorg
> and Qt/Kde that will interfere, however better than going CFS :-) ).

I was looking primarily at the "user" time, which shouldn't be
affected by this much. The elapsed time isn't going to be all about
LyX anyway. Since keypresses get dropped if we send them too fast, my
benchmark sends them at most once every 100ms, and even then, only if
LyX is sleeping.

...

Anyway: I have reproduced the increase in memory use with =rel as
well. It appears to be caused by the additions to
lib/layouttranslations. Does LyX make an in memory copy of the
translations for every inset? LyX appears to be using a lot of memory,
almost 100k per note inset. We could easily fit one copy of
lib/layouttranslations per LyX-note into that amount of memory.

Total number of lines, insets: 8192,
38163:
5.13user 0.47system 0:15.18elapsed 36%CPU (0avgtext+0avgdata 790768maxresident)k
Size of layouttranslations 40k
Memory use / note inset: 96k

38162:
3.90user 0.32system 0:14.88elapsed 28%CPU (0avgtext+0avgdata 382272maxresident)k
Size of  layouttranslations: 28k
Memory use / note inset: 46k

-- 
John C. McCabe-Dansted

Re: Towards RC4/final release

[Uwe Stöhr]

>> Jürgen Spitzmüller wrote:
>>> Pavel Sanda wrote:
>>> is anybody knowing what is this customHeaderFooter module for and how it
>>> should be used? - cf #7196
>>
>> It's an attempt at providing a GUI to customize fancyhdr's header and footer
>> content, something that should not have been implemented ad-hoc via a module,
>> but rather properly in the document settings, IMHO.
>
> should we kill it then?

I added this module after a discussion. We came to the conclusion that a module is perhaps not the 
best UI but simple and intuitive for the users. I therefore created it and also to use it for our 
new thesis template.
I saw today Helges documentation for it. I will review it and add it to the docs (if possible as 
addition to the UserGuide).


regards Uwe

Re: Springer layout files

[Uwe Stöhr]

Am 11.07.2011 23:35, schrieb Marcus Kriele:


I have tested the new layouts and templates for svmono, svjour3, and svmult. In 
these new versions,
the proof, solution and problem environments work for me. However, I would 
change the label of the
sol environment: Currently it is an automatically generated counter that may 
have nothing to do with
the counter of the corresponding problem. I find this misleading.


To what should I change it, a string plus the counter? If yes, what string?


In addition, if the solutions are
written in the same order as the problems then in LyX it appears that each 
solution references the
correct problem. However, the output gives question marks as the references are 
not given
explicitly.


I don't get them with the template files. How can I get them?


I would prefer a label like "sol [label of problem]". While this looks very 
different
from the output, it would reduce the likelihood of user error.


So you mean I should change the name of the style (the one in LyX's style-combobox). If so, I'll do 
this as you suggested. But this is independent of the label you see in your text when using Sol. How 
should I change it. To avoid confusions, it is perhaps better if you send me a patch how you would 
like to have it and I put it in. OK?



I also have a few additional comments:

svmono:

1) Minor -- Master document has not been set. I propose to do so for each 
include file

How can I do this?


For each document that is to be included: Documents -> Settings... -> Document 
Class, check "Select
default master document", browse for the master document. This may result in an 
absolute path, but
you can edit this path to make it relative. (I only tested this on mac).


Thanks, I have done this now.
(Btw. It is really time that I start documenting all the new LyX 2.0 features if even I don't know 
them all.)



4) Medium -- chapter.lyx: References to LaTeX should be replaced by references 
to LyX, e.g,
"Furtheron please use the LaTeX automatism for all your cross-references and 
citations." There are
several instances of such references.


The references to LaTeX are still present.


I changed it now to "LyX" as you suggested.

I will have a look for the other issues tomorrow.

thanks and regards
Uwe


9) Medium -- foreword.lyx: Optional argument has not been explained

I don't understand this option. If I need another heading, I can directly 
change it, why do I need
an optional heading for this?

The user would need to use the extrachap command which might not be obvious to 
her/him. Perhaps one
could document the usage in a comment note? Same for preface.



svjour3:

There are two citations to non-existing bibliography entries, "Abernethy2003" and 
"Pellacini:2005:LAH"

svmult:

1) title*

In svmult_author.lyx the title* style does not work. Both as an embedded 
document and as a
stand-alone document you simply get "*" as the title and the given title 
("Contribution Title") is
ignored. I couldn't get this style to work either.

The intended behavior is to produce the title in the output without the line 
"chapter 1". It does
work with their latex templates.

If you do not have an idea how to do implement title*, I would propose to 
delete our title* style
and to write a note that we do not support it. After all, the whole problem is 
appears to be caused
by Springer hacking the LaTeX title and chapter commands in a way that is not 
compatible with the
idea of a mark-up language.

(Something minor: title is in the "Section" category while "Title*" is in the 
FrontMatter category.
While this does reflect the purpose of title and title *, it would probably be 
better to present
these styles side by side. )

2) Author

The format in LyX is indistinguishable from the standard format or at least 
very similar. I propose
to add an italic label "Author: " similar to the style "Institute".

Other bugs:

I think that the relative path to the pictures "../../examples/CV-image.png" 
should read
"../examples/CV-image.png". If this is the case then this bug was originally 
introduced by me. My
apologies. This applies to svmono_chapter.lyx (twice), svmono_appendix.lyx, 
svjour3.lyx (twice),
svmult_author.lyx (twice), svmult_appendix.lyx

Regards, Marcus

Re: New layouttranslation strings

[Pavel Sanda]

Uwe Stöhr wrote:
> Am 13.07.2011 03:12, schrieb Pavel Sanda:
>
>> it seems you recently add new layout strings to be translated in latex 
>> output,
>> in particular "Prop", "Property", "Solution".
>
> I don't understand. I added new styles for the Springer layouts. Their 
> names should automaticaklly appear in the po-files after a remerge.
>
>> its also strange that we want to translate introduced "Prop" while
>> letting new environment "Sol" untranslated.
>
> What do you mean? "Sol" is a style in svcommons.inc as "Prop". What is the 
> difference?
>
> I have not touched the file "layouttranslations".

well, not directly. if you change strings they are going to appear in .po
files sooner or later. if you change/add some environments which are
translatable in .tex output, they'll soon appear in layouttranslation
when anyone "remerges" this file.

to repeat my question: we translate "Prop" and not "Sol". this can 
be seen when layouttranslation file is remerged. should they be both translated?
or none of them?

i guess you missed the discussion about new translation mechanism
of lyx while being in SA. README.localization, PART II should
be read to have at least some user-perspective.

pavel

Re: New layouttranslation strings

[Uwe Stöhr]

Am 13.07.2011 03:12, schrieb Pavel Sanda:


it seems you recently add new layout strings to be translated in latex output,
in particular "Prop", "Property", "Solution".


I don't understand. I added new styles for the Springer layouts. Their names should automaticaklly 
appear in the po-files after a remerge.



its also strange that we want to translate introduced "Prop" while
letting new environment "Sol" untranslated.


What do you mean? "Sol" is a style in svcommons.inc as "Prop". What is the 
difference?

I have not touched the file "layouttranslations".

regards Uwe

Re: New Benchmark Tool for LyX & Results.

[Richard Heck]

On 07/13/2011 06:27 PM, Tommaso Cucinotta wrote:
> Il 13/07/2011 20:32, John McCabe-Dansted ha scritto:
>> I have begun developing benchmark utilities for LyX. These can be
>> found by doing
>>git clone g...@github.com:gmatht/Jankey.git
>>cd Jankey/Benchmarks/
>>
>> Running these benchmarks reports that that the resource usage of LyX
>> has been growing in a number of discrete jumps, the most significant
>> of these is r38163; increasing running time by about %15 and doubling
>> memory usage. This seems wrong to me; all r38163 is meant to do is
>> print some untranslated entries. I haven't been able to reproduce this
>> manually, but I get this result consistently with the benchmark tool.
>
> one trivial questions (sorry to ask):
> 1) are you sure power management was disabled on your machine while
> running these benchmarks ?
> 2) are you sure the compile-flags with which the various revisions
> were compiled are all the same ?
> 3) do you get anything different if you launch lyx with something like
> "chrt -f 1 lyx " ? Just to rule out some random process that
> interfered with the program maybe activated by cron or similar (ok, we
> still have xorg and Qt/Kde that will interfere, however better than
> going CFS :-) ).
>
The biggest thing I'd check here is that debugging stuff is disabled,
i.e., that we are compiling --enable-build-type=rel. The string checks
that stdlib-debug does take forever.

Richard

website typo

[Tommaso Cucinotta]

On the announcement of the lyx 2.0.0 release (http://www.lyx.org/News), 
we have this typo


  "and the LyX wiki , which you You can also send 
email to the LyX users' list (lyx-users at lists.lyx.org)."



Perhaps it could be fixed.

Bye,

T.

Re: New Benchmark Tool for LyX & Results.

[Tommaso Cucinotta]

Il 13/07/2011 20:32, John McCabe-Dansted ha scritto:

I have begun developing benchmark utilities for LyX. These can be found by doing
   git clone g...@github.com:gmatht/Jankey.git
   cd Jankey/Benchmarks/

Running these benchmarks reports that that the resource usage of LyX
has been growing in a number of discrete jumps, the most significant
of these is r38163; increasing running time by about %15 and doubling
memory usage. This seems wrong to me; all r38163 is meant to do is
print some untranslated entries. I haven't been able to reproduce this
manually, but I get this result consistently with the benchmark tool.


one trivial questions (sorry to ask):
1) are you sure power management was disabled on your machine while 
running these benchmarks ?
2) are you sure the compile-flags with which the various revisions were 
compiled are all the same ?
3) do you get anything different if you launch lyx with something like 
"chrt -f 1 lyx " ? Just to rule out some random process that 
interfered with the program maybe activated by cron or similar (ok, we 
still have xorg and Qt/Kde that will interfere, however better than 
going CFS :-) ).


Thx,

   T.

Importing \usepackage{algorithmic}

[Tommaso Cucinotta]

Hi all,

today I just noticed a colleague of mine trying to import in LyX a 
simple latex document he started to write in plain latex, and the only 
thing that was imported as ERT was some usage of the algorithmic 
package, which apparently was being used for the same purpose as 
LyX-Code would fit (or anyway preformatted code).


Is this considered normal/good behavior of the program, or is there any 
direction for improving such an (easy) import ?

(I'm asking as I don't know what actually can be done with such a package).

Thanks,

T.

New Benchmark Tool for LyX & Results.

[John McCabe-Dansted]

I have begun developing benchmark utilities for LyX. These can be found by doing
  git clone g...@github.com:gmatht/Jankey.git
  cd Jankey/Benchmarks/

The Benchmark  basically involves spamming the following keycodes at LyX
  \Ac \D1 \Ac \D9 \D9 \Ao \D1\Av\D10 \Ai n n nnn \[Right] asdf \r \r
iadsf \Ao \Ca \D9 \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc
\Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv
\Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Ca \Cc \Cv
\Cv \Ca \Cc \Cv \Cv \Cc MEMINFO \Cq \Cs \Ad \Ad

This causes LyX to create line of text with a LyX Note, and then make
8192 copies the line. Replacing these keycodes is easy, and I am
intending to try to reproduce other performance bugs.

Running these benchmarks reports that that the resource usage of LyX
has been growing in a number of discrete jumps, the most significant
of these is r38163; increasing running time by about %15 and doubling
memory usage. This seems wrong to me; all r38163 is meant to do is
print some untranslated entries. I haven't been able to reproduce this
manually, but I get this result consistently with the benchmark tool.

Another result is that r38562 is three times faster than most other
revisions, I could try to find out why is this. It appears to work
correctly, so I don't know why performance suddenly got better and
then worse again.

r20010 11.02user 0.21system 0:27.76elapsed 40%CPU (344592maxresident)
r20010 11.51user 0.19system 0:21.21elapsed 55%CPU (344544maxresident)
r24000 Command terminated by signal 6 2.65user 0.15system
0:13.12elapsed 21%CPU (294992maxresident)
r25000 13.33user 0.16system 0:22.96elapsed 58%CPU (371584maxresident)
r26000 43.02user 0.19system 0:52.23elapsed 82%CPU (397792maxresident)
r27418 12.33user 0.16system 0:22.03elapsed 56%CPU (365344maxresident)
r29473 13.19user 0.26system 0:24.09elapsed 55%CPU (386736maxresident)
r29479 13.16user 0.30system 0:24.44elapsed 55%CPU (387184maxresident)
r29731 12.98user 0.18system 0:23.87elapsed 55%CPU (391824maxresident)
r29990 13.43user 0.25system 0:24.20elapsed 56%CPU (391968maxresident)
r30507 13.11user 0.25system 0:24.02elapsed 55%CPU (392304maxresident)
r30612 13.18user 0.18system 0:24.62elapsed 54%CPU (392208maxresident)
r31024 13.51user 0.36system 0:24.58elapsed 56%CPU (392368maxresident)
r31125 13.24user 0.29system 0:24.06elapsed 56%CPU (392912maxresident)
r31182 13.70user 0.27system 0:24.48elapsed 57%CPU (392592maxresident)
r31334 13.40user 0.34system 0:24.07elapsed 57%CPU (393056maxresident)
r31506 13.66user 0.33system 0:24.85elapsed 56%CPU (395152maxresident)
r31540 13.43user 0.24system 0:22.97elapsed 59%CPU (395376maxresident)
r31542 13.35user 0.28system 0:23.45elapsed 58%CPU (395472maxresident)
r32000 13.24user 0.22system 0:22.85elapsed 58%CPU (395536maxresident)
r32403 12.84user 0.14system 0:22.25elapsed 58%CPU (395728maxresident)
r32562 12.93user 0.12system 0:22.38elapsed 58%CPU (396000maxresident)
r32642 14.00user 0.25system 0:25.11elapsed 56%CPU (422256maxresident)
r32722 13.98user 0.36system 0:25.12elapsed 57%CPU (422704maxresident)
r32806 13.87user 0.30system 0:24.92elapsed 56%CPU (422752maxresident)
r33051 13.93user 0.22system 0:25.30elapsed 55%CPU (422752maxresident)
r33209 13.94user 0.10system 0:24.57elapsed 57%CPU (427312maxresident)
r33269 14.10user 0.11system 0:24.10elapsed 58%CPU (427296maxresident)
r33350 13.87user 0.11system 0:24.69elapsed 56%CPU (427072maxresident)
r33375 13.65user 0.20system 0:25.20elapsed 54%CPU (427280maxresident)
r33438 14.14user 0.16system 0:25.09elapsed 56%CPU (426944maxresident)
r33441 14.24user 0.15system 0:25.07elapsed 57%CPU (426928maxresident)
r33501 14.32user 0.34system 0:25.47elapsed 57%CPU (426928maxresident)
r33612 14.47user 0.24system 0:24.09elapsed 61%CPU (427888maxresident)
r33819 13.89user 0.13system 0:23.35elapsed 60%CPU (427024maxresident)
r33884 14.07user 0.22system 0:23.80elapsed 60%CPU (427072maxresident)
r34027 13.86user 0.23system 0:25.08elapsed 56%CPU (427392maxresident)
r34027 14.05user 0.23system 0:24.15elapsed 59%CPU (427344maxresident)
r34027 14.18user 0.13system 0:23.45elapsed 61%CPU (427616maxresident)
r34088 13.73user 0.17system 0:24.63elapsed 56%CPU (426800maxresident)
r34088 13.83user 0.13systk  basically involves spamming the following
keycodes at LyX
  \Ac \D1 \Ac \D9 \D9 \Ao \D1\Av\D10 \Ai n n nnn \[Right] asdf \r \r
iadsf \Ao \Ca \D9 \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc
\Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv
\Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Cc \Cv \Cv \Ca \Ca \Cc \Cv
\Cv \Ca \Cc \Cv \Cv \Cc MEMINFO \Cq \Cs \Ad \Ad

This causes LyX to create line of text with a LyX Note, and then make
8192 copies the line. Replacing these keycodes with others should be
easy.

Running these benchmarks reports that that the resource usage of LyX
has been growing in a number of discrete jumps, the most significant
of these is r38163; increasing running time by about %15 and doubling
memory usage. This seems wro

Re: build error with trunk on openSUSE

[Cor Blom]

Op woensdag 13 juli 2011 12:57:25 schreef Jean-Marc Lasgouttes:
> Le 13/07/2011 12:27, Cor Blom a écrit :
> > As of r39281 I still get the error above. Am I the only one and is this
> > an openSUSE problem? Or are others seeing the same? Either case, I need
> > some help here, because I don't know how to solve this.
> > 
> > Shall I file a bug report?
> 
> What is you qt version? Normally this code is compiled conditionally to
> what qt supports.
> 
> JMarc

It happens on all version I build for: 11.3 with qt 4.6.3, 11.4 with 4.7.1 and 
factory with 4.7.3

Cor

P.S. you can view all details here:

https://build.opensuse.org/package/show?package=lyx-2.1-
svn&project=home%3Acornelisbb%3Alyx-unstable

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Wed, Jul 13, 2011 at 3:53 PM, Richard Heck  wrote:

> On 07/13/2011 05:23 AM, Rainer M Krug wrote:
> > So - could somebody guide me into the direction where I could look at
> > the code for vcs handling in LyX?
> >
> src/VCBackend.cpp
>

Thanks

Rainer


>
> rh
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/13/2011 05:23 AM, Rainer M Krug wrote:
> So - could somebody guide me into the direction where I could look at
> the code for vcs handling in LyX?
>
src/VCBackend.cpp

rh

SV: [Patch] Translation update for LyX 2.0.1

[Helge Hafting]

Pavel Sanda wrote:

> ps: btw would it be possible to look on
> http://www.lyx.org/trac/ticket/7196 ?

I have made a document demonstrating headers/footers, and uploaded it to ticket 
7196. It should be useful as an example.

Helge Hafting
<>

Re: build error with trunk on openSUSE

[Jean-Marc Lasgouttes]

Le 13/07/2011 12:27, Cor Blom a écrit :

As of r39281 I still get the error above. Am I the only one and is this an
openSUSE problem? Or are others seeing the same? Either case, I need some help
here, because I don't know how to solve this.

Shall I file a bug report?


What is you qt version? Normally this code is compiled conditionally to 
what qt supports.


JMarc

Re: build error with trunk on openSUSE

[Cor Blom]

Op woensdag 6 juli 2011 10:35:24 schreef Cor Blom:
> Hi,
> 
> My build from trunk on OBS gives the following error:
> 
> [...]
>   AR liblyxmathed.a
>   AR liblyxinsets.a
>   CXXLD  lyx
> frontends/qt4/liblyxqt4.a(FancyLineEdit.o): In function `IconButton':
> /usr/src/packages/BUILD/lyx-2.1-
> svn-2.1.rev39247/src/frontends/qt4/FancyLineEdit.cpp:265: undefined
> reference to `vtable for lyx::frontend::IconButton'
> /usr/src/packages/BUILD/lyx-2.1-
> svn-2.1.rev39247/src/frontends/qt4/FancyLineEdit.cpp:265: undefined
> reference to `vtable for lyx::frontend::IconButton'
> frontends/qt4/liblyxqt4.a(FancyLineEdit.o): In function
> `qobject_cast':
> /usr/include/QtCore/qobject.h:366: undefined reference to
> `lyx::frontend::IconButton::staticMetaObject'
> collect2: ld returned 1 exit status
> make[4]: *** [lyx] Error 1
> make[4]: Leaving directory `/usr/src/packages/BUILD/lyx-2.1-
> svn-2.1.rev39247/src'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/usr/src/packages/BUILD/lyx-2.1-
> svn-2.1.rev39247/src'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/usr/src/packages/BUILD/lyx-2.1-
> svn-2.1.rev39247/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/usr/src/packages/BUILD/lyx-2.1-svn-2.1.rev39247' make: *** [all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.NtQHhb (%build)
> 
> Regards,
> 
> Cor

As of r39281 I still get the error above. Am I the only one and is this an 
openSUSE problem? Or are others seeing the same? Either case, I need some help 
here, because I don't know how to solve this.

Shall I file a bug report?

Cor

Re: GIT as vcs for lyx documents

[Rainer M Krug]

So - could somebody guide me into the direction where I could look at the
code for vcs handling in LyX?

Rainer

On Mon, Jul 11, 2011 at 4:52 PM, Pavel Sanda  wrote:

> Rainer M Krug wrote:
> > On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda  wrote:
> > This mustn't happen - but isn't this risk higher when we are trying to
> use
> > own / copied routines to check then using an established command like
> "git
> > status"?
>
> this is not about "using our code" vs "parsing git output" but
> "detecting git" vs "ignore git VCS".
>
> > For the medium term: what about per file or general options, which enable
> > certain vcs?
>
> general (by default disabled) option like "git support" was the only
> solution
> i was able to come with.
>
> pavel
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug