On Wed, Feb 17, 2016 at 02:37:42PM -0800, Pavel Sanda wrote: > Stephan Witt wrote: > > > 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. > > What I like about this patch is that it remains contained within git VCS and > there is no need to test whether we broke other VCSs, therefore if you tested > it works with git it has my +1.
I tested and it fixes the bug for me. It is not ideal to have buffer code call vcs code that calls a buffer function, but the patch is indeed simple which is nice so I'm fine with it. Scott
signature.asc
Description: PGP signature
