> Meld is great because it allows to edit the diff that is shows. Features for > browsing history have a different workflow from how Meld works right now, > and need a different GUI.
I have to dis-dis-agree. The point is that for the source-control user, it's *not* different at all, and why everything has to be a special case is quite beyond me. The backend is different between wether the thing you are 'expanding' in the tree is a folder or a file with multiple revisions, and Vincent has already stated the backend is the easy part. The front end concept (i.e. I want to compare 'this file' (foo.1.2.c) with 'that file' (foo.1.7.c)) is no different (i.e. I want to compare foo.c with bar.c). IIRC there are even filesystems that support this at the shell-level. As far as I'm concerned, if we're not going to show the revisions before HEAD, we're not really supporting source control; which is fine; there are plenty of diff tools out there with no pretense of source-control awareness at all. I was about to start writing shell scripts to integrate kdiff with cvs when I found meld, which is really much nicer than any hack.sh I'm going to cook up... There's no reason the existing functionality isn't fine - you click on a file, it compares the working copy with head. I just thought the 'natural' extension of this idea was to expand the line on the tree where the working copy is listed to show HEAD, 1.7, 1.6, 1.5, etc.... as files below the working copy. Clearly the range of human experience allows for this to be very 'unnatural' for some instead, and refreshingly so, I suppose. I really must travel abroad...(or perhaps to the local secondary school - they probably think my thought process is as alien as anyone ;) Best, Steve _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
