subrepo wish list

[Steve Losh]

On Apr 14, 2010, at 6:18 PM, Michael Ekstrand wrote:

> After working with subrepos in Mercurial for some weeks now, I have been
> getting somewhat frustrated with the remaining user experience holes in
> them.  But with that, I also have proposals for what would make this
> experience better.
> 
> The purpose of this message is not to demand "write my feature! fix my
> bug!", but rather to share my thoughts based on some subrepos
> experience, see if there are already-existing methods to achieve my
> goals, and start a conversation about how best to fill these gaps.
> 
> For subrepos to be near-perfect for me, two things are missing or "broken":
> * Status support is nonexistent, as near as I can tell
> * Commit recursively auto-committing doesn't fit well w/ my workflow
> 
> For the first, it looks like there has already been some discussion on
> doing this and some submitted patches.  It seems to me that there are 3
> states a subrepo can be in:
> * Unchanged, and thus suppressible from status display
> * Changed but committed: the subrepo is changed from a parent repo
> perspective, but itself has no uncommitted changes.
> * Possibly changed and dirty: the subrepo has uncommitted changes, and
> its last checked-in status may or may not be the same as recorded in
> .hgsubstate.

Personally I'd find the following two features helpful:

* 'hg status --suprepos' would show *all* uncommitted changes, including any in subrepositories.  Maybe an extra character could be added to the output to distinguish changes in subrepos from changes in the main repo, but that's not a huge deal.

* 'hg summary --subrepos' would include a line telling you if committing in your main repo would update the .hgsubstate file -- i.e. subrepo X is currently at a different revision than the .hgsubstate lists.

> 
> Commit is a bit more complicated, and my ideal workflow is not
> backwards-compatible.  Right now, commit recursively tries to commit
> subrepositories before committing the current repository.  It would be
> quite nice if there were an option at least to modify this behavior.  My
> workflow would be best served, as near as I can tell, by the following:
> * If subrepositories are clean, commit and update .hgsubstate if
> necessary.  From a UI perspective, treat directories as files, so I can
> commit the updated state of subrepos selectively.
> * If subrepos are dirty, fail.  Require a --force option to proceed; in
> that case, update .hgsubstate but do not commit the nested repository.
> Have another option to do the recursive commit.
> 
> Basically, I don't want my subrepos transparently committed for me: I
> want to manually commit them every time.

If we want to stay backwards-compatible with the current behavior, we could offer a "[subrepos] autocommit = False" option in hgrc to disable the automatic commit of changes in subrepos.

Selectively committing individual updates to subrepos seems more difficult -- I think it would require a new option to commit and personally I don't see myself using it a lot.  Others might feel differently.

> 
> Thoughts?  Is there a way (options I don't know of, extensions, etc.) to
> accomplish either or both of these goals currently?  What is involved in
> making either of these happen?

I don't know of any extensions.

Sending patches to add the features would certainly get the ball rolling, even if the end result winds up being something different than our first ideas.

> 
> Thanks,
> - Michael
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial