GNOME Bugzilla – Bug 321637
Read-only file handling
Last modified: 2012-12-24 00:30:52 UTC
Meld allows hunks to be transferred from writable files into read-only files, then complains when you try to exit. It would be nice to have the option to disallow editing on such files. This could be as a preference for all r/o files and/or a commandline to mark a particular file as non-editable regardless of file permissions.
What use case do you have to mark an editable file as non-editable?
Sorry about the delay replying. Actually, just noticing that some of the files/directories don't have write permission would probably be enough. In my particular case, I'm trying to interface with Perforce. There are two options here: either invoke meld (actually a shell script around meld) as perforce's external merge tool. In this case P4 provides four files: a common ancestor, the clashing version, your version, and the output file (initially equal to your version) which will be accepted. The first three it makes read-only. Obviously the wrapper script can only pass two of the others to meld to provide a 3-way diff. And P4 repeats this process for each individual file in a checkin. The other case I have is my own script which attempts to do something similar on the entire current working directory by extracting info from the repo and making /tmp copies of everything it needs. I can make the various versions read-only if necessary, but in fact there is an additional feature which I believe is already reported as a separate bug which is the ability to label arguments. Ideally I'd like to be able to explicitly mark on the command line: This file/dir (and all the files in it) is to be labelled "Original", and is read-only; This file/dir is to be labelled "Final" and is writeable; This file/dir is to be labelled "Theirs" and is read-only. That gives the most flexibility. (I'm quite fascist about SCM interfacing: I really don't like doing anything unless I know *exactly* what is going to result, which means being able to tell each component in the chain at least once what I expect it to be doing. Safety first or there's no point in using one.) But just noticing read-only files and forbidding edits would be cool.
You can now specify labels on the command line. Meld also shows a different icon for nonwritable files. There is still no logic to prevent changes to the buffer though.
I'd really like this as well. When scm merge utilities invoke 3-way merges, they always have two of the files as temporary files (the "basis" version and the "other" version) which were grabbed from the SCM tool simply to allow the merge tool to have the right file contents to work on. Those are temporary files and editing them is useless, even if they are writable. It would be really, really nice, and alleviate much confusion, if meld could have some files marked as non-modifiable, so that changes could only be made to the modifiable files.
*** Bug 689790 has been marked as a duplicate of this bug. ***
Just some quick further notes on this. Merge mode already works this way. If one of the files is set to be non-editable, merging into that file is disabled, and other actions are adapted accordingly. As it stands, having a read-only file does *not* set a file to be non-editable; merge mode does this manually. The reason for this is that some people find it useful to be able to edit individual files to better understand a merge. One option would be to provide a UI toggle for whether a given pane is editable or not. This should be very easy --- almost trivial --- to code, but UI-wise we don't have anywhere sensible to put it, and it's going to look bad.
If this is personal taste dependent, you can make it an option and have it both ways. It is very confusing when meld offers to edit file in the repository. By default it should reflect what the situation is, explicitly read-only, and as an option it can be made like today. In fact, file selection box over the versioned file currently displays something like this: /tmp/tmpVCOwzb-meld/my-file.tcl It should say: subversion rev.NNNNN (/tmp/tmpVCOwzb-meld/my-file.tcl) Should be explicitly clear. And don't allow user to change this choice like you allow today. It is always possible to make combobox uneditable when particular choice is made. Also, this bug is up from 2005. I think it is a good policy when bug becomes the highest priority after certain time. Say, critical release blocker after 3 years. Otherwise, how many years can such bug drag on?
I'd appreciate it if you could adjust your tone. Please consider that as the maintainer, *I know all this already*. Your suggestion would give us about 50 release blocking bugs, several of which require significant rewrites of various modules. As such, I can't imagine there would ever *be* another release. There is currently exactly one person (me) working on Meld's code base on a semi-regular basis, and a couple of additional people making very much appreciated, but still occasional, commits. This bug will 'drag on' until someone gets time to work on it. Feel free to be that someone. (Apologies to other people being bugzilla-CCed.)
Sorry for this, there is no way I could know how many people are on the meld project. Bugzilla doesn't have such field yet ;-) BTW, in general bug response time has no relation to how many resources are allocated on the project. Example is Apple llvm project having all manpower in the world and still some patches (ready to apply patches !) aren't applied for months and months. And they go stale and require additional work after a while.
Read-only files are now not editable by default; there is a toggle to enable editing of read-only files. Changes are in HEAD.