Problem using subrepos

[Scott Palmer]

On Thu, Jun 2, 2011 at 8:00 PM, Mads Kiilerich <mads at kiilerich.com> wrote:

> Scott Palmer wrote, On 06/02/2011 06:26 PM:
>
>  On 2011-06-02, at 9:25 AM, Mads Kiilerich wrote:
>>
>>  "Doctor, doctor, it hurts when I use subrepos with non-trivial mappings".
>>> "Well, then don't do that!"
>>>
>>> (Ok, other mappings than trivial relative x=x mappings can work just fine
>>> if Mercurial is used in a 100% centralized model without any distributed
>>> cloning or pulling - but then why use Mercurial?)
>>>
>>> /Mads
>>>
>> I think it is important to find a solution other than trivial mappings for
>> this.  There are times when you want a common library to be shared by
>> otherwise unrelated modules, and while there are alternative solutions to
>> this, the (potential) subrepo solution is intuitive.
>>
>
> I have no doubt that you have valid use case, but I don't understand how
> you can be so sure up front that "trivial mappings" is the wrong solution.
> It (and subrepos in general) might be incomplete, but that's a different
> story.


Well currently "trivial mappings" is not a solution because is doesn't solve
the problem of sharing common code - it leads to unintentional forking of
the shared code.  The code stops being "common". In the trivial mapping case
subrepos are hardly different than not using subrepos at all and just having
a normal managed folder in their place.  They offer a slight partitioning of
the code so that it can be shared in a manner that really creates a fork.
There is nothing tying the forks together in the sense that they are much
different from having the anonymous branches that you mention below. A great
deal more effort is required to keep them synchronised.


>  E.g. Project A and B both want to use Library C, but it needs to be
>> extended to meet their needs.  Both A and B will make a repo that pulls in C
>> as a subrepo.  They will both simultaneously be working on changes that
>> affect the library C and the project they are using it with.  Since C is a
>> shared library they will obviously want to share the changes with each other
>> to ensure they aren't duplicating effort or breaking each other's code.
>>  There are many ways to do this, but if they do share a common repo to
>> push/pull their changes it will at least make them aware that they aren't
>> the only one working on C.
>>
>
> Well ... only if they watch what is going on in the other anonymous
> branches and update/merge with what the other team is doing and commits a
> new .hgsubstate.


Of course... but isn't that at least one way to use Mercurial in general
when working with a small team in the same office on a closed source project
where we aren't randomly getting patches from Joe User?



>  This is the solution that arises from using an absolute path to C in the
>> .hgsub file.  It works okay most of the time.  But there are the usual
>> benefits of the distributed model that they are missing out on.  They could
>> realize some of those benfits if clones of their A+C and B+C repos could be
>> made in the usual manner and those clones didn't unexpectedly push C
>> directly back to the "central" server while pushing the unshared A or B
>> project to it's natural parent repo.
>>
>> This has been brought up in the past and I've seen a few interesting
>> suggestions for allowing it to work, but I'm not sure if there is any
>> consensus on a solution or desire to get it done by the core Mercurial dev
>> team.
>>
>
> There is no consensus on what the solution should be, and the only thing
> that is known is that if we choose the wrong solution we will have to
> support it forever anyway.
>

I totally understand.


>
> It is however getting more and more clear to me that the only thing that is
> known for sure is where the subrepo should be "mounted" and what revision it
> should be updated to. The advantage of trivial mappings is that they don't
> say more than that, and .hgsubstate thus says it all. That is thus all that
> should be tracked in the outer repository.
>

I see your point.  Though it implies that subrepos simply don't work well
for sharing code.  At least not without a lot of special care.  Maybe that's
just all there is to say about that, or maybe there is a reasonable solution
that has eluded us thus far.


> Mercurial is a DVCS where clones can be cloned locally, and as this thread
> shows it is a valid expectation that this applies to repositories with
> subrepositories too. It follows from how subrepositories lives "in place" in
> both "source" and "target" repositories that this location also is the
> natural location to look for subrepositories. (Ok - trivial mappings also
> says that.)
>

I agree with that... but it's missing the one piece that ties together
shared code. As you say, "the trivial mapping is incomplete"...  a subrepo
of shared code now needs a *lot* of manual intervention to keep it shared.
The clones in subrepos become a bunch of forks, one for each master repo, of
what was once a shared library.

In most cases I'm trying to avoid subrepos and use a dependency manager
(Maven, Ivy, etc.) to avoid this problem entirely.  I suspect that in a
distributed model that is the best way to go, because subrepos just don't
mean the same thing as Subversion's svn:externals. (And they probably
shouldn't if it can't stay simple and intuitive.)

I believe I'm talking myself out of the whole idea of using subrepos in the
vast majority of cases where I had thought I would.


Cheers,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110602/5d19a3f0/attachment.htm>