Am 17.02.2016 um 20:58 schrieb Pavel Sanda <sa...@lyx.org>:
>
> Scott Kostyshak wrote:
>> On Tue, Feb 09, 2016 at 07:34:04PM -0800, Pavel Sanda wrote:
>>> Scott Kostyshak wrote:
>>>> Regarding #9940, why does VCS need to do something special for
>>>> buffer-toggle-read-only ?
>>>
>>> Read-only status is currently connected with locking features of VCS
>>> (RCS,SVN, maybe CVS, not git).
>>
>> Regarding the following code:
>>
>> case LFUN_BUFFER_TOGGLE_READ_ONLY:
>> if (lyxvc().inUse()) {
>> string log = lyxvc().toggleReadOnly();
>> if (!log.empty())
>> dr.setMessage(log);
>> }
>> else
>> setReadonly(!isReadonly());
>> break;
>>
>> Ideally, what do we want to happen? Is the idea that if the VC handles
>> locking then we ask it to lock the file, which will mark the file as
>> read only at the OS level, which LyX will see and then mark the buffer
>> as read only? Seems overly complicated to me, but that's probably
>> because I never used SVN much.
>
> It's messy now, but historically it goes back to RCS (which by the way is
> still preferred by me for simple lyx files - it just creates single .lyx,v
> next to your file without creating any mess in directories around).
>
> There check-in and check-out is directly connected with read-only status
> of the file and lyx was initially coded to recognize its VCS status via
> read-only status of the .lyx file, not parsing .lyx,v. That works perfectly,
> there is no need to distinguish these two.
>
> Then came CVS/SVN. I won't comment on CVS, Stephan is expert here, but
> in SVN you can 'lock' the file so other contributors do not interfere,
> while you are editing your chapter or whatever (my best experience
> when it comes to cooperate on book/paper with non tech people and avoid
> merge conflicts).
> So you have two states: file is(/not) under locking feature and
> if under locking next two states (locked/unlocked) - kind of identical
> situation to RCS for that case. You don't want to allow to mess with
> read-only status of the file if under locking. You might allow readonly
> status changes if not under locking but you enter dark territory since
> you have to think through the transitions possible...
>
> Then came git. I never checked it has locking, but I wouldn't expect
> it due to its decentralized philosophy. So here the connection between
> locking and readbility is zero and could be fixed more easily compared
> to SVN.
>
> As a summary I see more approaches:
> 1. Stay with current architecture and hack it little bit so readonly
> status change is allowed only for git (and maybe CVS?) case.
> 2. Decouple ui read only and file read-only status.
> 3. Decouple file locking and locking status internally used by VCS.
> Would need parsing of internal structures and handling possible
> mess when those two conflicts and its transitions.
>
> IMHO you don't wann go 3; 2 seem to be robust but might need to rethink
> whole logic of toggling we have now; 1 should be doable with little
> bit of testing that you haven't screwed other than git VCSs.That’s all true. With CVS you can work like RCS and let CVS set the file to read-only on check-in and read-write on check-out. This is the mode I prefer and this works with LyX VCS logic too. I’d go with 1 and made a patch to demonstrate it. A cleaner solution would move the NOLOCKING handler into the VCS base class by adding a virtual member method toggleReadOnly() there. Stephan
vcs.patch
Description: Binary data
