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

[Fred Wulff]

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
>