Am 27.10.2010 um 11:14 schrieb Vincent van Ravesteijn:
> You know what would be cool ?
>
> Version Control BLAME :)... that LyX shows you the whole document
> colored with when the last change was, and if you hover over with your
> mouse, a popup will show, who wrote it, when he wrote it, and wha
Vincent van Ravesteijn wrote:
> You know what would be cool ?
>
> Version Control BLAME :)... that LyX shows you the whole document
:D
> colored with when the last change was, and if you hover over with your
> mouse, a popup will show, who wrote it, when he wrote it, and what his
> reason was to
You know what would be cool ?
Version Control BLAME :)... that LyX shows you the whole document
colored with when the last change was, and if you hover over with your
mouse, a popup will show, who wrote it, when he wrote it, and what his
reason was to write it (read log).
Anyone ?
Vincent
Stephan Witt wrote:
> I've done a little bit... before I continue, what are the rules here?
there are no specific rules for this manual.
> Use current lyx version - trunk for trunk and branch for branch, I guess?
yes.
> Turn on change tracking?
> Edit the english version and hope for translatio
Am 25.10.2010 um 14:07 schrieb Stephan Witt:
> Am 25.10.2010 um 13:02 schrieb Pavel Sanda:
>
>> please make documentation for the current cvs state inside additional manual
>> and indicate to the users what are the supposed usecases.
>
> I'll do that.
I've done a little bit... before I continue
Am 26.10.2010 um 18:19 schrieb Jürgen Spitzmüller:
> Stephan Witt wrote:
>>> I would be more comfortable to wait with this until 1.6.8 is out, so it
>>> can be tested a bit.
>>
>> I'm comfortable with waiting after 1.6.8. We're using 1.6.7 for now.
>> If 1.6.8 is out I can build 1.6.9svn for int
Stephan Witt wrote:
> > I would be more comfortable to wait with this until 1.6.8 is out, so it
> > can be tested a bit.
>
> I'm comfortable with waiting after 1.6.8. We're using 1.6.7 for now.
> If 1.6.8 is out I can build 1.6.9svn for internal use after the patch is
> applied. I'd hope for 1.6.
Am 26.10.2010 um 10:06 schrieb Jürgen Spitzmüller:
> Stephan Witt wrote:
>> The patch is ready and attached.
>> I tested all CVS functions and it works here.
>
> The patch is certainly much bigger than what suits me now, and it introduces
> new strings.
>
> I would be more comfortable to wait w
Stephan Witt wrote:
> The patch is ready and attached.
> I tested all CVS functions and it works here.
The patch is certainly much bigger than what suits me now, and it introduces
new strings.
I would be more comfortable to wait with this until 1.6.8 is out, so it can be
tested a bit.
However,
Stephan Witt wrote:
> Now, I have an patch at hand again. I can continue to use and provide a
> patched version
> for my colleges, of course. But I claim it's useful for others, too.
only misunderstanding, i didn't want to dispute backport. i only wanted to have
documentation even in 1.6 so its u
Am 25.10.2010 um 23:14 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
>>
>>> Stephan Witt wrote:
The patch is ready and attached.
I tested all CVS functions and it works here.
>>>
>>> looks fine.
>>
>> Thanks.
>>
>>> the documentation of cou
Stephan Witt wrote:
> Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
>
> > Stephan Witt wrote:
> >> The patch is ready and attached.
> >> I tested all CVS functions and it works here.
> >
> > looks fine.
>
> Thanks.
>
> > the documentation of course ;)
>
> Sorry, I don't understand you.
> You mea
Am 25.10.2010 um 22:01 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> The patch is ready and attached.
>> I tested all CVS functions and it works here.
>
> looks fine.
Thanks.
> the documentation of course ;)
Sorry, I don't understand you.
You mean after writing the documentation I should backp
Stephan Witt wrote:
> The patch is ready and attached.
> I tested all CVS functions and it works here.
looks fine. the documentation of course ;)
pavel
Am 25.10.2010 um 16:53 schrieb Jürgen Spitzmüller:
> Stephan Witt wrote:
>> I'd like to prepare a backport of the CVS backend changes to make it usable
>> in 1.6.8. The dialog part of the changes I would skip so the other
>> backends are not modified.
>> May I do that or is it too late?
>
> If y
Stephan Witt wrote:
> I'd like to prepare a backport of the CVS backend changes to make it usable
> in 1.6.8. The dialog part of the changes I would skip so the other
> backends are not modified.
> May I do that or is it too late?
If you are very fast and if the changes are safe. In general, I'd
Stephan Witt wrote:
> Am 25.10.2010 um 14:45 schrieb Pavel Sanda:
>
> > Stephan Witt wrote:
> >> Patch is attached. Ok to apply?
> >
> > please go on.
>
> Done. (r35828)
>
> I'd like to prepare a backport of the CVS backend changes to make it usable
> in 1.6.8.
> The dialog part of the changes
Am 25.10.2010 um 14:45 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Patch is attached. Ok to apply?
>
> please go on.
Done. (r35828)
I'd like to prepare a backport of the CVS backend changes to make it usable in
1.6.8.
The dialog part of the changes I would skip so the other backends are not
Stephan Witt wrote:
> Patch is attached. Ok to apply?
please go on.
pavel
Am 25.10.2010 um 13:02 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Or I can go to rcs and you'll do the svn implementation?
>
> i came to the conclusion that its less energy spent when i write the patch
> myself
> than doing detailed review and flame about nitpicks.
Ok. I finished the part2 o
Stephan Witt wrote:
> Or I can go to rcs and you'll do the svn implementation?
i came to the conclusion that its less energy spent when i write the patch
myself
than doing detailed review and flame about nitpicks.
please make documentation for the current cvs state inside additional manual
and i
Am 25.10.2010 um 00:53 schrieb Pavel Sanda:
> Pavel Sanda wrote:
>> the 2nd patch is not finished should i apply here and try to finish svn part
Yes, I know. But I did want to consolidate cvs before going to svn or rcs.
I'll have to setup a local svn repository to be able to test that - if you li
Pavel Sanda wrote:
> the 2nd patch is not finished should i apply here and try to finish svn part
here is the superflous-dialog fix which is on the top of your first patch.
it basically (should) not change behaviour of svn and rcs and let you do any
bussiness inside cvs (i let the cvs routines in
Stephan Witt wrote:
> I had to change many bad problems inside the CVS code and now the
> bugfix depends on that changes. I'd like to present a patch to
> correct the error situations inside CVS as base patch
please put in the first part. i didn't looked too carefully, just
saw one typo - you forg
Am 24.10.2010 um 19:09 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> So I can apply the attached patch to solve the ui bug.
>
> ok.
Done.
> btw how the bugfix about superfluous dialog continues?
> it looked nearly finished and i would like to have this in soon...
I had to change many bad pro
Stephan Witt wrote:
> So I can apply the attached patch to solve the ui bug.
ok.
> The core issues I'd like to left to someone other.
i will look later.
btw how the bugfix about superfluous dialog continues?
it looked nearly finished and i would like to have this in soon...
pavel
Am 24.10.2010 um 18:43 schrieb Pavel Sanda:
> Pavel Sanda wrote:
>
> thinking more about the whole issue, more proper solution would be perhaps
> reloading the whole buffer.
> your patch solves only the ui glitch but let the core issue unresolved -
> there is not-up-to-date
> stuff left _inside
Pavel Sanda wrote:
thinking more about the whole issue, more proper solution would be perhaps
reloading the whole buffer.
your patch solves only the ui glitch but let the core issue unresolved - there
is not-up-to-date
stuff left _inside_ the buffer, not to speak about undo buffer.
we need in r
Stephan Witt wrote:
> > hmm, but then we destroy vcs object for each save, no?
>
> Yes.
>
> > if we decide to store there some info which should survive during buffer
> > life it will be killed.
>
> Is it the case already?
havent looked but dont think so.
> I can see the advantage that the vc
Am 23.10.2010 um 21:52 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Am 23.10.2010 um 21:24 schrieb Pavel Sanda:
>>
>>> Stephan Witt wrote:
@@ -2207,6 +2209,7 @@
if (b.save()) {
theSession().lastFiles().add(b.fileName());
+ b.lyxvc().file_found_hoo
Stephan Witt wrote:
> Am 23.10.2010 um 21:24 schrieb Pavel Sanda:
>
> > Stephan Witt wrote:
> >> @@ -2207,6 +2209,7 @@
> >>
> >>if (b.save()) {
> >>theSession().lastFiles().add(b.fileName());
> >> + b.lyxvc().file_found_hook(b.fileName());
> >
> > is there reason why is
Am 23.10.2010 um 21:24 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> @@ -2207,6 +2209,7 @@
>>
>> if (b.save()) {
>> theSession().lastFiles().add(b.fileName());
>> +b.lyxvc().file_found_hook(b.fileName());
>
> is there reason why is this in saveBuffer and not in rena
Stephan Witt wrote:
> @@ -2207,6 +2209,7 @@
>
> if (b.save()) {
> theSession().lastFiles().add(b.fileName());
> + b.lyxvc().file_found_hook(b.fileName());
is there reason why is this in saveBuffer and not in renameBuffer?
pavel
I've found another problem with VCS code.
If I save a file under version control as copy with another name then the VCS
infrastructure of the buffer is outdated and wrong.
The buffer references a new file now but the VC menu and title doesn't reflect
that.
The patch is attached. Ok to apply?
St
34 matches
Mail list logo
