Uwe Brauer wrote:
"rgheck" == rgheck
<[EMAIL PROTECTED]> writes:
> Uwe Brauer wrote:
>>
>>
> LyX has included interfaces to vc for some time, and the new
> version will extend the backends that can be used from rcs and cvs
> to svn and even git, I believe. More could be added fairly simply.
>> but I think to simplify scientific collaboration a
>> wikipedia/mediwiki solution would be much more intuitive.
>>
>>
> Why? "Intuitive" is a pretty subjective term. Perhaps what you want
> is something transparent, so it isn't possible not to "check in"
> what you've done. But I'm not sure that is a good idea. Maybe I
> want to play around with my local copy.
There are two issues here:
- one is the learning curve. Even with this simplified interface I
don't think me colleagues would be willing to learn version
control.
Yes, I agree with part of this. You have to start outside LyX, by
setting up the appropriate sort of version control, unless you want to
use rcs. It would be nice if LyX could make this a bit
easier---something like, "check out new repository"---when there already
exists such a thing somewhere. And that is really the hard part: There
needs to be such a repository that all the people working on the
document can access. So someone needs to set that up. But this too isn't
terribly hard, now that we have things like github.com to play with.
- how to submit the new version. Usually that would be done my
email then the new version is saved, loaded etc. Not a very good
solution, while a webbased solution would lock the file when
somebody is working, which I would prefer...
This is just the vcs three-step: check out, edit, check in. And
actually, you do NOT want the file to be locked. Do you really want not
to be able to work on section 1 because your buddy is working on section
2? Note that this is precisely the problem vcs solves.
Here again, what LyX does not have (yet) is support for
conflict-resolution within LyX. If you and your buddy edit section 2 at
the same time and he checks in before you do, then your check-in will
fail, and you'll have to go outside LyX to resolve the problem. And if
you do an update, you could (I think) end up with a document LyX could
not open---though, if you were lucky, you'd just get markers in the text
showing where the conflicts were. So this is definitely a shortcoming of
our vcs support, but it could be addressed, if someone wanted to do it.
> No. I suppose it could be done, but it would be a huge amount of
> work.
That I was afraid of. It reminds me of the hen/egg problem. Not very
many people miss such a software, but once it is there...(like with
wikipedia)
No, it's not so much that. I could be wrong, but it seems to me like
doing this would involve writing a whole new program, more or less. And
really making LyX VC-friendly seems to me as if it would be a superior
solution.
Richard
