[GSoC] Partial Cloning

Martin Geisler mg at lazybytes.net
Sat Apr 3 13:53:52 CDT 2010


Rafael Goncalves Martins <rafael at rafaelmartins.eng.br> writes:

> On 16:51 Sat 03 Apr     , Dirkjan Ochtman wrote:
>> On Sat, Apr 3, 2010 at 05:13, Rafael Goncalves Martins
>> <rafael at rafaelmartins.eng.br> wrote:
>> > - Nallow clones
>>
>> Not sure if this is a typo: it's called 'narrow'. :)
>
> Wow... My mistake! :)

Heh, I think this should be the official name for when you have a clone
that is both shallow and narrow :-)

>> And what are you going to about (allow for) hg merge?
>
> My initial idea is teach mercurial to only merge files inside the
> subtree, or at least blocks the merge if some file outside the subtree
> is confliting.

If you don't have the files outside your narrow subtree, then how can
you know if they are conflicting?


I've only through briefly about this, but it seems to me that you can
merge two revisions in a narrow clone when you know that all revisions
on the path back to their common ancestor are also "narrow". Meaning
that nothing outside of your subtree was changed.

Call the subtree that we have cloned S, and the rest R. You can then
think of each changeset as having two components: the S-component that
change when you make commits and the R-component that stays constant.
The R-component is constant since you cannot change things outside of
your subtree. So you can merge things when the R-component is the same:

                        [S2, R0]
                       /        \
  [S0, R0] --- [S1, R0]          [S4, R0]
                       \        /
                        [S3, R0]

Buf if you pull in changes you can get in trouble. Here you have pushed
[S1, R0] to the world and you pull [S2, R1] back in:

                        [S2, R1]
                       /        \
  [S0, R0] --- [S1, R0]          ?
                       \        /
                        [S3, R0]

Here you wouldn't know how to merge [S2, R1] with [S3, R0] since you
don't know the R1 and R0 parts.On the other hand, you can pull in
changes to the R-component and you can easily merge:

                        [S2, R1]
                       /        \
  [S0, R0] --- [S1, R1]          [S4, R1]
                       \        /
                        [S3, R1]

In the second care above, one could imagine that one would instead do a
rebase to turn the graph into:

  [S0, R0] --- [S1, R0] --- [S2, R1] --- [S3', R1]

whereby the changes from S1 to S3 are applied to S2.

Does this make sense?

-- 
Martin Geisler

Fast and powerful revision control: http://mercurial.selenic.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100403/ad316d6f/attachment.pgp>


More information about the Mercurial-devel mailing list