5 comments
Comment actions Permalink

If you push something into a subrepository, the main repository is not intended to automatically get the change. You need to run "hg update", which in turn will pull in the new changes from the subrepositories, then update the .hgsubstate file. You then commit in the main repo - and that will be the change TC detects.

0
Comment actions Permalink

Hi,
yes you need to say mercurial you track a new revision of a subrepository. If you need an svn-like subprojects (when you track a latest commit in the subrepository), you might use our checkout rules instead of hg subrepositories. Just create a new VCS root for your subrepository, attach it to build configuration and set a checkout rule to be +:.=>desired/path/for/subrepository.

0
Comment actions Permalink

Le 19/05/2011 19:05, Dmitry Neverov a ecrit :

Hi,
yes you need to say mercurial you track a new revision of a subrepository. If you need an svn-like subprojects (when you track a latest commit in the subrepository), you might use our checkout rules instead of hg subrepositories. Just create a new VCS root for your subrepository, attach it to build configuration and set a checkout rule to be +:.=>desired/path/for/subrepository.


We already have subrepository, we're using it, even if it's not perfect,
we cannot change this.
We have to deal with hg bugs or limitations on this feature.

I think calling a script that does clone/pull on all repos is the better
solution I have found.

Gérald

0
Comment actions Permalink

Le 13/05/2011 19:04, Christian Goetze a ecrit :

If you push something into a subrepository, the main repository is not intended to automatically get the change. You need to run "hg update", which in turn will pull in the new changes from the subrepositories, then update the .hgsubstate file. You then commit in the main repo - and that will be the change TC detects.


That's not so easy to use. Commiting all subrepositories at once is not
very effective, and moreover the hg pull is not recursive as the hg push is.

0
Comment actions Permalink

I didn't suggest "committing to all subrepositories". I said that pulls are non-recursive by design. The basic premise of hg is to never create a configuration that hasn't been seen at least once by a developer, giving  that developer the opportunity to build and test it.

This means that whenever a subrepository is updated, all repositories which include that subrepository must be looked at by a developer, and the action of pointing the clients of that subrepository to a new revision is a manual one: "hg update". One you updated a client (i.e a repository including the subrepository), you must commit that update (reflected as a change to the .hgsubstate file) - and that is the change that TC will see.

You may not like this feature, and yes, it is different from the way svn does things, but it's not a bug.

If you want svn-like behaviour, then mutiple VCS roots with appropriate mappings is the way to go.

0

Please sign in to leave a comment.