On Tue, Apr 14, 2009 at 1:44 PM, Steve Franks <[email protected]> wrote: > IIRC there are even filesystems > that support this at the shell-level.
Exactly, that was my point...its done already that way. If you use such a system, then meld's existing file browser will do precisely what you are asking for without any changes. > 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; Again, the functionality already exists...off the shelf without any configuration, "hg extdiff -p meld --rev 1.0 --rev 1.2.1" gives me the difference between arbitrary revisions. That's mercurial, but other VC systems I've worked with provide similar features. If you do it from a gui VC client, you get a navigation interface too. (And one that is likely better suited to your VC system than a one-size-fits-all solution.) > there are plenty of diff tools out there with no pretense > of source-control awareness at all. Ultimately, that seems like a good goal, at least as far as distribution of code. There has been some talk about using the anyvc library for the VC interface in meld, and I think that or something like it is a good idea. There is no reason every diff tool (and IDE, bugtracker, etc...) should reimplement from scratch an interface to every different VC...it seems much better to push common VC functionality into a library that abstracts over the different systems. > There's no reason the existing functionality isn't fine - you click on > a file, it compares the working copy with head. I meant the interoperation of meld with VC based filesystems or gui clients which provide navigation and diff'ing arbitrary revisions that already do what you want. If there are interoperability problems, those should be addressed. > Clearly the range of human > experience allows for this to be very 'unnatural' for some instead, I personally have never found GUIs particularly useful for VC, so don't typically use them, but know plenty who do. I don't think anyone is saying that yours is an 'unnatural' request, or that it isn't useful. My point was simply that I don't think that adding a special purpose feature to meld is the way to achieve what you want to do, and that solutions exist that do it today. Of particular concern to me would be dealing with branching and merging. The simple case of a list of sequential changes could be implemented pretty easily, but branching can get pretty hairy even just dealing with one VC system, and is an area that different systems take very different approaches to. At the moment meld doesn't have to deal with these issues at all, and I believe there is not any branching related code in the VC interfaces. I'm worried that a generic solution would quickly become useless for nontrivial cases, or would become a huge mass of code trying to deal with how different VCs view branches, and in the end not being a perfect fit anywhere. This is the type of thing I see as being better done in a tool tied more closely to a specific VC system, or pushed into an abstraction library that deals with this outside meld. _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
