subrepo: what about making subrepo URLs configurable
JonnyDee
jonny.dee.1 at googlemail.com
Wed Feb 17 22:13:44 UTC 2010
On Feb 17, 10:57 pm, Augie Fackler <li... at durin42.com> wrote:
> On Wed, Feb 17, 2010 at 3:42 PM, JonnyDee <jonny.de... at googlemail.com> wrote:
> >> > in our company we use Mercurial's subrepo feature in many cases and it
> >> > is working pretty well. Recently, however, we had to restructure the
> >> > directories of our central Mercurial server. Consequently, some URLs to
> >> > our repositories on that server have changed. For instance, the URL to a
> >> > repository xyz-framework with URL
> >> > ssh://mercurial.company.com/xyz-framework changed to
> >> > ssh://mercurial.company.com/libs/xyz-framework. Now the problem is that
> >> > we cannot rollback to a previous version of a project referencing that
> >> > xyz-framework anymore, because older revisions reference the subrepo by
> >> > using its old URL ssh://mercurial.company.com/xyz-framework, and this
> >> > URL is no longer valid. In order to get an older state we would have to
> >> > make sure the old URLs can still be used.
>
> >> On Feb 17, 11:05 am, Andreas Axelsson <andreas.axels... at combination.se> wrote:
> >> Without actually considering the pros & cons of your suggestion, I can see two alternative solutions:
>
> >> 1. Redirect the old URL to the new on the web server.
> >> 2. Branch and edit .hgsub to match the new URL if you have to work on an old revision.
>
> >> Cheers,
> >> /axl
>
> > Thanks for your suggestions. But those two workarounds are not really
> > solutions we would like toend up with. Ther first suggestion requires
> > appropriate control over the server infrastructure which is not the
> > case when a project references a third party subrepo. And the second
> > suggestion sounds like "if you want to make the hello world program
> > output 'hello universe' branch it and change the source code
> > correspondingly". But the .hgsub isn't a source code, it's actually a
> > configuration for subrepos. I think the URLs to subrepos themselves
> > shouldn't be versioned. But for those who disagree...maybe there would
> > be a hybrid solution, which allows current behavior and my suggested
> > one (or another one which avoids the problem of outdated URLs in
> > history)?
>
> The problem with listing anything in .hg/hgrc is that there's no way
> to carry that along with clones, so it'll be a manual configuration on
> a per-client basis, and won't be in the tree at all...
I know, but to rollback to an old version will also require the
clients to tweak the old .hgsub file. But as I said, one could imagine
a hybrid solution. For instance, using an %include directive in .hg/
hgrc referencing a version file in the repo could reproduce the
current behavior if it is needed.
But maybe Mercurial should introduce some .hg/etc directory, which is
always cloned along with all its files underneath that directory. This
would solve a lot of problems I think. Mercurial's mq extension, for
example, does exactly such kind of thing with its 'qclone' command.
But it's a solution specialized only for mq. A general approach would
be better, I think. One could also pass around some meta information
about a repository. Something like guide lines, readme's, contact
information, etc. ... Just an idea...
Jonny
More information about the Mercurial
mailing list