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