Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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 running out of ideas which email could it be.

If someone could reset my passwd and sent it to this email sparing me
creating new account?


Sincerely,
Gour 

-- 
Even a man of knowledge acts according to his own nature, for 
everyone follows the nature he has acquired from the three modes. 
What can repression accomplish?

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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 running out of ideas which email could it be.

If someone could reset my passwd and sent it to this email sparing me
creating new account?


Sincerely,
Gour 

-- 
Even a man of knowledge acts according to his own nature, for 
everyone follows the nature he has acquired from the three modes. 
What can repression accomplish?

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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 am running out of ideas which email could it be.

If someone could reset my passwd and sent it to this email sparing me
creating new account?


Sincerely,
Gour 

-- 
Even a man of knowledge acts according to his own nature, for 
everyone follows the nature he has acquired from the three modes. 
What can repression accomplish?

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 might want to comment on that one / cc as well.

 
 After deciding to use LyX as the tool for writing manual for software
 application which will be kept under DVCS (not git, but most probably
 Fossil), I just wonder what are your experiences with different diff
 tools?
 
 In one blog post, I saw that Emacs' ediff was much better thant e.g
 KDiff, Vim's diff...
 (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
 but considering that so far I only keep my own docs under DVCS, I'm
 interested what one can expect when diff-ing LyX documents in order to
 try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 might want to comment on that one / cc as well.

 
 After deciding to use LyX as the tool for writing manual for software
 application which will be kept under DVCS (not git, but most probably
 Fossil), I just wonder what are your experiences with different diff
 tools?
 
 In one blog post, I saw that Emacs' ediff was much better thant e.g
 KDiff, Vim's diff...
 (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
 but considering that so far I only keep my own docs under DVCS, I'm
 interested what one can expect when diff-ing LyX documents in order to
 try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 might want to comment on that one / cc as well.

> 
> After deciding to use LyX as the tool for writing manual for software
> application which will be kept under DVCS (not git, but most probably
> Fossil), I just wonder what are your experiences with different diff
> tools?
> 
> In one blog post, I saw that Emacs' ediff was much better thant e.g
> KDiff, Vim's diff...
> (http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
> but considering that so far I only keep my own docs under DVCS, I'm
> interested what one can expect when diff-ing LyX documents in order to
> try to provide merge of changes?

line based diff works poorly out of the box with justified latex paragraphs as 
noted in that blog. This problem is actually somewhat less severe with lyx 
since it automatically breaks lines after every period in the text and where 
any change of formatting occurs. In my experience I have found built-in diff 
merge with git works perfectly well. If you want more fine grained display of 
differences (the patches will be the same) see e.g.:

http://idnotfound.wordpress.com/2009/05/09/word-by-word-diffs-in-git/

I imagine fossil may have a similar option to --color-words.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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 conversions to XHTML that are reasonably faithful (more on
 that some other time), but there's no XML-LyX converter.

I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
interesting.

After deciding to use LyX as the tool for writing manual for software
application which will be kept under DVCS (not git, but most probably
Fossil), I just wonder what are your experiences with different diff
tools?

In one blog post, I saw that Emacs' ediff was much better thant e.g
KDiff, Vim's diff...
(http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
but considering that so far I only keep my own docs under DVCS, I'm
interested what one can expect when diff-ing LyX documents in order to
try to provide merge of changes?

I also wonder whether XML-based format would be better than the present
one in such scenario?

Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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 conversions to XHTML that are reasonably faithful (more on
 that some other time), but there's no XML-LyX converter.

I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
interesting.

After deciding to use LyX as the tool for writing manual for software
application which will be kept under DVCS (not git, but most probably
Fossil), I just wonder what are your experiences with different diff
tools?

In one blog post, I saw that Emacs' ediff was much better thant e.g
KDiff, Vim's diff...
(http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
but considering that so far I only keep my own docs under DVCS, I'm
interested what one can expect when diff-ing LyX documents in order to
try to provide merge of changes?

I also wonder whether XML-based format would be better than the present
one in such scenario?

Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Gour]

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
> supports conversions to XHTML that are reasonably faithful (more on
> that some other time), but there's no XML->LyX converter.

I read the whole thread and http://www.lyx.org/trac/ticket/8440 looks
interesting.

After deciding to use LyX as the tool for writing manual for software
application which will be kept under DVCS (not git, but most probably
Fossil), I just wonder what are your experiences with different diff
tools?

In one blog post, I saw that Emacs' ediff was much better thant e.g
KDiff, Vim's diff...
(http://rvb.mytanet.de/comparing-latex-files-with-latexdiff.shtml)
but considering that so far I only keep my own docs under DVCS, I'm
interested what one can expect when diff-ing LyX documents in order to
try to provide merge of changes?

I also wonder whether XML-based format would be better than the present
one in such scenario?

Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 command or decrypt 
whatever comes from git
in case of conflict :)

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:)

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

 what would be more important for my workflow is the ability to do merges by a 
 functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 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 conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML-LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML-.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.
 But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 command or decrypt 
whatever comes from git
in case of conflict :)

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:)

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

 what would be more important for my workflow is the ability to do merges by a 
 functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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
 in case of conflict :)
 
 One solution would be to detect merge conflicts and call our diff algorithm 
 for the different versions.

that is exactly what I had in mind

 This would be beautiful but an order of magnitude harder to implement (surely 
 not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) pull (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)
 
 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.
 
 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

 But Ok, we don't agree here, let is sleep.

OK!

 what would be more important for my workflow is the ability to do merges by 
 a functional diff in lyx.
 
 This is the key point and I recommend that you add some comment or 
 CC-yourself in bug #6889
 to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 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 conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML-LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML-.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

 if you wanted to have bare bones support for git in lyx you would need
 * commit (saving your changes)
 * push (share your work)
 * pull (fetch changes and merge with your work)

 I know what I need, but the question was about your workflow.
 In particular, does it make sense in your case to automatically push after 
 commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

 After testing out the existing svn implementation I think this is actually 
 simpler to automatically merge with git than to lock files with svn.

 Maybe more powerful, but simpler? I have hard time to understand how 
 resolving merge conflicts is _simpler_ than automatical locking part of the 
 document you work on.
 But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 command or decrypt 
whatever comes from git
in case of conflict :)

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:)

> if you wanted to have bare bones support for git in lyx you would need
> * commit (saving your changes)
> * push (share your work)
> * pull (fetch changes and merge with your work)

I know what I need, but the question was about your workflow.
In particular, does it make sense in your case to automatically push after 
commit?

> After testing out the existing svn implementation I think this is actually 
> simpler to automatically merge with git than to lock files with svn.

Maybe more powerful, but simpler? I have hard time to understand how resolving 
merge conflicts is _simpler_ than automatical locking part of the document you 
work on.
But Ok, we don't agree here, let is sleep.

> what would be more important for my workflow is the ability to do merges by a 
> functional diff in lyx.

This is the key point and I recommend that you add some comment or CC-yourself 
in bug #6889
to indicate that this bug hunts more people and add it more importance...

Cheers,
Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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
> in case of conflict :)
> 
> One solution would be to detect merge conflicts and call our diff algorithm 
> for the different versions.

that is exactly what I had in mind

> This would be beautiful but an order of magnitude harder to implement (surely 
> not me:)

I don't think it is that hard. The SVN VCS support already in git offers the 
option to fetch remote changes and then the option to do something about 
conflicts if they exist (at the moment, just keep local or remote). 

for git this would mean 
1) "pull" (presumably if the current branch is a tracking branch)
2) if the merge is successful then just reload the buffer
3) if it fails (and there are clear signals from git when this is the case)
  diff the local and remote documents _inside_ lyx to give some tracked changes 
that the user then needs to accept/reject.

That really doesn't strike me as that hard to implement (iff the diff did 
something useful).

>> if you wanted to have bare bones support for git in lyx you would need
>> * commit (saving your changes)
>> * push (share your work)
>> * pull (fetch changes and merge with your work)
> 
> I know what I need, but the question was about your workflow.
> In particular, does it make sense in your case to automatically push after 
> commit?

For us, push on commit is fine. We basically try to pull immediately before 
starting to make changes and push as soon as possible afterwards. This way we 
very rarely have trouble. However, I think some would prefer to wait to push 
until they had accumulated a few related changes, so it would be nicer if a 
design allowed this. Looking a little bit at the existing VCS class and the 
toolbar, I guess there isn't immediately a way to support commit without push, 
because svn does not have that separation.

>> After testing out the existing svn implementation I think this is actually 
>> simpler to automatically merge with git than to lock files with svn.
> 
> Maybe more powerful, but simpler? I have hard time to understand how 
> resolving merge conflicts is _simpler_ than automatical locking part of the 
> document you work on.

when merging works (and this is 99% of the time for us) it is simpler. When 
there is conflict it is indeed much harder – and that is the problem that a 
functional diff in lyx could solve.

> But Ok, we don't agree here, let is sleep.

OK!

>> what would be more important for my workflow is the ability to do merges by 
>> a functional diff in lyx.
> 
> This is the key point and I recommend that you add some comment or 
> CC-yourself in bug #6889
> to indicate that this bug hunts more people and add it more importance...

Good point. I have now done so. Nico, I guess it might be good if you did the 
same. Pavel has already proposed a work around that looks relatively simple to 
implement and ought to reduce the number of changes significantly, so there is 
some chance that this will get picked up and improved. Ticket is here:

http://www.lyx.org/trac/ticket/6889

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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:)

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 conversions to XHTML that are reasonably faithful (more on
that some other time), but there's no XML->LyX converter.

I can't contribute much C++ code to LyX, but I could contribute XSLs
to do XML->.lyx conversion, if you point me at documentation on how
the .lyx format and the LyXHTML and XHTML export formats (specifically
what conventions are used to represent LyX elements in XHTML).

>> if you wanted to have bare bones support for git in lyx you would need
>> * commit (saving your changes)
>> * push (share your work)
>> * pull (fetch changes and merge with your work)
>
> I know what I need, but the question was about your workflow.
> In particular, does it make sense in your case to automatically push after 
> commit?

I don't want LyX to be in the business of being a git GUI, but if it
were going to be so we'd need either to always do git commit -a
(ouch), or git add the files LyX knows were touched (risky) then
commit those, or have a git add UI then git commit.  That's either
unsatisfying or a lot of work, so I'd rather LyX stay out of the git
UI business.

What I want is that if git (or whatever) has merged a .lyx file *with*
conflicts, then LyX should be able to display those such that a user
could fix them by normal editing operations in LyX.

>> After testing out the existing svn implementation I think this is actually 
>> simpler to automatically merge with git than to lock files with svn.
>
> Maybe more powerful, but simpler? I have hard time to understand how 
> resolving merge conflicts is _simpler_ than automatical locking part of the 
> document you work on.
> But Ok, we don't agree here, let is sleep.

Locking is simpler until you realize that it causes serious problems
(already discussed).

I don't want to stop you from locking.  I want the option to merge.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 managed to break a LyX file with an 
 inappropriate automated merge. Merge conflicts are obviously possible if 2 
 users edit the same piece of text but in our use very rare ? we encourage 
 frequent push/pull, avoid e.g. fixing spelling errors all across the document 
 without checking that changes have been committed and pushed. But on the rare 
 occasions when conflicts do happen they unfortunately a showstopper for most 
 users. It would indeed be very nice to have the option to merge in LyX when 
 this happens, when one would typically use git mergetool. However, I do note 
 that when a merge conflict happens, the file with conflicts left marked by 
 git's regular merge or what you typically get by using git mergetool to start 
 a generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
 means you only have to worry about the *conflicts* not the compatible changes 
 in each branch. So in these circumstances firing up a text editor to fix the 
 conflict might be much quicker (albeit more dangerous) than using LyX to 
 accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
 that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
 really what one is after.
 
 When I am working with less tech savvy people outside the lab, I usually tell 
 them to use track changes (and commit their work manually to git). You can 
 even consider asking people to use track changes when using a VCS if someone 
 is going to review all changes for integration. Regrettably there is still 
 the possibility of merge conflict even after the discussion/fix noted here:
 
 http://www.lyx.org/trac/ticket/6058
 
 if two or more people both start tracking changes before merging to master.
 
 Hope some of this experience might be of use.

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).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 merging.  Locking simply does not scale.  This is true even of
documents (as opposed to source code).

 While we are at possible LyX support of git, can you explicitly name the 
 commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

 I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
 immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

 To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
 SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 email exchanges of manuscript (locking exists by definition)
- only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
b)
- private document where VCS is used just to store history (just for sure)

In such world even knowing what merging or branching means qualifies
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 were:
 a)
 - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

 - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

 - only subset of people are IT-aware while the others are capable at
   most of push the red button to commit the change and unlock the
   given chapter.
 b)

Again, merging is not hard.

 In such world even knowing what merging or branching means qualifies
 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 about :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
 button, push green button and I know what I'm talking about :)


Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(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 not scale.  This is true even of
 documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper
 - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

 - only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
 b)
 - private document where VCS is used just to store history (just for sure)
 
 In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for branches aka different 
versions of the same document, which is a related idea.

 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so git in LyX would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 managed to break a LyX file with an 
 inappropriate automated merge. Merge conflicts are obviously possible if 2 
 users edit the same piece of text but in our use very rare ? we encourage 
 frequent push/pull, avoid e.g. fixing spelling errors all across the document 
 without checking that changes have been committed and pushed. But on the rare 
 occasions when conflicts do happen they unfortunately a showstopper for most 
 users. It would indeed be very nice to have the option to merge in LyX when 
 this happens, when one would typically use git mergetool. However, I do note 
 that when a merge conflict happens, the file with conflicts left marked by 
 git's regular merge or what you typically get by using git mergetool to start 
 a generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
 means you only have to worry about the *conflicts* not the compatible changes 
 in each branch. So in these circumstances firing up a text editor to fix the 
 conflict might be much quicker (albeit more dangerous) than using LyX to 
 accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
 that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
 really what one is after.
 
 When I am working with less tech savvy people outside the lab, I usually tell 
 them to use track changes (and commit their work manually to git). You can 
 even consider asking people to use track changes when using a VCS if someone 
 is going to review all changes for integration. Regrettably there is still 
 the possibility of merge conflict even after the discussion/fix noted here:
 
 http://www.lyx.org/trac/ticket/6058
 
 if two or more people both start tracking changes before merging to master.
 
 Hope some of this experience might be of use.

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).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 merging.  Locking simply does not scale.  This is true even of
documents (as opposed to source code).

 While we are at possible LyX support of git, can you explicitly name the 
 commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

 I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
 immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

 To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
 SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 email exchanges of manuscript (locking exists by definition)
- only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
b)
- private document where VCS is used just to store history (just for sure)

In such world even knowing what merging or branching means qualifies
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 were:
 a)
 - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

 - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

 - only subset of people are IT-aware while the others are capable at
   most of push the red button to commit the change and unlock the
   given chapter.
 b)

Again, merging is not hard.

 In such world even knowing what merging or branching means qualifies
 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 about :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
 button, push green button and I know what I'm talking about :)


Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(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 not scale.  This is true even of
 documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

 Conditions I had in mind were:
 a)
 - small team working on e.g. scientific paper
 - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

 - only subset of people are IT-aware while the others are capable at
  most of push the red button to commit the change and unlock the
  given chapter.
 b)
 - private document where VCS is used just to store history (just for sure)
 
 In such world even knowing what merging or branching means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for branches aka different 
versions of the same document, which is a related idea.

 you as someone who really does not need LyX to manipulate version tracking
 and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so git in LyX would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 managed to break a LyX file with an 
> inappropriate automated merge. Merge conflicts are obviously possible if 2 
> users edit the same piece of text but in our use very rare ? we encourage 
> frequent push/pull, avoid e.g. fixing spelling errors all across the document 
> without checking that changes have been committed and pushed. But on the rare 
> occasions when conflicts do happen they unfortunately a showstopper for most 
> users. It would indeed be very nice to have the option to merge in LyX when 
> this happens, when one would typically use git mergetool. However, I do note 
> that when a merge conflict happens, the file with conflicts left marked by 
> git's regular merge or what you typically get by using git mergetool to start 
> a generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
> means you only have to worry about the *conflicts* not the compatible changes 
> in each branch. So in these circumstances firing up a text editor to fix the 
> conflict might be much quicker (albeit more dangerous) than using LyX to 
> accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
> that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
> really what one is after.
> 
> When I am working with less tech savvy people outside the lab, I usually tell 
> them to use track changes (and commit their work manually to git). You can 
> even consider asking people to use track changes when using a VCS if someone 
> is going to review all changes for integration. Regrettably there is still 
> the possibility of merge conflict even after the discussion/fix noted here:
> 
> http://www.lyx.org/trac/ticket/6058
> 
> if two or more people both start tracking changes before merging to master.
> 
> Hope some of this experience might be of use.

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).
Comparison tool is used merely to watch/check history (integrated with VCS 
already).
If there is need to check changes by the other author, changes are committed in 
change-tracking mode
while the other author accepts those changes.

While we are at possible LyX support of git, can you explicitly name the 
commands used for your workflow?
I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
immediatelly after commit?)
To me, git concepts are unnecessarily complicated and tools like GNU RCS or SVN 
are better suited for document tracking.


Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
and merging.  Locking simply does not scale.  This is true even of
documents (as opposed to source code).

> While we are at possible LyX support of git, can you explicitly name the 
> commands used for your workflow?

Like any team workflow:

 - each team member must be able to work on their changes independent
of the rest of the team, even when the changes overlap

This requires support for merging.

I've been thinking about this a fair bit and I think there's a number
of possible strategies to computing a 3-way diff suitable for merging
with manual conflict resolution.  Here's my stab at low-disruption (to
LyX source, that is) strategy:

1. export each of the two or three LyX document versions as XML, using
a schema that is as direct a representation of LyX document structure
as possible
2. apply an XSL to change the schema to a document structure that is
deeper (nested sections, ...)
3. apply an XML diff algorithm that looks for additions/deletions of
nodes, node *moves*, and node changes
4. apply an automatic merge algorithm to the base version using the
diffs from (3)
5. apply an XSL to flatten the document structure
6. convert the result back to .lyx format
7. present the result to the user for manual conflict resolution

Of these the only difficult (magical) step is (4), and that's probably
only because I've not researched it well enough.

> I'm also interested for criteria for commit/push/merge/pull (e.g. do you push 
> immediatelly after commit?)

I have several different workflows.  The most common one is to create
a branch as a copy of master, do a bunch of work there, then pull and
update master, rebase my branch, repeat until done, then send a pull
request.  Another workflow is to maintain a branch that is a merger of
several feature branches, which I use until all those feature branches
are merged upstream.

> To me, git concepts are unnecessarily complicated and tools like GNU RCS or 
> SVN are better suited for document tracking.

I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase,
PRCS, fossil, git, and others), and I find none as powerful or awesome
as git.  I understand why many find git hard to understand, but I
don't think this is as much git's fault as it is that distributed,
lock-less version control is inherently hard, but also the only game
in town (see above comment about locking not scaling).

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 email exchanges of manuscript (locking exists by definition)
- only subset of people are "IT-aware" while the others are capable at
  most of "push the red button" to commit the change and unlock the
  given chapter.
b)
- private document where VCS is used just to store history ("just for sure")

In such world even knowing what "merging" or "branching" means qualifies
you as someone who really does not need LyX to manipulate version tracking
and who will stay happily with specialized software or command line :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 in mind were:
> a)
> - small team working on e.g. scientific paper

I believe merging is easier than locking, even for small teams.  The
alternative is dealing with someone locking a file then going on
vacation -- you can break the lock, but either they lose their work
or... they have to merge.

Merging is *not* hard provided there's a way to display the conflicts.
 Displaying conflicts usefully can be really hard for some data, such
as LyX documents, but only due to the lack of suitable tools.

> - avoid endless email exchanges of manuscript (locking exists by definition)

This is true whether you use git or SVN.

> - only subset of people are "IT-aware" while the others are capable at
>   most of "push the red button" to commit the change and unlock the
>   given chapter.
> b)

Again, merging is not hard.

> In such world even knowing what "merging" or "branching" means qualifies
> you as someone who really does not need LyX to manipulate version tracking
> and who will stay happily with specialized software or command line :)

You don't need to know what branching is.  You do need to know what
merging is, but it's not hard.

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 about :)

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
> button, push green button" and I know what I'm talking about :)
>

Anyone who would use track changes can merge.  In any case, a merge
capability would be huge.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

(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 not scale.  This is true even of
>> documents (as opposed to source code).

I definitely agree with Nico. Even for a small group, concurrent editing and 
automatic merging is a major productivity boost. For example we are in the 
final stages of finishing a manuscript. More often than I care to admit it's 
late in the evening and we're saying: I'll do the intro, A do the methods, B 
fix the problems in supplemental, C check the figure/table references.

> Conditions I had in mind were:
> a)
> - small team working on e.g. scientific paper
> - avoid endless email exchanges of manuscript (locking exists by definition)

there really isn't a way to lock in git so this is out

> - only subset of people are "IT-aware" while the others are capable at
>  most of "push the red button" to commit the change and unlock the
>  given chapter.
> b)
> - private document where VCS is used just to store history ("just for sure")
> 
> In such world even knowing what "merging" or "branching" means qualifies
I think the idea of merging is pretty obvious – after all you can merge changes 
in Word but it's harder and much more involved/error prone than doing with git.

if you wanted to have bare bones support for git in lyx you would need
* commit (saving your changes)
* push (share your work)
* pull (fetch changes and merge with your work)

After testing out the existing svn implementation I think this is actually 
simpler to automatically merge with git than to lock files with svn.

I admit that branching seems more complex and one could pass on branch handling 
for a basic git in lyx implementation. But branching (and then merging those 
branches) are super easy with git and I have been surprised at the takeup by 
people in my lab who are really not that techie. I used subversion for several 
years and almost never branched (and dealing with merges was nasty). Branch 
(and merge) in git was a revelation.

Incidentally LyX itself already has support for "branches" aka different 
versions of the same document, which is a related idea.

> you as someone who really does not need LyX to manipulate version tracking
> and who will stay happily with specialized software or command line :)

However, I think it is true that there are lots of good external tools for git 
so "git in LyX" would be nice (and it would stop me making the occasional 
mistake of not saving and closing my lyx doc before commiting/pushing/pulling) 
but what would be more important for my workflow is the ability to do merges by 
a functional diff in lyx.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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, invoke 
 latexdiff and then generate the marked-up PDF (which is what you get with 
 latexdiff) would work. For latexdiff there are already scripts to handle 
 git revisions which should allow one to diff a pair of arbitrary revisions 
 in a git repository.
 
 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.
 
 Right, the goal is to merge LyX documents.  Unless converstion to/from
 LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

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 managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

http://www.lyx.org/trac/ticket/6058

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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, invoke 
 latexdiff and then generate the marked-up PDF (which is what you get with 
 latexdiff) would work. For latexdiff there are already scripts to handle 
 git revisions which should allow one to diff a pair of arbitrary revisions 
 in a git repository.
 
 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.
 
 Right, the goal is to merge LyX documents.  Unless converstion to/from
 LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

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 managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

http://www.lyx.org/trac/ticket/6058

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 versions to latex, invoke 
>>> latexdiff and then generate the marked-up PDF (which is what you get with 
>>> latexdiff) would work. For latexdiff there are already scripts to handle 
>>> git revisions which should allow one to diff a pair of arbitrary revisions 
>>> in a git repository.
>> 
>> This should work, but it would be really nice if these changes were on LyX 
>> level and that one could
>> save a file LyX file containing the differences as tracked changes.
> 
> Right, the goal is to merge LyX documents.  Unless converstion to/from
> LaTeX is loss-less this is not a solution.

Just to clarify (since it was apparently not clear) my suggestion re latexdiff 
was specifically about change *comparison* not merging (though I had admittedly 
wondered about the possibility of a round trip via latex). But for me seeing 
changes in context is half the battle!

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 managed to break a LyX file with an 
inappropriate automated merge. Merge conflicts are obviously possible if 2 
users edit the same piece of text but in our use very rare – we encourage 
frequent push/pull, avoid e.g. fixing spelling errors all across the document 
without checking that changes have been committed and pushed. But on the rare 
occasions when conflicts do happen they unfortunately a showstopper for most 
users. It would indeed be very nice to have the option to merge in LyX when 
this happens, when one would typically use git mergetool. However, I do note 
that when a merge conflict happens, the file with conflicts left marked by 
git's regular merge or what you typically get by using git mergetool to start a 
generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That 
means you only have to worry about the *conflicts* not the compatible changes 
in each branch. So in these circumstances firing up a text editor to fix the 
conflict might be much quicker (albeit more dangerous) than using LyX to 
accept/reject all changes displayed in a 2 way diff. In some sense a strategy 
that turned conflict markers into LyX tracked changes (or a 3 way diff) is 
really what one is after.

When I am working with less tech savvy people outside the lab, I usually tell 
them to use track changes (and commit their work manually to git). You can even 
consider asking people to use track changes when using a VCS if someone is 
going to review all changes for integration. Regrettably there is still the 
possibility of merge conflict even after the discussion/fix noted here:

http://www.lyx.org/trac/ticket/6058

if two or more people both start tracking changes before merging to master.

Hope some of this experience might be of use.

Best,

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

 But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 using latexdiff for change comparison in not merging? 
 Presumably a small script to export both versions to latex, invoke latexdiff 
 and then generate the marked-up PDF (which is what you get with latexdiff) 
 would work. For latexdiff there are already scripts to handle git revisions 
 which should allow one to diff a pair of arbitrary revisions in a git 
 repository.

This should work, but it would be really nice if these changes were on LyX 
level and that one could
save a file LyX file containing the differences as tracked changes.

To see what has changed in the text, the latexdiff approach surely would work.

Rainer


 
 http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
 http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/
 
 But a compare tool from commandline would be exceedingly useful for VCS.
 
 +1.
 
 Greg.
 


- -- 
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 :   +33 - (0)9 58 10 27 44

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

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDB2uIACgkQoYgNqgF2egq9LwCfa/TeLxPRGKYbFYo6pKGcN3FD
vA0AoIrbSvb9cIlhYNFraEMZ9nxqZjKC
=vzhT
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 marked-up PDF (which is what you get with latexdiff) 
 would work. For latexdiff there are already scripts to handle git revisions 
 which should allow one to diff a pair of arbitrary revisions in a git 
 repository.

 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.

Right, the goal is to merge LyX documents.  Unless converstion to/from
LaTeX is loss-less this is not a solution.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

 But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 using latexdiff for change comparison in not merging? 
 Presumably a small script to export both versions to latex, invoke latexdiff 
 and then generate the marked-up PDF (which is what you get with latexdiff) 
 would work. For latexdiff there are already scripts to handle git revisions 
 which should allow one to diff a pair of arbitrary revisions in a git 
 repository.

This should work, but it would be really nice if these changes were on LyX 
level and that one could
save a file LyX file containing the differences as tracked changes.

To see what has changed in the text, the latexdiff approach surely would work.

Rainer


 
 http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
 http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/
 
 But a compare tool from commandline would be exceedingly useful for VCS.
 
 +1.
 
 Greg.
 


- -- 
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 :   +33 - (0)9 58 10 27 44

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

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDB2uIACgkQoYgNqgF2egq9LwCfa/TeLxPRGKYbFYo6pKGcN3FD
vA0AoIrbSvb9cIlhYNFraEMZ9nxqZjKC
=vzhT
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 marked-up PDF (which is what you get with latexdiff) 
 would work. For latexdiff there are already scripts to handle git revisions 
 which should allow one to diff a pair of arbitrary revisions in a git 
 repository.

 This should work, but it would be really nice if these changes were on LyX 
 level and that one could
 save a file LyX file containing the differences as tracked changes.

Right, the goal is to merge LyX documents.  Unless converstion to/from
LaTeX is loss-less this is not a solution.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Gregory Jefferis]

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 versions to latex, invoke latexdiff 
and then generate the marked-up PDF (which is what you get with latexdiff) 
would work. For latexdiff there are already scripts to handle git revisions 
which should allow one to diff a pair of arbitrary revisions in a git 
repository.

http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/

> But a compare tool from commandline would be exceedingly useful for VCS.

+1.

Greg.

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 using latexdiff for change comparison in not merging? 
> Presumably a small script to export both versions to latex, invoke latexdiff 
> and then generate the marked-up PDF (which is what you get with latexdiff) 
> would work. For latexdiff there are already scripts to handle git revisions 
> which should allow one to diff a pair of arbitrary revisions in a git 
> repository.

This should work, but it would be really nice if these changes were on LyX 
level and that one could
save a file LyX file containing the differences as tracked changes.

To see what has changed in the text, the latexdiff approach surely would work.

Rainer


> 
> http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
> http://eothred.wordpress.com/2010/11/07/latexdiff-and-git/
> 
>> But a compare tool from commandline would be exceedingly useful for VCS.
> 
> +1.
> 
> Greg.
> 


- -- 
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 :   +33 - (0)9 58 10 27 44

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

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDB2uIACgkQoYgNqgF2egq9LwCfa/TeLxPRGKYbFYo6pKGcN3FD
vA0AoIrbSvb9cIlhYNFraEMZ9nxqZjKC
=vzhT
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 the marked-up PDF (which is what you get with latexdiff) 
>> would work. For latexdiff there are already scripts to handle git revisions 
>> which should allow one to diff a pair of arbitrary revisions in a git 
>> repository.
>
> This should work, but it would be really nice if these changes were on LyX 
> level and that one could
> save a file LyX file containing the differences as tracked changes.

Right, the goal is to merge LyX documents.  Unless converstion to/from
LaTeX is loss-less this is not a solution.

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 
 vc-compare, which
 compares documents already in version control.
 
 Not part of the official API (so no guarantee for future) but at this moment 
 dialog-show
 compare run file1 file2 LFUN should work.
 
 Apart from the problems how to cram it into commandline, the bug #6889 is in 
 my experience
 quite limiting for real usage of LyX comparison tool.

I agree with this comment - I wanted to use the comparison tool for comparing 
two revisions, and
the result was simply unusable.

But a compare tool from commandline would be exceedingly useful for VCS.

Cheers,

Rainer

 
 Pavel
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDAUd8ACgkQoYgNqgF2egrpdACbBB3kBgYRcxDeclBe7ROL8xor
U8AAn1oZLLMDoFomJn2kcyfTYey1FcfX
=gUr7
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 
 vc-compare, which
 compares documents already in version control.
 
 Not part of the official API (so no guarantee for future) but at this moment 
 dialog-show
 compare run file1 file2 LFUN should work.
 
 Apart from the problems how to cram it into commandline, the bug #6889 is in 
 my experience
 quite limiting for real usage of LyX comparison tool.

I agree with this comment - I wanted to use the comparison tool for comparing 
two revisions, and
the result was simply unusable.

But a compare tool from commandline would be exceedingly useful for VCS.

Cheers,

Rainer

 
 Pavel
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDAUd8ACgkQoYgNqgF2egrpdACbBB3kBgYRcxDeclBe7ROL8xor
U8AAn1oZLLMDoFomJn2kcyfTYey1FcfX
=gUr7
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Rainer M Krug]

-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 
>> vc-compare, which
>> compares documents already in version control.
> 
> Not part of the official API (so no guarantee for future) but at this moment 
> "dialog-show
> compare run file1 file2" LFUN should work.
> 
> Apart from the problems how to cram it into commandline, the bug #6889 is in 
> my experience
> quite limiting for real usage of LyX comparison tool.

I agree with this comment - I wanted to use the comparison tool for comparing 
two revisions, and
the result was simply unusable.

But a compare tool from commandline would be exceedingly useful for VCS.

Cheers,

Rainer

> 
> Pavel
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDAUd8ACgkQoYgNqgF2egrpdACbBB3kBgYRcxDeclBe7ROL8xor
U8AAn1oZLLMDoFomJn2kcyfTYey1FcfX
=gUr7
-END PGP SIGNATURE-

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 (so no guarantee for future) but at this
moment dialog-show compare run file1 file2 LFUN should work.

Apart from the problems how to cram it into commandline, the bug #6889
is in my experience quite limiting for real usage of LyX comparison tool.

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 documents already in version control.

 Not part of the official API (so no guarantee for future) but at this
 moment dialog-show compare run file1 file2 LFUN should work.

 Apart from the problems how to cram it into commandline, the bug #6889
 is in my experience quite limiting for real usage of LyX comparison tool.

I see.  Also, I will really need a 3-way diff/merge...  Thanks.

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 (so no guarantee for future) but at this
moment dialog-show compare run file1 file2 LFUN should work.

Apart from the problems how to cram it into commandline, the bug #6889
is in my experience quite limiting for real usage of LyX comparison tool.

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 documents already in version control.

 Not part of the official API (so no guarantee for future) but at this
 moment dialog-show compare run file1 file2 LFUN should work.

 Apart from the problems how to cram it into commandline, the bug #6889
 is in my experience quite limiting for real usage of LyX comparison tool.

I see.  Also, I will really need a 3-way diff/merge...  Thanks.

Re: LyX document diff/merge tools for cooperative editing?

[Pavel Sanda]

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 (so no guarantee for future) but at this
moment "dialog-show compare run file1 file2" LFUN should work.

Apart from the problems how to cram it into commandline, the bug #6889
is in my experience quite limiting for real usage of LyX comparison tool.

Pavel

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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, which compares documents already in version control.
>
> Not part of the official API (so no guarantee for future) but at this
> moment "dialog-show compare run file1 file2" LFUN should work.
>
> Apart from the problems how to cram it into commandline, the bug #6889
> is in my experience quite limiting for real usage of LyX comparison tool.

I see.  Also, I will really need a 3-way diff/merge...  Thanks.

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 diffs that users can merge
manually.  Are there any such tools?  Thanks,


Have you looked into Document  Track Changes?


The problem is probably to see how to invoke that from command line.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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 argument?

Liviu

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 two LyX documents
using the --execute CLI argument?


Yes. Theoretically.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

What would the exact command-line invocation be?

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 request on bug tracker?


Yes, probably. I thinik this is not very difficult to implement, 
although I am not sure what the syntax should be (should buffers be 
loaded before? ...)


JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.

Thanks,

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 interaction, as the idea
is to use this as a merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.


Feel free to open it. The only problem will be to find someone who is 
interested in implemented it (this is probably easy).


JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 diffs that users can merge
manually.  Are there any such tools?  Thanks,


Have you looked into Document  Track Changes?


The problem is probably to see how to invoke that from command line.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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 argument?

Liviu

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 two LyX documents
using the --execute CLI argument?


Yes. Theoretically.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

What would the exact command-line invocation be?

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 request on bug tracker?


Yes, probably. I thinik this is not very difficult to implement, 
although I am not sure what the syntax should be (should buffers be 
loaded before? ...)


JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.

Thanks,

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 interaction, as the idea
is to use this as a merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.


Feel free to open it. The only problem will be to find someone who is 
interested in implemented it (this is probably easy).


JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 contain diffs that users can merge
manually.  Are there any such tools?  Thanks,


Have you looked into Document > Track Changes?


The problem is probably to see how to invoke that from command line.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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 CLI argument?

Liviu

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 diff two LyX documents
using the --execute CLI argument?


Yes. Theoretically.

JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

What would the exact command-line invocation be?

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 feature request on bug tracker?


Yes, probably. I thinik this is not very difficult to implement, 
although I am not sure what the syntax should be (should buffers be 
loaded before? ...)


JMarc

Re: LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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 merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.

Thanks,

Nico
--

Re: LyX document diff/merge tools for cooperative editing?

[Jean-Marc Lasgouttes]

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 interaction, as the idea
is to use this as a merge strategy for git and the like.

This would be extremely useful for distributed authoring/editing.  I'd
go farther and ask for a merge tool that can work like traditional
version control merge tools, only at the LyX layer, but this seems
likely to be very difficult, as opposed to existing change tracking
feature.

If you wish I can open the feature request.


Feel free to open it. The only problem will be to find someone who is 
interested in implemented it (this is probably easy).


JMarc

LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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 there any such tools?  Thanks,

Have you looked into Document  Track Changes?

Liviu

LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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 there any such tools?  Thanks,

Have you looked into Document  Track Changes?

Liviu

LyX document diff/merge tools for cooperative editing?

[Nico Williams]

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
--

Re: LyX document diff/merge tools for cooperative editing?

[Liviu Andronic]

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.  Are there any such tools?  Thanks,
>
Have you looked into Document > Track Changes?

Liviu