Re: browse verisons idea
- From: Andrew Beyer <beyer andrew gmail com>
- To: meld-list <meld-list gnome org>, Steve Franks <franks rudbek com>
- Subject: Re: browse verisons idea
- Date: Tue, 14 Apr 2009 15:11:14 -0700
On Tue, Apr 14, 2009 at 1:44 PM, Steve Franks <franks rudbek com> 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]