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

Wed Jan 2 11:24:32 CST 2008

Thanks Fred for this very good overview of the problem.  I can see why 
automating replication from parent can cause problems.  I wonder if 
anyone has experience with AccuRev and can share their experience, but 
that may not be the best list for that.

Thanks again.

-Pierre

Fred Wulff wrote:
> Hi Pierre,
> 
> I've never actually used AccuRev, and I'm not a Mercurial developer
> (well, I've played around with it, but I'm not in the commit logs). So
> take my analysis with a grain of salt - I'd be particularly interested
> in hearing from somebody who's actually used AccuRev. I gained my
> knowledge of AccuRev mainly from their article at:
> http://www.accurev.com/whitepaper/stream_based_architecture.htm
> 
> The concept of streams as I understand it is as follows: within a
> project (particularly within a corporate project), you typically have
> a number of parallel branches of development. These include major
> ones, such as a stable tree that corresponds to previous releases +
> backpatches and the current development trunk, as well as minor ones,
> such as the private branches for developers to work on tasks. In the
> AccuRev formulation, each stream basically corresponds to a Mercurial
> repo: it has the history of all the files in it and identifies the
> current version of the files.
> 
> This, in and of itself, is used pretty widely in the Mercurial
> community: for instance, mercurial and mercurial-crew are repositories
> that serve this kind of arrangement. Where AccuRev tries to add
> something is by adding a concept of migrating changesets between
> streams. The idea is that you could set it up so that updates
> automatically propagate from stable streams to more experimental
> streams, but if the more experimental stream has changes to the file
> that's propagating, it keeps the modified version. Now, there are a
> couple of problems with this, some unique to what appears to be the
> AccuRev implementation and some of which are endemic to the concept.
> 
> The first problem is that AccuRev appears to define its fundamental
> unit as an "element" - a file or directory. Linus is a much more
> entertaining ranter than I am, so I'll let you look up his shtick on
> why file versioning is evil, but it does bring us to one of the bigger
> problems with the system.
> 
> Let's say you work on "a.cpp" and "b.cpp", while your friend Phil is
> working on "b.cpp" and "c.cpp". (You're working on your genius
> edutainment game to teach kids the alphabet and C++ simultaneously.)
> You commit a.cpp and b.cpp, it works fine, and you push it back to a
> stream that is a parent of Phil's. Under AccuRev, it appears that
> a.cpp would be updated in Phil's working copy (since he hasn't touched
> it) while b.cpp wouldn't (because he has). This can obviously be
> problematic if a.cpp and b.cpp are interdependent.
> 
> Mercurial's fixed the file-based problem in the general case, so we
> could say that we'll make the atomicity of propagation between the
> streams a single changeset. This fixes the case we talked about, but
> what if your change is actually two changesets, the first of which
> only touches a.cpp and the latter of which touches both a.cpp and
> b.cpp? Then Phil will automatically pull the first but not the second.
> Since mercurial/agile practices encourage committing often and there
> isn't a really good way to merge changesets, it may well be that the
> first changeset is broken without the second.
> 
> Even if we assume no user error, what if you change the interface to a
> function in a.cpp and need to modify its clients? If Phil adds a new
> client to that function in c.cpp (and doesn't touch a.cpp), whenever
> your update propagates, his code will break. Of course, this could
> happen now when he pulls the update, but if Phil is practicing good
> SCM hygiene, he'll do that when he can isolate the pull as the problem
> and investigate what caused the break. Any automation we add to that
> will likely make Phil's job of tracking down the breakage harder.
> 
> 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)? The forest
> extension does some of this, but my understanding is that it's more
> concerned with directory-based repo divisions than with different
> streams in the AccuRev sense.
> 
> -Fred
> 
> On Jan 1, 2008 10:43 PM, Pierre Rouleau <prouleau001 at gmail.com> wrote:
>> Mark A. Flacy wrote:
>>> On 2008.01.01 21:48, Pierre Rouleau wrote:
>>>> Hi all,
>>>>
>>>> I recently stumbled on an article describing the capabilities of
>>>> AccuRev
>>>>   inheritable threads ( http://www.daveonscm.com/ ).
>>>>
>>>> The article describes how AccuRev's streams simplifies the
>>>> branching/merging work.
>>> Nice as long as you don't have multiple "tasks" touching the same files.
>>>
>>>
>> I am not that familiar with AccuRev and the facilities that its threads
>> offer.  However, the thread system with its concept of inheritance,
>> seems a good idea to replicate info automatically.  They have different
>> types of threads with different behaviours related to what is allowed to
>> change.
>>
>> I am assuming that the changes allowed in the parent would be under
>> control.  Something someone would have to do anyway when pulling changes
>> from several other repositories.
>>
>> However, if there were any 'children' repository to that single 'parent'
>> repository, no explicit pull/update would be required: maybe just an
>> update or something.
>>
>> Have you (anyone) worked with AccuRev or any other SCM that support the
>> concept of inheritance with streams?
>>
>> --
>>
>> Pierre Rouleau
>>
>>
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
>>