Am 07.03.2012 um 19:16 schrieb Richard Heck:
On 03/07/2012 09:32 AM, Stephan Witt wrote:
Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
More thoughts - what about this proposal:
On 03/09/2012 11:06 AM, Stephan Witt wrote:
Ok, here comes the patch. If anybody can give it a try - especially on
Windows - I'm interested in the result. Otherwise I'll commit it on
Sunday or so... I've introduced the FileName::parentPath() method to
avoid the infinite loop when
Am 09.03.2012 um 20:18 schrieb Richard Heck:
On 03/09/2012 11:06 AM, Stephan Witt wrote:
Ok, here comes the patch. If anybody can give it a try - especially on
Windows - I'm interested in the result. Otherwise I'll commit it on Sunday
or so... I've introduced the FileName::parentPath()
On 03/09/2012 03:20 PM, Stephan Witt wrote:
Am 09.03.2012 um 20:18 schrieb Richard Heck:
On 03/09/2012 11:06 AM, Stephan Witt wrote:
Ok, here comes the patch. If anybody can give it a try - especially on Windows
- I'm interested in the result. Otherwise I'll commit it on Sunday or so...
Am 07.03.2012 um 19:16 schrieb Richard Heck:
> On 03/07/2012 09:32 AM, Stephan Witt wrote:
>> Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
>>
>>> Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
>>> More thoughts - what
On 03/09/2012 11:06 AM, Stephan Witt wrote:
Ok, here comes the patch. If anybody can give it a try - especially on
Windows - I'm interested in the result. Otherwise I'll commit it on
Sunday or so... I've introduced the FileName::parentPath() method to
avoid the infinite loop when
Am 09.03.2012 um 20:18 schrieb Richard Heck:
> On 03/09/2012 11:06 AM, Stephan Witt wrote:
>>
>> Ok, here comes the patch. If anybody can give it a try - especially on
>> Windows - I'm interested in the result. Otherwise I'll commit it on Sunday
>> or so... I've introduced the
On 03/09/2012 03:20 PM, Stephan Witt wrote:
Am 09.03.2012 um 20:18 schrieb Richard Heck:
On 03/09/2012 11:06 AM, Stephan Witt wrote:
Ok, here comes the patch. If anybody can give it a try - especially on Windows
- I'm interested in the result. Otherwise I'll commit it on Sunday or so...
On Wed, Mar 7, 2012 at 3:15 PM, Pavel Sanda sa...@lyx.org wrote:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in .svn.
2. If possible
Am 08.03.2012 um 11:41 schrieb Abdelrazak Younes:
On Wed, Mar 7, 2012 at 3:15 PM, Pavel Sanda sa...@lyx.org wrote:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
More thoughts - what about this proposal:
1. We completely
On Wed, Mar 7, 2012 at 3:15 PM, Pavel Sanda wrote:
> Stephan Witt wrote:
>> I don't like hard-coding the knowledge how subversion developers organize
>> their meta-data.
>
> More thoughts - what about this proposal:
> 1. We completely kill parsing of 1.6 metadata in .svn.
> 2. If
Am 08.03.2012 um 11:41 schrieb Abdelrazak Younes:
> On Wed, Mar 7, 2012 at 3:15 PM, Pavel Sanda wrote:
>> Stephan Witt wrote:
>>> I don't like hard-coding the knowledge how subversion developers organize
>>> their meta-data.
>>
>> More thoughts - what about this proposal:
>> 1.
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in .svn.
2. If possible than write common routine for both 1.6/1.7 (I assume the output
of svn
Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize
their meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in .svn.
2. If possible than write common
On 03/07/2012 09:32 AM, Stephan Witt wrote:
Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize their
meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in
Stephan Witt wrote:
1. and 2. (minus --xml) is essentially my already existing patch.
3. is a thing I can live with
Now we're all happy, aren't we? :)
Yes, thanks :)
Pavel
Stephan Witt wrote:
> I don't like hard-coding the knowledge how subversion developers organize
> their meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in .svn.
2. If possible than write common routine for both 1.6/1.7 (I assume the output
of
Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> I don't like hard-coding the knowledge how subversion developers organize
>> their meta-data.
>
> More thoughts - what about this proposal:
> 1. We completely kill parsing of 1.6 metadata in .svn.
> 2. If possible than write
On 03/07/2012 09:32 AM, Stephan Witt wrote:
Am 07.03.2012 um 15:15 schrieb Pavel Sanda:
Stephan Witt wrote:
I don't like hard-coding the knowledge how subversion developers organize their
meta-data.
More thoughts - what about this proposal:
1. We completely kill parsing of 1.6 metadata in
Stephan Witt wrote:
> 1. and 2. (minus --xml) is essentially my already existing patch.
> 3. is a thing I can live with
>
> Now we're all happy, aren't we? :)
Yes, thanks :)
Pavel
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
(ab perhaps just as fallback to current current check
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
(ab perhaps just as
Stephan Witt wrote:
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.
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 perhaps just as fallback to current current
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
Stephan Witt wrote:
> > 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
Am 03.03.2012 um 20:36 schrieb Pavel Sanda:
Lars Gullik Bj?nnes wrote:
Stephan Witt wrote:
second bad news is that i'm short of time these weeks to debug it :)
Do you know more about the details? Perhaps I can do something about that.
Stephan, do you still have some time to look on
Am 03.03.2012 um 20:36 schrieb Pavel Sanda:
> Lars Gullik Bj?nnes wrote:
>
>> Stephan Witt wrote:
>>> second bad news is that i'm short of time these weeks to debug it :)
>>
>> Do you know more about the details? Perhaps I can do something about that.
>
> Stephan, do you still have some time
Lars Gullik Bj?nnes wrote:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application freezes
as well.
|
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).
Well, why don't you look in the git source. They will have found a robust way
to do this.
Vincent
Vincent van Ravesteijn wrote:
Well, why don't you look in the git source. They will have found a robust
way to do this.
Of course linking to their library would be best.
one day :)
Pavel
Lars Gullik Bj?nnes wrote:
> >> Le 26/10/2011 14:37, Pavel Sanda a écrit :
> >>> i have painful experience with applications which scan neighbourhood
> >>> of the folders you are working in case you are working in networked
> >>> filesystem. one mount point freezes and unrelated application
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).
Well, why don't you look in the git source. They will have found a robust way
to do this.
Vincent
Vincent van Ravesteijn wrote:
> Well, why don't you look in the git source. They will have found a robust
> way to do this.
Of course linking to their library would be best.
one day :)
Pavel
Georg Baum georg.b...@post.rwth-aachen.de writes:
| Pavel Sanda wrote:
it just feels wrong. when document has 10 childern we will execute it 10
times. when we introduce git then 20 times? if some win user has firewall
will we ask about execution of svn/git binary upon opening lyx manual for
Pavel Sanda sa...@lyx.org writes:
| Jean-Marc Lasgouttes wrote:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated
Pavel Sanda sa...@lyx.org writes:
| Jean-Marc Lasgouttes wrote:
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because just checking .svn dir in the current
folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
|
Georg Baum writes:
| Pavel Sanda wrote:
>
>> it just feels wrong. when document has 10 childern we will execute it 10
>> times. when we introduce git then 20 times? if some win user has firewall
>> will we ask about execution of svn/git binary upon opening lyx
Pavel Sanda writes:
| Jean-Marc Lasgouttes wrote:
>> Le 26/10/2011 14:37, Pavel Sanda a écrit :
>>> i have painful experience with applications which scan neighbourhood
>>> of the folders you are working in case you are working in networked
>>> filesystem. one mount point freezes
Pavel Sanda writes:
| Jean-Marc Lasgouttes wrote:
>> Le 26/10/2011 15:01, Pavel Sanda a écrit :
>>> the whole problem arised because "just checking" .svn dir in the current
>>> folder
>>> is no more possible with subversion 1.7.
>>
>> Because only the top svn directory has
Stephan Witt wrote:
Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
Because I've only the LYX SVN repository at hand I don't want to test
all operations. But the detection of SVN repository members is working now.
I missed some status flag: I stands for ignore.
This
Le 26/10/2011 12:05, Pavel Sanda a écrit :
i feel uneasy about this stuff being executed for opening each lyx file
(the same problem as with git), directory traversal is not better.
shall we introduce some gui variable like Use revision control systems
or am i oversensitive?
Is it a matter of
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 12:05, Pavel Sanda a écrit :
i feel uneasy about this stuff being executed for opening each lyx file
(the same problem as with git), directory traversal is not better.
shall we introduce some gui variable like Use revision control systems
or am i
Le 26/10/2011 12:21, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 12:05, Pavel Sanda a écrit :
i feel uneasy about this stuff being executed for opening each lyx file
(the same problem as with git), directory traversal is not better.
shall we introduce some gui variable like
Jean-Marc Lasgouttes wrote:
Can't we just read the local files? I agree that network access when
opening a file is wrong.
i believe svn will only access local files (though i didn't test).
pavel
Am 26.10.2011 um 12:05 schrieb Pavel Sanda:
Stephan Witt wrote:
Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
Because I've only the LYX SVN repository at hand I don't want to test
all operations. But the detection of SVN repository members is working now.
I missed some
Op 26-10-2011 13:03, Stephan Witt schreef:
Am 26.10.2011 um 12:05 schrieb Pavel Sanda:
Stephan Witt wrote:
Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
Because I've only the LYX SVN repository at hand I don't want to test
all operations. But the detection of SVN
Vincent van Ravesteijn wrote:
Stephan
I'm in favor of having some better settings for the version control
system(s), but I don't like to have another option whether to use VCS or
not.
you are against general use vcs or against subversion support, git support
checkboxes?
there is
Op 26-10-2011 13:41, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Stephan
I'm in favor of having some better settings for the version control
system(s), but I don't like to have another option whether to use VCS or
not.
you are against general use vcs or against subversion support, git
Vincent van Ravesteijn wrote:
Against all, unless you convince me this that this option really can't be
enabled always. I'm afraid this will become just another option that should
be there out of principle, but isn't ever used by the user.
there is absolutely no reason to disable it for the
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application freezes
as well.
considering that svn is used by
Op 26-10-2011 14:52, Jean-Marc Lasgouttes schreef:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application freezes
as well.
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because just checking .svn dir in the current folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
JMarc
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because just checking .svn dir in the current
folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
yes. dont know the motivations behind,
Op 26-10-2011 15:45, Pavel Sanda schreef:
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because just checking .svn dir in the current
folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
Vincent van Ravesteijn wrote:
So I'm happy they finally saw the light.
:) if one seeks the light he should probably switch to git...
breaking older things to work means perhaps one reason less
to continue to use svn at all.
p
On Wed, Oct 26, 2011 at 04:02:08PM +0200, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
So I'm happy they finally saw the light.
:) if one seeks the light he should probably switch to git...
breaking older things to work means perhaps one reason less
to continue to use svn at all.
Am 26.10.2011 um 16:21 schrieb Enrico Forestieri:
On Wed, Oct 26, 2011 at 04:02:08PM +0200, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
So I'm happy they finally saw the light.
:) if one seeks the light he should probably switch to git...
breaking older things to work means perhaps
Am 26.10.2011 um 15:01 schrieb Pavel Sanda:
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and
Pavel Sanda wrote:
it just feels wrong. when document has 10 childern we will execute it 10
times. when we introduce git then 20 times? if some win user has firewall
will we ask about execution of svn/git binary upon opening lyx manual for
the first time after lyx is launched and so on...
Georg Baum wrote:
Parsing internal svn files from LyX looks as wrong to me as starting the svn
client a dozen times. A better solution would be to use svn not as a binary,
but link to the library. I even tried that some time ago. It does not look
too bad, but I never finished it.
yep,
On 26/10/2011 21:56, Georg Baum wrote:
Pavel Sanda wrote:
it just feels wrong. when document has 10 childern we will execute it 10
times. when we introduce git then 20 times? if some win user has firewall
will we ask about execution of svn/git binary upon opening lyx manual for
the first time
Stephan Witt wrote:
> > Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
> > Because I've only the LYX SVN repository at hand I don't want to test
> > all operations. But the detection of SVN repository members is working now.
>
> I missed some status flag: "I" stands for ignore.
Le 26/10/2011 12:05, Pavel Sanda a écrit :
i feel uneasy about this stuff being executed for opening each lyx file
(the same problem as with git), directory traversal is not better.
shall we introduce some gui variable like "Use revision control systems"
or am i oversensitive?
Is it a matter
Jean-Marc Lasgouttes wrote:
> Le 26/10/2011 12:05, Pavel Sanda a écrit :
>> i feel uneasy about this stuff being executed for opening each lyx file
>> (the same problem as with git), directory traversal is not better.
>> shall we introduce some gui variable like "Use revision control systems"
>>
Le 26/10/2011 12:21, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 12:05, Pavel Sanda a écrit :
i feel uneasy about this stuff being executed for opening each lyx file
(the same problem as with git), directory traversal is not better.
shall we introduce some gui variable like
Jean-Marc Lasgouttes wrote:
> Can't we just read the local files? I agree that network access when
> opening a file is wrong.
i believe svn will only access local files (though i didn't test).
pavel
Am 26.10.2011 um 12:05 schrieb Pavel Sanda:
> Stephan Witt wrote:
>>> Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
>>> Because I've only the LYX SVN repository at hand I don't want to test
>>> all operations. But the detection of SVN repository members is working now.
>>
>>
Op 26-10-2011 13:03, Stephan Witt schreef:
Am 26.10.2011 um 12:05 schrieb Pavel Sanda:
Stephan Witt wrote:
Pavel, I've tested this patch with 1.7 SVN and on Linux with 1.6.
Because I've only the LYX SVN repository at hand I don't want to test
all operations. But the detection of SVN
Vincent van Ravesteijn wrote:
>> Stephan
> I'm in favor of having some better settings for the version control
> system(s), but I don't like to have another option whether to use VCS or
> not.
you are against general "use vcs" or against "subversion support", "git support"
checkboxes?
> there
Op 26-10-2011 13:41, Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Stephan
I'm in favor of having some better settings for the version control
system(s), but I don't like to have another option whether to use VCS or
not.
you are against general "use vcs" or against "subversion support",
Vincent van Ravesteijn wrote:
> Against all, unless you convince me this that this option really can't be
> enabled always. I'm afraid this will become just another option that should
> be there out of principle, but isn't ever used by the user.
>
>>> there is absolutely no reason to disable it
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application freezes
as well.
considering that svn is used by
Op 26-10-2011 14:52, Jean-Marc Lasgouttes schreef:
Le 26/10/2011 14:37, Pavel Sanda a écrit :
i have painful experience with applications which scan neighbourhood
of the folders you are working in case you are working in networked
filesystem. one mount point freezes and unrelated application
Jean-Marc Lasgouttes wrote:
> Le 26/10/2011 14:37, Pavel Sanda a écrit :
>> i have painful experience with applications which scan neighbourhood
>> of the folders you are working in case you are working in networked
>> filesystem. one mount point freezes and unrelated application freezes
>> as
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because "just checking" .svn dir in the current folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
JMarc
Jean-Marc Lasgouttes wrote:
> Le 26/10/2011 15:01, Pavel Sanda a écrit :
>> the whole problem arised because "just checking" .svn dir in the current
>> folder
>> is no more possible with subversion 1.7.
>
> Because only the top svn directory has information, right?
yes. dont know the motivations
Op 26-10-2011 15:45, Pavel Sanda schreef:
Jean-Marc Lasgouttes wrote:
Le 26/10/2011 15:01, Pavel Sanda a écrit :
the whole problem arised because "just checking" .svn dir in the current
folder
is no more possible with subversion 1.7.
Because only the top svn directory has information, right?
Vincent van Ravesteijn wrote:
> So I'm happy they finally saw the light.
:) if one seeks the light he should probably switch to git...
breaking older things to work means perhaps one reason less
to continue to use svn at all.
p
On Wed, Oct 26, 2011 at 04:02:08PM +0200, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > So I'm happy they finally saw the light.
>
> :) if one seeks the light he should probably switch to git...
>
> breaking older things to work means perhaps one reason less
> to continue to use svn at
Am 26.10.2011 um 16:21 schrieb Enrico Forestieri:
> On Wed, Oct 26, 2011 at 04:02:08PM +0200, Pavel Sanda wrote:
>> Vincent van Ravesteijn wrote:
>>> So I'm happy they finally saw the light.
>>
>> :) if one seeks the light he should probably switch to git...
>>
>> breaking older things to work
Am 26.10.2011 um 15:01 schrieb Pavel Sanda:
> Jean-Marc Lasgouttes wrote:
>> Le 26/10/2011 14:37, Pavel Sanda a écrit :
>>> i have painful experience with applications which scan neighbourhood
>>> of the folders you are working in case you are working in networked
>>> filesystem. one mount point
Pavel Sanda wrote:
> it just feels wrong. when document has 10 childern we will execute it 10
> times. when we introduce git then 20 times? if some win user has firewall
> will we ask about execution of svn/git binary upon opening lyx manual for
> the first time after lyx is launched and so on...
Georg Baum wrote:
> Parsing internal svn files from LyX looks as wrong to me as starting the svn
> client a dozen times. A better solution would be to use svn not as a binary,
> but link to the library. I even tried that some time ago. It does not look
> too bad, but I never finished it.
yep,
On 26/10/2011 21:56, Georg Baum wrote:
Pavel Sanda wrote:
it just feels wrong. when document has 10 childern we will execute it 10
times. when we introduce git then 20 times? if some win user has firewall
will we ask about execution of svn/git binary upon opening lyx manual for
the first time
Hi all :
The folder.svn in version 1.7 has two subfolders pristine and tmp, while
the.svnversion 1.6, I remember several subfolders, such
as propdel, propset and three more that are handled
by LyX. When accessing LyX to the version 1.7 is all completelychanged.
Regards
Miguel
Hi all :
The folder.svn in version 1.7 has two subfolders pristine and tmp, while
the.svnversion 1.6, I remember several subfolders, such
as propdel, propset and three more that are handled
by LyX. When accessing LyX to the version 1.7 is all completelychanged.
Regards
Miguel
Hi all :
I used a repository, made with svn 1.6 and I open my LyX documents, and
they worked perfectly. Then I did a svn upgrade to version 1.7 and LyX,
you can not put them under version control, so I conclude that there is
a problem with this newversion and the program LyX 2.1.0svn.
Regards
Am 24.10.2011 um 16:55 schrieb Buenas Noticias:
Hi all :
I used a repository, made with svn 1.6 and I open my LyX documents, and they
worked perfectly. Then I did a svn upgrade to version 1.7 and LyX, you can
not put them under version control, so I conclude that there is a problem
with
I don't know make these. I am a normal user, what discover a problem in
the svn version control.
Regards
El 24/10/11 17:05, Stephan Witt escribió:
Am 24.10.2011 um 16:55 schrieb Buenas Noticias:
Hi all :
I used a repository, made with svn 1.6 and I open my LyX documents, and they
worked
Am 24.10.2011 um 17:11 schrieb Buenas Noticias:
I don't know make these. I am a normal user, what discover a problem in
the svn version control.
You're able to upgrade your SVN to 1.7 and cannot create a ticket in our
trac-system?
Did you try it already?
Stephan
El 24/10/11 17:05,
Hi all :
I used a repository, made with svn 1.6 and I open my LyX documents, and
they worked perfectly. Then I did a svn upgrade to version 1.7 and LyX,
you can not put them under version control, so I conclude that there is
a problem with this newversion and the program LyX 2.1.0svn.
Regards
Am 24.10.2011 um 16:55 schrieb Buenas Noticias:
> Hi all :
>
> I used a repository, made with svn 1.6 and I open my LyX documents, and they
> worked perfectly. Then I did a svn upgrade to version 1.7 and LyX, you can
> not put them under version control, so I conclude that there is a problem
I don't know make these. I am a normal user, what discover a problem in
the svn version control.
Regards
El 24/10/11 17:05, Stephan Witt escribió:
> Am 24.10.2011 um 16:55 schrieb Buenas Noticias:
>
>> Hi all :
>>
>> I used a repository, made with svn 1.6 and I open my LyX documents, and they
Am 24.10.2011 um 17:11 schrieb Buenas Noticias:
> I don't know make these. I am a normal user, what discover a problem in
> the svn version control.
>
You're able to upgrade your SVN to 1.7 and cannot create a ticket in our
trac-system?
Did you try it already?
Stephan
> El 24/10/11 17:05,
Am 21.10.2011 um 22:25 schrieb Stephan Witt:
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
Am 23.10.2011 um 14:15 schrieb Stephan Witt:
Am 21.10.2011 um 22:25 schrieb Stephan Witt:
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
Am 21.10.2011 um 22:25 schrieb Stephan Witt:
> Am 21.10.2011 um 21:38 schrieb Lars Gullik Bjønnes:
>
>> Stephan Witt writes:
>>
>> | Am 21.10.2011 um 14:09 schrieb Pavel Sanda:
>>>
Buenas Noticias wrote:
> Ok. Subversion 1.7 is incompatible with LyX.
maybe
Am 23.10.2011 um 14:15 schrieb Stephan Witt:
> Am 21.10.2011 um 22:25 schrieb Stephan Witt:
>
>> Am 21.10.2011 um 21:38 schrieb Lars Gullik Bjønnes:
>>
>>> Stephan Witt writes:
>>>
>>> | Am 21.10.2011 um 14:09 schrieb Pavel Sanda:
> Buenas Noticias wrote:
>> Ok.
1 - 100 of 136 matches
Mail list logo