Am 08.10.2010 um 14:06 schrieb Pavel Sanda:
> sw...@lyx.org wrote:
>> Author: switt
>> Date: Fri Oct 8 07:40:16 2010
>> New Revision: 35575
>> URL: http://www.lyx.org/trac/changeset/35575
>>
>> Log:
>> add implementation for CVS::checkOut
>
> few comments...
>
>>
>>
>> string CVS::checkOut()
>> {
>> - // cvs update or perhaps for cvs this should be a noop
>> - // we need to detect conflict (eg "C" in output)
>> - // before we can do this.
>> - lyxerr << "Sorry, not implemented." << endl;
>> - return string();
>> + // to be sure we test it again...
>> + if (!checkOutEnabled())
>> + return string();
>
> why we are not sure here? we should be consistent in all routines.
Because it is not sure if the checkout is enabled when doing the checkout.
You test the enabled state when the menu is used.
You cannot know the time difference from opening the menu and the begin of the
checkout.
If somehow there is an "checkout" done already in the meantime you are in
trouble.
That's what I want to avoid.
>> +
>> + int ret = doVCCommand("cvs -q edit "
>> + +
>> quoteName(onlyFileName(owner_->absFileName())),
>> + FileName(owner_->filePath()));
>
> i would like to understand the usecase here.
> shouldn'be there some unedit in the commit case?
No, the commit restores the readonly state.
But you can use cvs unedit to drop your local uncommited changes.
This I didn't want to implement in revert() because I didn't want to assume the
average user is working like me. But perhaps it as a good alternative. I have to
think about that.
> this mimicks locking in order to avoid conflicts?
Not in our case. You may implement that on the server side.
We only want to avoid the change of some file unintentionally.
As a bonus you can query the list of the current editors with "cvs editors".
It's possible to edit some file by multiple editors and to commit the changes.
But the second user has to use "cvs update" before "cvs commit".
That's the case anyway. And is currently not supported with LyX.
Stephan
