Sharing liquid history

[Martin Geisler]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> First, Sorry for being a bit harsh and arrogant in the other mail.
> It's kind automatic, when anyone start talking about liquid, people
> get excited about all the cool stuff we can do with them and forget
> that still don't have the basic brick. I would like most energy to
> focus on defining an implementation of local hg.

Yes, I know you want to save the discussion for later, but it is not
clear to me that this is the right way to go. I feel that the thing that
should drive the discussion is the sharing of volative changesets since
that is the interesting part.

So far my though has been to use push and pull almost like today, but
with the exclusion of abandoned (dead) heads. [I much prefer the name
"abandoned head" over "dead head"].

In that world, people can edit their changesets as they want and keep
publishing new versions with the understanding that the server will
accumulate more and more abandoned heads.

If people have pulled something and a subsequent pull makes their work
abandoned, then they would have to manually rebase/transplant their
changesets over to another head.

I think that is fine for a start. A later version could help the user by
providing hints in the abandoned head about why it is abandoned. Hints
could be of the form:

  new preferred head is a44fcc

which tells a smart hg that the parent of the abandoned head has been
replaced by a44fcc. Any local descendents of the abandoned head should
thus be rebased on top of a44fcc.

> The most basic solution is to use a bookmark to transmit information
> about which branch of liquid changeset replace which branch of liquid
> changeset. This is the way git works and would work out of the box in
> HG once we have liquid changeset. However this force the use of
> bookmark and require some kind of garbage collecting or dead head
> usage. This solution is simple and works well if everyone works in
> it's own nice and independant branch without messing up changeset used
> by other people bookmark.

I also like this simple approach.

> The only way to gracefully handle concurrent modifications of liquid
> changes are to store a rich history of modifications made to them. The
> same we need vcs history to handle changes made to files. We need an
> history to handle changes made to changeset.

I don't believe we can do this in a comprehensive and user-friendly way.
That is why I like the simplicity of simply saying that you mark
changesets as abandoned as needed or that you consider all
non-bookmarked liquid changesets as candidates for garbage collection.

Those two mechanisms are simple to understand and still provides us with
the power we need: the ability to change things locally and push the
changes to a remote server, knowing that future clones and pulls will
see the new version only.

In my opinion, trying to solve the problem of automatic merging of edits
to the history will complicate things too much.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/