[Users] path expansion in git/darcs/hg repositories

[Roland Haas]

Hello Eric,

>> !TARGET   = $ARR !TYPE     = git !URL      = 
>> git://someurl/Scotch/$2 AUTH_URL = rhaas3 at someotherurl/Scotch/$2 
>> !REPO_PATH= ../$2 !CHECKOUT = Scotch/SoundSpeed 
>> Scotch/Bremsstrahlung
> 
> That's an interesting example, but is there really a case where you 
> would need $2 in both URL and REPO_PATH? I'd rather not add anything
>  that could add confusion like that. Also, I think it's better to 
> stick with the nature of distributed versioning systems and clone the
> whole repo, as opposed to attempting a clone of a sub-directory (I'm
> assuming the Scotch is the repository in your example).
No, the example (and code that I have, but not in the Einstein Toolkit)
is for SoundSpeed and Bremsstrahlung being full git repositories which
are both located in a Scotch folder (an arrangement of thorns that work
with Whisky). With the current hard-coded assumtions on the directory
layout of git/darcs/hg repositories I think I need the ../$2 in
REPO_PATH. Since both SoundSpeed and Bremsstrahlung are full
repositories I would also need $2 in the URL. I am not sure if having two
$2 is confusing, both refer to the second part of the CHECKOUT item.
Having $2 in the URL would allow users to avoid having to replicate the
whole TARGET..CHECKOUT stanza for each git repository that is part of
the arrangement.

> That being said, I agree that the $[12] expansion should be expanded
>  to cvs and http/ftp.
Fine by me :-)

>> The first variant seems to be the more general one since it does 
>> not make assumptions about the repository layout. Currently both 
>> versions are used in einsteintoolkit.th (first one for McLachlan, 
>> second one for GenericFD).
> 
> This variance is actually by design, as you point out we use both 
> methods in einsteintoolkit.th. Is it causing any problems when you 
> add other thorns? It has worked very well for einsteintoolkit.th, and
> I would prefer not to change the method unless it's causing issues.
Hmm, I suspected that it was by design. So it is a feature. I'll work
around it then.

Yours,
Roland

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20100608/25c6ea8e/attachment.bin