Mercurial nested subrepos (subrepos in subrepos) not recursively commiting?
Mads Kiilerich
mads at kiilerich.com
Wed Jul 28 23:01:36 UTC 2010
Mina R Waheeb wrote, On 07/29/2010 12:30 AM:
> Lately, in work we have a conversation about the same topic i'd like to share.
> We consider this workflow bad practice and indicator of bad setup because all
> repos will share the same commit message which should contains information
> about changes.
Yes, FWIW I agree that this behavior of subrepo isn't perfect in all
cases, especially not if subrepos are used for shared generic libraries
used within customer-specific repositories.
That means that the developers have to be disciplined and be aware where
they are editing and what they are committing. They can't rely on
Mercurial to save their a** ... yet. ;-)
> Also, usually the developer don't remember which files changed
> since he/she start working which will cause committing unfinished files.
Yes, hg status is not yet aware of subrepos.
Fortunately it seems like somebody else have funded development of this.
> Finally
> we prevent anyone do this kind of commits and when a developer think two
> independent repo should have share the same commit, he should ask why they are
> two repos not one!
Yes, that is a good question. If you use subrepos for a shared library
used from custom projects then you probably need different changeset
descriptions in the different contexts - and you should make sure your
changes are independent and that no change touches both repos.
Subrepos can however also be used for example if some contributors only
need a subset of the repo, or to get the possibility of sharing a subset
of the repository without carrying the full history of everything - or
to be able to "throw away" a part of the repository and its history.
That could be reasons for having two repos and wanting the same commit
message in both.
/Mads
More information about the Mercurial
mailing list