On Mon, 7 Jan 2013 13:06:04 +
Gregory Jefferis jeffe...@gmail.com wrote:
maybe cc yourself on ticket to indicate your interest, but existing
document comparison produces poor results as noted here:
Tried to guess the username/email combo, and although I'd say the
username is 'gour', I am
On Mon, 7 Jan 2013 13:06:04 +
Gregory Jefferis jeffe...@gmail.com wrote:
maybe cc yourself on ticket to indicate your interest, but existing
document comparison produces poor results as noted here:
Tried to guess the username/email combo, and although I'd say the
username is 'gour', I am
On Mon, 7 Jan 2013 13:06:04 +
Gregory Jefferis wrote:
> maybe cc yourself on ticket to indicate your interest, but existing
> document comparison produces poor results as noted here:
Tried to guess the username/email combo, and although I'd say the
username is 'gour', I
On 3 Jan 2013, at 15:35, Gour wrote:
I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
interesting.
maybe cc yourself on ticket to indicate your interest, but existing document
comparison produces poor results as noted here:
http://www.lyx.org/trac/ticket/6889
so you
On 3 Jan 2013, at 15:35, Gour wrote:
I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
interesting.
maybe cc yourself on ticket to indicate your interest, but existing document
comparison produces poor results as noted here:
http://www.lyx.org/trac/ticket/6889
so you
On 3 Jan 2013, at 15:35, Gour wrote:
> I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
> interesting.
maybe cc yourself on ticket to indicate your interest, but existing document
comparison produces poor results as noted here:
http://www.lyx.org/trac/ticket/6889
so you
On Wed, 12 Dec 2012 11:14:58 -0600
Nico Williams n...@cryptonector.com wrote:
That's what I want. I think it's quite doable if we have a consistent
XML representation of LyX that can be converted in both directions.
That's because there are nice XML diff algorithms. LyX already
supports
On Wed, 12 Dec 2012 11:14:58 -0600
Nico Williams n...@cryptonector.com wrote:
That's what I want. I think it's quite doable if we have a consistent
XML representation of LyX that can be converted in both directions.
That's because there are nice XML diff algorithms. LyX already
supports
On Wed, 12 Dec 2012 11:14:58 -0600
Nico Williams wrote:
> That's what I want. I think it's quite doable if we have a consistent
> XML representation of LyX that can be converted in both directions.
> That's because there are nice XML diff algorithms. LyX already
>
Gregory Jefferis wrote:
In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious ?
If you mean git merge then I'm happy to tell you that some people I need to
work with even don't
know what is command line in which you can write the
On 12 Dec 2012, at 13:49, Pavel Sanda wrote:
I think the idea of merging is pretty obvious ?
If you mean git merge then I'm happy to tell you that some people I need to
work with even don't
know what is command line in which you can write the command or decrypt
whatever comes from git
On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda sa...@lyx.org wrote:
Gregory Jefferis wrote:
One solution would be to detect merge conflicts and call our diff algorithm
for the different versions.
This would be beautiful but an order of magnitude harder to implement (surely
not me:)
That's
Gregory Jefferis wrote:
In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious ?
If you mean git merge then I'm happy to tell you that some people I need to
work with even don't
know what is command line in which you can write the
On 12 Dec 2012, at 13:49, Pavel Sanda wrote:
I think the idea of merging is pretty obvious ?
If you mean git merge then I'm happy to tell you that some people I need to
work with even don't
know what is command line in which you can write the command or decrypt
whatever comes from git
On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda sa...@lyx.org wrote:
Gregory Jefferis wrote:
One solution would be to detect merge conflicts and call our diff algorithm
for the different versions.
This would be beautiful but an order of magnitude harder to implement (surely
not me:)
That's
Gregory Jefferis wrote:
> > In such world even knowing what "merging" or "branching" means qualifies
> I think the idea of merging is pretty obvious ?
If you mean "git merge" then I'm happy to tell you that some people I need to
work with even don't
know what is command line in which you can
On 12 Dec 2012, at 13:49, Pavel Sanda wrote:
>> I think the idea of merging is pretty obvious ?
>
> If you mean "git merge" then I'm happy to tell you that some people I need to
> work with even don't
> know what is command line in which you can write the command or decrypt
> whatever comes
On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda wrote:
> Gregory Jefferis wrote:
> One solution would be to detect merge conflicts and call our diff algorithm
> for the different versions.
> This would be beautiful but an order of magnitude harder to implement (surely
> not me:)
Gregory Jefferis wrote:
Returning to the original question of merging + VCS, we currently use git +
lyx for collaborative editing of papers in the lab (normally =3 people)
using git's built in merge. For us this a tremendous improvement over the
emailed word file strategy. We have not
On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda sa...@lyx.org wrote:
We currently use integrated SVN support of LyX for this.
The merge conflicts are avoided by locking the whole document or childern
(parts of the text).
It is precisely because locking doesn't scale that we have branching
and
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does not scale. This is true even of
documents (as opposed to source code).
Conditions I had in mind were:
a)
- small team working on e.g. scientific paper
- avoid endless
On Tue, Dec 11, 2012 at 12:25 PM, Pavel Sanda sa...@lyx.org wrote:
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does not scale. This is true even of
documents (as opposed to source code).
Conditions I had in mind
Nico Williams wrote:
I believe merging is easier than locking, even for small teams.
That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is push red
button, push green button and I know what I'm talking
On Tuesday, December 11, 2012, Pavel Sanda wrote:
Nico Williams wrote:
I believe merging is easier than locking, even for small teams.
That's because you probably work with people with computer science
background.
The moment you step out of these waters the most you can expect is push
red
(wrote this up and noticed that much of it duplicates what Nico said – merging
is easy and branching is not so bad either)
On 11 Dec 2012, at 18:25, Pavel Sanda wrote:
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does
Le 12/12/12 00:06, Nico Williams a écrit :
Anyone who would use track changes can merge. In any case, a merge
capability would be huge.
Sure, but not trivial to implement...
JMarc
Gregory Jefferis wrote:
Returning to the original question of merging + VCS, we currently use git +
lyx for collaborative editing of papers in the lab (normally =3 people)
using git's built in merge. For us this a tremendous improvement over the
emailed word file strategy. We have not
On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda sa...@lyx.org wrote:
We currently use integrated SVN support of LyX for this.
The merge conflicts are avoided by locking the whole document or childern
(parts of the text).
It is precisely because locking doesn't scale that we have branching
and
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does not scale. This is true even of
documents (as opposed to source code).
Conditions I had in mind were:
a)
- small team working on e.g. scientific paper
- avoid endless
On Tue, Dec 11, 2012 at 12:25 PM, Pavel Sanda sa...@lyx.org wrote:
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does not scale. This is true even of
documents (as opposed to source code).
Conditions I had in mind
Nico Williams wrote:
I believe merging is easier than locking, even for small teams.
That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is push red
button, push green button and I know what I'm talking
On Tuesday, December 11, 2012, Pavel Sanda wrote:
Nico Williams wrote:
I believe merging is easier than locking, even for small teams.
That's because you probably work with people with computer science
background.
The moment you step out of these waters the most you can expect is push
red
(wrote this up and noticed that much of it duplicates what Nico said – merging
is easy and branching is not so bad either)
On 11 Dec 2012, at 18:25, Pavel Sanda wrote:
Nico Williams wrote:
It is precisely because locking doesn't scale that we have branching
and merging. Locking simply does
Le 12/12/12 00:06, Nico Williams a écrit :
Anyone who would use track changes can merge. In any case, a merge
capability would be huge.
Sure, but not trivial to implement...
JMarc
Gregory Jefferis wrote:
> Returning to the original question of merging + VCS, we currently use git +
> lyx for collaborative editing of papers in the lab (normally <=3 people)
> using git's built in merge. For us this a tremendous improvement over the
> emailed word file strategy. We have not
On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda wrote:
> We currently use integrated SVN support of LyX for this.
> The merge conflicts are avoided by locking the whole document or childern
> (parts of the text).
It is precisely because locking doesn't scale that we have branching
Nico Williams wrote:
> It is precisely because locking doesn't scale that we have branching
> and merging. Locking simply does not scale. This is true even of
> documents (as opposed to source code).
Conditions I had in mind were:
a)
- small team working on e.g. scientific paper
- avoid endless
On Tue, Dec 11, 2012 at 12:25 PM, Pavel Sanda wrote:
> Nico Williams wrote:
>> It is precisely because locking doesn't scale that we have branching
>> and merging. Locking simply does not scale. This is true even of
>> documents (as opposed to source code).
>
> Conditions I had
Nico Williams wrote:
> I believe merging is easier than locking, even for small teams.
That's because you probably work with people with computer science background.
The moment you step out of these waters the most you can expect is "push red
button, push green button" and I know what I'm talking
On Tuesday, December 11, 2012, Pavel Sanda wrote:
> Nico Williams wrote:
> > I believe merging is easier than locking, even for small teams.
>
> That's because you probably work with people with computer science
> background.
> The moment you step out of these waters the most you can expect is
(wrote this up and noticed that much of it duplicates what Nico said – merging
is easy and branching is not so bad either)
On 11 Dec 2012, at 18:25, Pavel Sanda wrote:
> Nico Williams wrote:
>> It is precisely because locking doesn't scale that we have branching
>> and merging. Locking simply
Le 12/12/12 00:06, Nico Williams a écrit :
Anyone who would use track changes can merge. In any case, a merge
capability would be huge.
Sure, but not trivial to implement...
JMarc
On 7 Dec 2012, at 17:46, Nico Williams wrote:
On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
On 07/12/12 12:45, Gregory Jefferis wrote:
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both versions to latex,
On 7 Dec 2012, at 17:46, Nico Williams wrote:
On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
On 07/12/12 12:45, Gregory Jefferis wrote:
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both versions to latex,
On 7 Dec 2012, at 17:46, Nico Williams wrote:
> On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug wrote:
>> On 07/12/12 12:45, Gregory Jefferis wrote:
>>> Has anyone tried using latexdiff for change comparison in not merging?
>>> Presumably a small script to export both
On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
I agree with this comment - I wanted to use the comparison tool for comparing
two revisions, and
the result was simply unusable.
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/12 12:45, Gregory Jefferis wrote:
On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
I agree with this comment - I wanted to use the comparison tool for
comparing two revisions, and
the result was simply unusable.
Has anyone tried
On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
On 07/12/12 12:45, Gregory Jefferis wrote:
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both versions to latex, invoke latexdiff
and then generate the
On Fri, Dec 7, 2012 at 6:46 PM, Nico Williams n...@cryptonector.com wrote:
Unless converstion to/from
LaTeX is loss-less
It isn't necessarily.
Liviu
On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
I agree with this comment - I wanted to use the comparison tool for comparing
two revisions, and
the result was simply unusable.
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/12 12:45, Gregory Jefferis wrote:
On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
I agree with this comment - I wanted to use the comparison tool for
comparing two revisions, and
the result was simply unusable.
Has anyone tried
On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug r.m.k...@gmail.com wrote:
On 07/12/12 12:45, Gregory Jefferis wrote:
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both versions to latex, invoke latexdiff
and then generate the
On Fri, Dec 7, 2012 at 6:46 PM, Nico Williams n...@cryptonector.com wrote:
Unless converstion to/from
LaTeX is loss-less
It isn't necessarily.
Liviu
On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
> I agree with this comment - I wanted to use the comparison tool for comparing
> two revisions, and
> the result was simply unusable.
Has anyone tried using latexdiff for change comparison in not merging?
Presumably a small script to export both
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/12 12:45, Gregory Jefferis wrote:
>
> On 6 Dec 2012, at 08:05, Rainer M Krug wrote:
>
>> I agree with this comment - I wanted to use the comparison tool for
>> comparing two revisions, and
>> the result was simply unusable.
>
> Has anyone
On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug wrote:
> On 07/12/12 12:45, Gregory Jefferis wrote:
>> Has anyone tried using latexdiff for change comparison in not merging?
>> Presumably a small script to export both versions to latex, invoke latexdiff
>> and then generate
On Fri, Dec 7, 2012 at 6:46 PM, Nico Williams wrote:
Unless converstion to/from
> LaTeX is loss-less
>
It isn't necessarily.
Liviu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/12 19:44, Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/12 19:44, Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/12 19:44, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> Le 04/12/2012 18:10, Nico Williams a écrit :
>>> What would the exact command-line invocation be?
>>
>> Unfortunately, it seems that there is no lfun to do that. The only one is
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Not part of the official API
On Wed, Dec 5, 2012 at 12:44 PM, Pavel Sanda sa...@lyx.org wrote:
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Not part of the official API
On Wed, Dec 5, 2012 at 12:44 PM, Pavel Sanda sa...@lyx.org wrote:
Jean-Marc Lasgouttes wrote:
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares
Jean-Marc Lasgouttes wrote:
> Le 04/12/2012 18:10, Nico Williams a écrit :
>> What would the exact command-line invocation be?
>
> Unfortunately, it seems that there is no lfun to do that. The only one is
> vc-compare, which compares documents already in version control.
Not part of the official
On Wed, Dec 5, 2012 at 12:44 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> Le 04/12/2012 18:10, Nico Williams a écrit :
>>> What would the exact command-line invocation be?
>>
>> Unfortunately, it seems that there is no lfun to do that. The only one is
>> vc-compare,
Le 04/12/2012 08:41, Liviu Andronic a écrit :
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams n...@cryptonector.com wrote:
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Have you looked into Document Track Changes?
The problem is probably to see how to invoke that from command line.
Good question. Theoretically is it possible to diff two LyX documents
using the --execute CLI
Le 04/12/2012 09:22, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Have you looked into Document Track Changes?
The problem is probably to see how to invoke that from command line.
Good question. Theoretically is it possible to diff
What would the exact command-line invocation be?
Nico
--
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one
is vc-compare, which compares documents already in version control.
JMarc
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Is it worth filing a feature request on bug tracker?
Liviu
Le 04/12/2012 19:32, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Is it worth filing a feature
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user interaction, as the idea
is to use this as a
Le 04/12/2012 19:42, Nico Williams a écrit :
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user
Le 04/12/2012 08:41, Liviu Andronic a écrit :
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams n...@cryptonector.com wrote:
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Have you looked into Document Track Changes?
The problem is probably to see how to invoke that from command line.
Good question. Theoretically is it possible to diff two LyX documents
using the --execute CLI
Le 04/12/2012 09:22, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Have you looked into Document Track Changes?
The problem is probably to see how to invoke that from command line.
Good question. Theoretically is it possible to diff
What would the exact command-line invocation be?
Nico
--
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one
is vc-compare, which compares documents already in version control.
JMarc
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Is it worth filing a feature request on bug tracker?
Liviu
Le 04/12/2012 19:32, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Is it worth filing a feature
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user interaction, as the idea
is to use this as a
Le 04/12/2012 19:42, Nico Williams a écrit :
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user
Le 04/12/2012 08:41, Liviu Andronic a écrit :
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams wrote:
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes wrote:
>> Have you looked into Document > Track Changes?
>
> The problem is probably to see how to invoke that from command line.
>
Good question. Theoretically is it possible to diff two LyX documents
using the --execute
Le 04/12/2012 09:22, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 9:06 AM, Jean-Marc Lasgouttes wrote:
Have you looked into Document > Track Changes?
The problem is probably to see how to invoke that from command line.
Good question. Theoretically is it possible to
What would the exact command-line invocation be?
Nico
--
Le 04/12/2012 18:10, Nico Williams a écrit :
What would the exact command-line invocation be?
Unfortunately, it seems that there is no lfun to do that. The only one
is vc-compare, which compares documents already in version control.
JMarc
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes wrote:
> Unfortunately, it seems that there is no lfun to do that. The only one is
> vc-compare, which compares documents already in version control.
>
Is it worth filing a feature request on bug tracker?
Liviu
Le 04/12/2012 19:32, Liviu Andronic a écrit :
On Tue, Dec 4, 2012 at 7:30 PM, Jean-Marc Lasgouttes wrote:
Unfortunately, it seems that there is no lfun to do that. The only one is
vc-compare, which compares documents already in version control.
Is it worth filing a
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user interaction, as the idea
is to use this as a
Le 04/12/2012 19:42, Nico Williams a écrit :
Ideally the syntax should be something like: lyx --merge --out=doc3
doc1 doc2, and the result should be a merged document with change
tracking so that the user can do all semantic merging. In this mode
LyX should not open a window nor require user
Hi,
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain diffs that users can merge
manually. Are there any such tools? Thanks,
Nico
--
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams n...@cryptonector.com wrote:
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain diffs that users can merge
manually. Are
Hi,
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain diffs that users can merge
manually. Are there any such tools? Thanks,
Nico
--
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams n...@cryptonector.com wrote:
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain diffs that users can merge
manually. Are
Hi,
I'd like to use LyX + git (or some such VCS) to cooperatively edit
documents. This requires a diff/merge tool that is LyX-aware and can
result in LyX documents that contain diffs that users can merge
manually. Are there any such tools? Thanks,
Nico
--
On Mon, Dec 3, 2012 at 6:44 PM, Nico Williams wrote:
> I'd like to use LyX + git (or some such VCS) to cooperatively edit
> documents. This requires a diff/merge tool that is LyX-aware and can
> result in LyX documents that contain diffs that users can merge
> manually.
99 matches
Mail list logo