A case for read-only narrow checkouts as subrepositories

Tony Mechelynck antoine.mechelynck at gmail.com
Mon Aug 16 02:35:39 UTC 2010


On 15/08/10 23:04, Patrick Mézard wrote:
> Le 14/08/10 03:34, Mads Kiilerich a écrit :
>>   Patrick Mézard wrote, On 08/14/2010 02:53 AM:
>>> Le 14/08/10 01:54, Mads Kiilerich a écrit :
>>>>    Patrick Mézard wrote, On 08/13/2010 07:42 PM:
>>>>> Mads suggested on IRC that the projects could be split in two mercurial repositories, one containing the lib/ part and another including it and everything else. While I agree it may solve my problem it does not look like a correct solution but a workaround for the lack of narrow checkouts in Mercurial.
>>>> For the record, I see it the opposite way. Using narrow checkouts would be a workaround for not having structured the repository correctly.
>>>>
>>>> I can imagine different reasons for using subrepos, but I think that singling out a subset that can be reused in different contexts (and thus is different) is one of the better.
>>> So in this case, would you say I should split the projects into two repositories, one for the lib and another one containing the library and everything else?
>>
>> Yes, I think so, or in other words: split each project up into an outer repo with its lib in a subrepo that can used in other contexts.
>>
>>> It's not compelling to me because while the lib may be reused as such somewhere else, the "everything else" would still be strongly related to it.
>>
>> Ok. But it seems like lib each lib also to some extent is "strongly related" with other projects.
>>
>>> For instance, if I have to backout one feature in the lib I would like to backout the related tests at the same time. Having them in different repositories will make this much harder.
>>
>> I think that that indicates that the tests for the lib should be the lib repo.
>
> If you assume the repository is correctly structured, you can extend this arguments to "everything else", including its dependencies, and we are back to square one. Besides, my projects are structured like every other C# projects I know (and similarly to most C projects as well), which makes it hard to argue this is not a just a Mercurial issue.
>
> --
> Patrick Mézard
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

Well, you need the libs to build the programs which use them but not 
vice-versa; and you need the tests (as a validation test at the end) 
when building the libs, but not necessarily vice-versa. However the 
tests are probably not useful in other contexts; so I suppose you might 
keep the tests together with the libs, not going to the (conceivable) 
luxury of having stll another tests' repo inside the libs'; but you 
might reasonably want a clone of the libs' repo kept inside the 
programs' but separate, maybe as an "hgignore"d subfolder, where the 
Makefile target for building the programs in the outer repo would 
descend and trigger a pull -u for the inner repo as a prerequisite.

Best regards,
Tony.
-- 
SIGIRO -- too much irony (core dumped)



More information about the Mercurial mailing list