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