[GSoC] Partial Cloning

Rafael Goncalves Martins rafael at rafaelmartins.eng.br
Sat Apr 3 16:30:17 CDT 2010


On 21:23 Sat 03 Apr     , Martin Geisler wrote:
> 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 :-)

Heheh... this could be fun... :)

>>> 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?
>

For sure! This is basically what I have in mind, but I haven't explained well
and I haven't the same experience of you with the mercurial internals (yet :-)
We'll really need to pull the changes in the files outside the subtree
(R-component in your example) to do the merge.

This approach is the best for me so far. I'm sure that I'll find some
difficulties during the implementation, but that's the more consistent way
that I can see.

Thanks for your ideas and your drawings. Were very useful for me.

Best regards,

-- 
Rafael Goncalves Martins
http://rafaelmartins.eng.br/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100403/119f06c0/attachment.pgp>


More information about the Mercurial-devel mailing list