Re: browse verisons idea

[Steve Franks <franks rudbek com>]

> 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.
>

Afraid I'm just a CVS guy.  I think CVS branches are more or less yet
another instance of a point that looks like an expansion in the tree
gui, but I concede that other VC's could easily break that paradigm.
Must be the reason I've never branched anything.  I suppose it's not
the branch, it's the de-branching or re-branching (merging?  how
confusing is that?) that would make the tree look more like a
spiderweb, and there's certainly no gui I know that would handle that.
 Still, I'm not a power user, any CVS hierarchy that strictly followed
a treeshape would be really cool to view in a tree gui for me, however
99% of the time all I do is compare the working copy with head, which
meld does beautifully now...

Best,
Steve