A case for read-only narrow checkouts as subrepositories

[Patrick Mézard]

Here is an attempt to migrate away from subversion and possibly a strong case for simplified read-only narrow checkouts as subrepositories.

Current situation
=================

I have 4 projects in svn with the following layouts:

projA/stuff_and_tests
     /lib

projB/stuff_and_tests
     /lib
     /libA => svn:externals projA/lib at rA1

projC/stuff_and_tests
     /lib
     /libA => svn:externals projA/lib at rA2

projD/stuff_and_tests
     /lib
     /libB => svn:externals projB/lib at rB1
     /libC => svn:externals projC/lib at rC1
     /libA => svn:externals projA/lib at rA3

The svn:externals properties are defined at project roots. When projD references projB/lib, it only brings projB lib/ directory, not projB externals. But to be built, libB needs to see libA, so projD adds its own reference to projA/lib at rA3. Obviously there is no reason for A3 to be the same than A1 or A2, what's necessary is the libraries to build and work as expected, and we make it so that compiling is good enough.


Question
========

How do I migrate that from subversion to mercurial? I assume there are no conversion problems, except for the externals.


S1: Convert every project with hgsubversion and use subrepos directly
==

Remember that mercurial does not support "narrow checkouts". So here is what projD would look like:

projD/stuff_and_tests
     /projB at rB1/stuff_and_tests
               /lib
               /projA at rA1/stuff_and_tests
                         /lib
     /projC at rC1/stuff_and_tests
               /lib
               /projA at rA2/stuff_and_tests
                         /lib


How does it compare to the svn version?

* projB and projC are not built against the same projA version. I don't like it even if I don't know if it is worse than picking one projA version explicitely. Could there be cases where different projA versions would lead to valid builds with runtime errors? It seems less likely in the single projA version case.

* If size(projA) >> size(projA/lib) then it's wasting a lot of space. It might not look important on this 4 projects example, but double the number of dependencies and add one depth level and things start looking bad.

* I don't control where the lib/ directories are checked out anymore. My current build script requires them to be on the same directory level. We can blame my build system, but in this case, subversion flexibility is just better.


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.

Am I doing it wrong?

What do you think of supporting some kind of [hgreadonly] subrepository type made of the complete original repository store and a checkout of one of its directory (file?) subtree?

Supporting update and status for the subtree should be enough to implement the required subrepository class.

--
Patrick Mézard