views:

63

answers:

1

Originally my subrepo's were defined with an absolute URL in .hgsub, which is now causing some trouble. It makes "friendly dictator" workflow impossible since I want to use an intermediate server where users clone their working copies from. Then I would pull changes to the intermediate server before pushing them to the master repository (intermediate server is also the continuous integration host, thus I won't pull stuff directly to the master). The absolute paths prevent this as the cloned repo's would be pushed directly to the master.

Now the problem is that my hg server spews out 404 errors when I try to push my changes made in the .hgsub file. Below is an example of a change I made

# original subrepo definition
common = http://hgserver/disp/common
# and after the change
common = common

This does not work, it spews out the following error

$ hg push
pushing to http://hgserver/disp
pushing subrepo common
abort: HTTP Error 404: Not Found

Is is possible to change the subrepo configuration in this way or do I have to recreate the whole repository?

+1  A: 

Yes, it should be changeable (and you're right that relative makes for a better work flow), however, the relative url path is taken as relative to the hg root of the repo in which the .hgsub lives -- not to where you happen to be pushing (which comes from .hg/hgrc's deafult entry in the paths section.

Here's a pretty normal subrepo layout:

on server http://hgserver/disp/main
    http://hgserver/disp/common # the "common" repo
    http://hgserver/disp/main # the main repo
        http://hgserver/disp/main/.hgsub # contains "common=../common"

Then after a clone everything just works and the same hgsub works fine on the server too.

There are a lot of stack overflow questions where people walk through the best layouts for relative subrepo setups, and while I've not tried switching from one to the other I think if you do the "next to" style of sub-repo with "../sibling" I show above it'll work fine.

Ry4an
Thanks, I'll have to fiddle with the paths a little bit more. The documentation of subrepos is, well, lousy :-/
puudeli
Yeah, they kind of snuck in as a feature with the understanding they'd grow in features, docs, and support once it became clear how they were being used. There's now a company paying a contractor to add subrepo support to most all the commands, so I expect they'll look a lot more polished in an upcoming release.
Ry4an
I'm the guy adding `-S` flags to a bunch of commands (status, diff, incoming, outgoing, ...) to make the aware of subrepos. I've also recently added a feature that lets you remap the lines in your `.hgsub` file, please see: http://mercurial.selenic.com/wiki/SubrepoRemappingPlan
Martin Geisler
Thanks for the help. The solution that worked for us was to redo the repositories. We renamed the old repos and then correctly created the subrepo's again under the main repo. Previously subrepos were siblings of the main and that just did not work.
puudeli