Non recursive update with subrepo's
Paul Nathan
pnathan at vandals.uidaho.edu
Thu Jan 30 15:32:26 UTC 2014
On 1/30/14 5:18 AM, Kastner Masilko, Friedrich wrote:
>> From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Raphael Sebbe
>>
>> My argument here is that there is another scenario, let call it "Daily
>> Development", in which developers work on each repo and want to handle
>> themselves the versions of each repo/subrepo (full control). However,
>> in that use-case, whenever the parent repository is pulled/updated, it
>> also updates the subrepo, which is cumbersome because developers have
>> to go through each of the subrepo to update them back to the tip. That
>> "Daily Development" scenario of not updating subrepo when updating
>> parent repo is not possible at all in Mercurial (couldn't find options
>> for it), yet it's the most common one for us.
>
> I use this "daily development" scenario every day at work, and it is no problem at all. Mercurial will just recognise the changed subrepos as dirty working-copy (as it should), and "merge" the new update-version into the working-copy if the standard update-and-merge strategy is applicable.
>
> Do you perhaps use "-C" all the time?
>
> Regards,
> Fritz
>
Part of what you propose has the side-effect of occasionally causing
merges to occur in the subrepos as the parent repos branches merge.
This is not always desirable from a development standpoint (I can go
into the scenarios why you wouldn't want it!).
An extension exists for when you don't want this behavior -
https://bitbucket.org/selinc/guestrepo (I help maintain this extension,
so it's a bit of a plug. :-) ). I personally believe that Guestrepo
solves the problem Raphael has quite nicely.
--
Regards,
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 946 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140130/9c28d541/attachment.asc>
More information about the Mercurial
mailing list