[GSoC] Partial Cloning

[Martin Geisler]

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

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

Heh, I just have a conceptual view of this, I'm not very familiar with
the details.

> We'll really need to pull the changes in the files outside the subtree
> (R-component in your example) to do the merge.

Wouldn't it be better to require people to rebase their changes? When
rebasing, you will effectively be merging the S components (S2 with S3
in the second drawing above) and you can ignore the other stuff.

If a narrow clone is meant to save you disk space and bandwidth, then it
seems to me that you don't want to download the rest of the repository
to do a 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.

Thanks, I hope I can help. But you should also get input from the other
crew members who have likely thought more about this...

-- 
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/bbbb98ff/attachment.pgp>