mercurial 1.5 sprint was nice

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Mon Feb 8 09:30:43 CST 2010


On Mon, Feb 8, 2010 at 3:57 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> I hope that someone will post and share the most important outcome with the
> crowd. New things you learned? New insight and conclusions from discussions?
> New directions and priorities?

What I took away for my own queue is below. Others please chime in
with your info.


== Incoming/Outgoing ==

Near term we can teach incoming to stop reading after it's read the
changelog. Also add a flag that tells the server to only send the
changelog (incoming w/o -b and -p).

Also near term we want to let the server check immediately whether it
knows all the client's heads to speed things up.

Longer term, people agree I should continue with my approach for
incoming/outgoing discovery with fewer roundtrips. Current prototype
work is in: http://bitbucket.org/parren/dag-discovery/


== Partial Clones ==

Narrow clones (only a subset of files) seem fairly straightforward. We
will always clone the entire manifest, though.

Shallow clones are more tricky. We have a plan, which I need to write
up on the wiki. It is a hybrid of punching and history truncation. It
will work offline, but allow explicit deepening of history. We want to
tackle punching of accidentally committed sensitive material at the
same time.


== Test Scripts and DAGs ==

We might eventually switch to test scripts that interleave commands
and expected output for easier reading. Also serves as basis for
tutorials that contain testable examples (literate testing). See also:
http://markmail.org/thread/qmzex3xhh4d353lg

Am adding helpers for tests to concisely create complex DAGs. Quick
example (which can be condensed to a single line):

+3         # 3 nodes in linear run
:forkhere  # a label for the last of the 3 nodes from above
+5         # 5 more nodes on one branch
:mergethis # label again
<forkhere  # set default parent to labelled fork node
+10        # 10 more nodes on a parallel branch
@stable    # following nodes will be annotated as "stable"
+5         # 5 nodes in stable
!addfile   # custom command; could trigger new file in next node
+2         # two more nodes
/mergethis # merge last node with labelled node
+4         # 4 more nodes descending from merge node


== pbranch ==

We found a nice way to reorder branches (patches) in pbranch using the
new rebase --detach. Need to implement this in pbranch.

Integration of pbranch with Steve Losh's code review thing looks promising.

Integration of pbranch with lbranch or overlays could allow one to
easily switch between multiple pbranch instances (for reviewers, for
instance).

MQ/pbranch/attic/... integration did not have liftoff.


Cheers,
-parren


More information about the Mercurial-devel mailing list