A case for read-only narrow checkouts as subrepositories
Patrick Mézard
pmezard at gmail.com
Sun Aug 15 21:04:25 UTC 2010
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
More information about the Mercurial
mailing list