External Repositories as Subrepositories

Matthias Goesswein tisi at sbox.tugraz.at
Wed Nov 10 12:19:24 CST 2010


Am 10.11.2010 17:07, schrieb Mads Kiilerich:
> On 11/10/2010 10:01 AM, Matthias Goesswein wrote:
>> Hello,
>>
>> I've upgraded from mercurial 1.6.x (i never remind the last version
>> number) to mercurial 1.7 on windows, and i've trouble with
>> subrepositories.
>>
>> I've tried to make two Repositories (MyRepo1 and MyRepo2)
>> on the same directory level and use one MyRepo2 as a Subrepo of MyRepo1:
>>
>> That are the commands:
>>
>> hg init MyRepo2
>> echo Test > MyRepo2/test.txt
>> hg add MyRepo2
>> hg commit MyRepo2 -m MyCommit
>>
>> hg init MyRepo1
>> echo MyRepo2 = ../MyRepo2 > MyRepo1/.hgsub
>> hg add MyRepo1
>> hg commit MyRepo1 -m MyCommit
>>
>> I'll get that:
>>
>> + MyRepo1
>> - .hg
>> - .hgsub
>> - .hgsubstate
>> + MyRepo2 (as Subrepo)
>> - .hg
>> + MyRepo2
>> - .hg
>> - test.txt
>>
>> But if i want to call hg pull within the MyRepo1/MyRepo2 directory, i'll
>> get an error message:
>>
>> cd MyRepo1/MyRepo2
>> hg pull
>> abort: repository default not found!
>>
>> So there is no default path for the subrepo set within the hgrc file.
>>
>> As i remind, within the old version the default path was set for
>> subrepos.
>
> Right. That's a change (regression?) I introduced in ef5eaf53f4f7 while
> working on issue1852. I simply didn't consider this case - which however
> explains why the old code defaulted to repo.root.
>
> Before the change subrepositories with relative paths would usually get
> a default path based on its parents default path, but in the case where
> there was no default path it would be based on the local path of the top
> repo.
>
> Now we no longer use the local path. Instead we use the path specified
> for push/pull (if any).
>
> I'm not sure, but I think my opinion is that the old behavior was
> confusing and wrong and that the new behavior in most cases is better.
>
> We could also wrap commit with _subtoppath like I did in 5dbff89cf107,
> but I don't think that is a good idea.
>
> (Subrepos with non-trivial relative mappings are IMHO confusing and
> should be avoided and deprecated. It do make some sense to have
> different layouts on a central repository and on local clones, but I
> think that is better solved with the new subpaths. Otherwise we end up
> with clone no longer being a transitive operation - and cases like this...)
>
> /Mads

Maybe its clearer or better, but at the moment I'm very confused. :-)

For me its not clear, why i have to set the path to the subrepository in 
the hgsub file and then i have to set it too for the pull operation.
For me it seems like information duplication. What happens if the two 
informations are not equal? For what is the information written in the 
.hgsub file used for?

I've the following structure, somewhat simplified, for better unterstanding:

I split my software into software components (they are reusable within 
different projects) and project specific code. So there are two 
directory trees (At the moment both trees are within one hg repository, 
only the individual components are subrepos):

- .hg
- .hgsub
- Project1
- Project2
...
+ Components
   - MyComponent1
   - MyComponent2
   - MyComponent3

The MyComponents* folders are Subrepos and i want them to be in specific 
Projects. with mercurial 1.6 i wrote:

.hgsub:
Project1/MyComponent1 = Components/MyComponent1
Project1/MyComponent2 = Components/MyComponent2
Project2/MyComponent2 = Components/MyComponent2
Project2/MyComponent3 = Components/MyComponent3

and all worked fine.

Now - as i right understand -, I've to set all pull paths too. That 
works, but its a mess and error prone.

If i have many components (around 30 is realistic) and a new project is 
started, i don't want do that. The old behavior with only editing the 
.hgsub file was clear and was also well-arranged.

I've also looked for the subpaths feature, i didn't know about that 
before. But its no solution for that problem. As I understand i can make 
aliases, which can be used within the .hgsub file.

Cheers,
Matthew.


















More information about the Mercurial mailing list