Initially Read Only vs. REAL Read-Only
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
Menu
▾
▴
#1238 Initially Read Only vs. REAL Read-Only
Winmerge is a very nice and useful tool.
Thats why i was very pleased to read in the RFE that
the topic "READ ONLY for use in CVS System" was
discussed several times and solved with the parameters
-wl and -wr.
When I tried this out i was "a bit" disappointed !
-wl and -wr set the files "initially" to read-only, but it
is possible to change them to normal edit mode
by one or two mouse clicks in the menu.
What is needed for CVS is a REAL read-only that is not
changeable.
Perhaps someone does not agree with me, thats why i
made 2 new parameters -xl and -xr.
They set the mode to read only AND also disable the
read-only menu. Thus we got a REAL read only mode.
I made a new File-Flag
FFILEOPEN_MENURODIS = 0x0004, /**< Menue ReadOnly
disable */
and 2 Properties (for Menu-Disable)
bool bMLDis ;
bool bMRDis ;
Changes were made in 4 files and they are marked with
// ### LH
For detailed changes look in the attached files.
ChangesForRealReadOnly
Logged In: YES
user_id=631874
Moving to patch list.
What is the point? If user wants to alter files, one can
start whatever editor or notepad to do so. WinMerge cannot
protect files from changes. Read-only can only protect from
accidental changes, and if user disables read-only from
menu, changes are intentional after that.
Logged In: YES
user_id=1106418
Hi kimmov,
i totally agree with you:
WinMerge cannot protect files from changes. Read-only can
only protect from accidental changes ...
=========
These accidental changes can be minimized be deactivating
the menu.
Logged In: YES
user_id=1195173
> These accidental changes can be minimized be deactivating
the menu.
I don't understand this.
It seems to me that the menu doesn't allow accidental
editing, it only allows deliberate editing.
Are you afraid the user will accidentally go to the menu and
change the file to be not read-only?
That doesn't sound very accidental to me. How can you
accidentally go to the menu and do that?
Logged In: YES
user_id=1195173
> What is needed for CVS is a REAL read-only that is not
changeable.
I think we need to expand more on what concept we're trying
to model here (at least, I'm not sure if I understand it --
below I take a guess).
Are you trying to differentate between files that are
attributed readonly on disk and files that the user who
invoked WinMerge *really* doesn't want to change? Therefore,
you want to make these files (that the user *really*
doesn't want to change) harder to change than ones merely
marked read-only on the disk?
Logged In: YES
user_id=1106418
OK, I give up ...
if you can't think of any situation
that makes sense for these parameters,
ignore my message.
I will keep the changes in my version.
Logged In: YES
user_id=1195173
You didn't answer my question about whether or not I am
correctly guessing your scenario; instead you said you give
up. It is difficult for me to do anything but also give up :)
Logged In: YES
user_id=631874
This read-only screnario is something we have to think about.
Its a real scenario that user has files one wants to
compare, but not merge. Now, one might ask if WinMerge is
best too for that. But if thats just occasional usage, or
for certain files or something like that, then we should
have some way for help users.
Disabling menuitems is not good way to solve it. Its a aid,
but not a solution.
One possible direction with this (and some other problems)
might be moving towards 'profiles' for usage. Profile would
be something like set of options, optional project file,
maybe filter(s) etc.
But that's new concept we'd need to discuss in forum first.
And not likely to happen soon anyway.
Logged In: YES
user_id=1106418
Sorry for that !
Now I will explain the comlete scenario, that i am afraid of.
Therefore it is important to know , that I want to use the
CVS for
Mircosoft Visual FoxPro.
In contrast to "normal" sourcecode files,
Visual FoxPro SourceCode is stored in FoxPro tables
(rather similar to DBase tables).
To use CVS in FoxPro there are "helper" programs,
that convert the code stored in those tables to plain text
files.
If I compare different version, I compare that textfiles ...
Now i am afraid, that one of my colleges, that is not so
familiar
with this mechanism, transfers codelines from one text file
to another
- thinking that this has any effect on the sourcecode -
but that would have NO effect !
He has to change the code in the Visual FoxPro editor as
only that changes the code in that tables.
This is why I definitely want to forbid changes within WinMerge
when it is started from the Visual FoxPro CVS environment.
Hope this is some kind of explanation for you ...
Logged In: YES
user_id=1195173
Ok, I've been thinking not to long ago, that we should
disambiguate uses of our "readonly" status, and this tends
to encourage me in this direction.
In fact, maybe this discussion should now or soon be moved
to forums.
I think we should differentiate between these (existing &
future possibilities):
- readonly attribute on file on disk
- non-writeable file due to permissions (except, unlikely
we know)
- user specifically asked for readonly
- binary file display (ie, lossy display, so saving a bad idea)
- any lossy transform results (ie, thru plugins) (so saving
a bad idea)
The fourth case came to me when I wrote recently the patch
to display text files with binary zeros, because I needed
that to use WinMerge to help me diff such files. The fifth
case is of the nature of the fourth.
The first four cases are each in some nature different, so I
think we optimally would (in the future) at least record
somehow for which reason we mark the file readonly.
Logged In: YES
user_id=1195173
BTW, your Lutz, your user might still want to save changes.
I suggest that because I was recently using WinMerge to
resolve differences in SQL Server databases. I was running
WinMerge against schema and data text files dumped out, so
obviously any merges I did with WinMerge were meaningless in
the original context (they didn't really change either
database), but, they helped me proceed in my merging:
(a) I could merge the files after I made the real changes
in the databases, thereby optimizing by skipping the step of
again dumping the schema and text files
(b) I could merge the files when I determined that the
differences were unimportant, and I wanted to not see them
anymore
Logged In: YES
user_id=631874
Lutz, thanks for describing your use case. Thats a real case
we should handle better, no question about that. Actually I've
sometimes been in similar situation but already totally forgot
that.
I think important question here is how this READONLY mode
should be activated. Commandline switches are mostly
useful when using WinMerge as external compare/merge
tool. Yes, its possible to use them via different shortcuts too,
but why bother with that?
Total READONLY actually makes sense when using
WinMerge as external tool. Files may be checked out from
some system, given as translated temp files or some such.
Modifying those files may have ill or unexpected effects (lost
changes). Or, system may track changes and be able to
update files according changes.
In first scenario (edit is harmful) we should not allow editing
files. For latter case we should allow editing.
And only way to differentiate these cases is via different
startup options (read commandline flags).
I still don't like disabling menuitems (user has no clue why
those items are disabled). And, user can use Open-dialog to
re-open same files and lose this READONLY status.
One way could be to set that TOTAL READONLY via
commandline switch, say /X. If that swithc is given, started
WinMerge instance assumes all files (even new ones opened
via Open-dialog) are READONLY, no changes allowed.
See also RFE #1081620 Allow readonly comparison as
default
https://sourceforge.net/tracker/index.php?
func=detail&aid=1081620&group_id=13216&atid=363216