Managing Dependencies with Subrepositories - Partial Checkout and Commit/Push Propagation

[Michael P. Jung]

On 2010-01-20 23:07, Mina R Waheeb wrote:
> Lets say repo B subrepo of A, clone of A will clone B too. If you did
> a modify some files in repo B and modify some files in repo A! The
> expected behavior that the modification in repo A depends on the 
> modification in repo B. How you wana commit repo A without committing
> repo B?

When does repo A need to care about pushing repo B?

There is nothing wrong with changing something in repo B, commiting it
and delaying the push, because it is only ment to be a local branch. Now
imagine you have to fix one critical bug in A that's not related to your
changes in repo B. In order to push A you're also forced to push B which
causes your local branch to be pushed into the wild.

So what's the whole idea behind enforcing pushing of subrepositories?
It's mainly for protecting the user of creating an inconsistent remote
repository. So the question is, what kind of change would render repo A
inconsistent? repo A doesn't care much about the content of repo B, but
it does care about the .hgsubstrate file. So in conclusion repo B only
needs to be pushed when a change of the .hgsubstrate file is about to be
pushed.

> Anyway, You still free to commit repo B without committing repo A!

For sure. That's why I would prefer if commiting and pushing subrepos
would become more explicit.

The ideal solution to me would be that if a repo A is pushed it checks
if .hgsubstrate has been changed - if so, check if remote repo B is
compatible with the content of the .hgsubstrate. When this is not the
case bail out with an error message telling the user to push repo B first.


--mp