> 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 _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
