Any intent to support the concept of thread with inheritance in Mercurial or derivatives?

[Jens Alfke]

My take on this is that the AccuRev guy is using some sleight-of-hand  
in his comparison of development processes. There are as many merges  
going on in the AccuRev scenario as with Mercurial/Git/etc. The  
difference is that they're being done automagically by the software,  
to propagate changes between repositories in the tree.

This makes sense only if you trust the ability of the software to  
merge revisions without introducing regressions in any repository.  
Fred's examples show that this isn't feasible unless the software is  
nearly as intelligent as the developers on your team, a goal that's  
probably at least five years away (and has been since 1960 ;-)

On 1 Jan '08, at 10:13 PM, Fred Wulff wrote:

> One thing that this suggests that might be helpful, though (and I
> don't know if there is functionality in mercurial for this already),
> is making connections between repositories more first class citizens.
> There's already at least vaguely the concept of a parent repository
> (the one that hg pull and push default to). Perhaps we could have
> multi-level pushes and pulls (or even some utility to graphically
> traverse and modify a tree of these repositories)?

Yes, that would be extremely useful. I worked at Sun briefly, years  
ago, and their version control system (I think it's called TeamWare?)  
had such a tree structure, making it very straightforward to push the  
code around.

For the most part, IIRC, each repository remembered its parent and  
could push to or pull from that parent. Mercurial already has this.  
But it might be useful to add the ability of a repository to remember  
other sets of repositories that it could push to / pull from.

--Jens