[PATCH 3 of 5] subrepo: fix hgrc paths section during subrepo pulling

[Saint Germain]

On Sun, 14 Mar 2010 07:38:03 +0000 (UTC), Edouard Gomez
<ed.gomez at free.fr> wrote :

> Benoit Boissinot <benoit.boissinot <at> ens-lyon.org> writes: 
> > Since Saint Germain added the test, I'd like to have his input. What
> > should subrepo do in that case (i.e. was your test wrong, or are
> > there conflicting opinions on what the end result should be)?
> > 
> > (I'm sorry, I don't use that feature enough to have an idea what the
> > "correct" behaviour should be)
> 
> The idea is that the clone layout doesn't represent the sources
> layout.
> 
> That's why i switch from a path.join with relative clone path to the
> function that gives the absolute source path.
> 
> This helps in the case someone want to pull only in the subrepo. THe
> config points to the source of the clone instead of that non existent
> pat join pointing at the source of parent clone + relative path.
> 
> Plus this patch allows this other usage
>  - clone -U main repo
>  - edit main/.hg/hgrc to have a default-push in there (eg: mine has
>    http default and ssh default-push)
>  - hg up -C
>  -> all hgrc files point to both locations correctly
> 
> But sure, wait for the original author test to validate the change.
> 

Hello !

At last, someone interested in subrepo !
I was feeling quite lonely trying to patch the subrepo management
without any input or advice (except -many thanks- from tonfa and sjl).

Indeed my first patch on .hgrc management was introducing a regression
and I immediatly tried to correct it 2 days after
:
http://www.selenic.com/pipermail/mercurial-devel/2010-February/018571.html

However my first patch was accepted, but my following correction wasn't.
Anyway after being reviewed, I finally proposed a 'clean' patch which
is still pending review:
http://www.selenic.com/pipermail/mercurial-devel/2010-February/018648.html

To answer your question, we both agree on the case with absolute path
(the subrepo shall always point to the absolute path even after
multiple cloning).
However it's more complicated on relative path, in case of clone of
clone it seems more 'logical' to reference the working copy instead of
keeping the relative path because it may not exist anymore.

An example:

1) you have 2 repositories on a bitbucket, main
(http://www.bitbucket.org/main) and extra
(http://www.bitbucket.org/extra). You would like to add extra as a
subrepo of main, so you will put "extra = ../extra" in .hgsub.

2) Let's now clone main on our computer (/home/user/main), what should
go inside the hgrc of extra:
 a) http://www.bitbucket.org/extra
 b) http://www.bitbucket.org/main/extra
Here we both agree that 2-a) is the correct answer

3) Let's now clone again from the main on our computer to another
location
on our computer (/tmp/main).
What should go inside the hgrc of extra:
 a) /home/user/extra
 b) /home/user/main/extra
In that case, I _think_ (it's only an opinion !) that Mercurial should
reference instead the working copy (3-b) because /home/user/extra
doesn't exist.

I had a very long an interesting discussion on the subject with Steve
Losh. I ended being very confused about the whole subject and no
obvious answer.

Anyway most people will only make a first level clone, so I think that
your patch should be accepted. The second level clone (clone of clone)
won't be so easily fixed (as my naive approach with my latest patch).

If you have other questions, don't hesitate !

For my part I would very much like any input/advice about this patch:
http://www.selenic.com/pipermail/mercurial-devel/2010-March/019313.html
As I personnaly think that it is essential to subrepo management (to
guarantee that we are in a particular state with no 'dirty' subrepo).

Regards,

P.S.: lots of french around here... ;o)