Dealing consistently with subrepositories

Martin Geisler mg at aragost.com
Tue Apr 5 07:14:27 CDT 2011


abn2bf at magic.ms writes:

Hi Olaf

> Personally I could agree to both default behaviors, if
>
> - recursive default: status would show me that files in my subs are
>   modified, so I would have the chance to commit the subs in a first
>   step. [...]

Yeah, I agree with you -- commit and status must match each other.

> Note that there is another motivation which requires at least a switch
> for a local scope of status: performance. If you consider a large
> number of files/dirs in the subs the recursive status can take a
> while... Of cause you need to be sure that your subs aren't modified,
> but there could be read-only 3rd party libraries hooked in as subs for
> example.

> - not recursive default: in this case, if there are uncommitted
>   changes in subs, commit needs to stop (unless you'd override this
>   with --force, hopefully knowing what you are doing)...

Yes, so the ui.commitsubrepos=False setting will do what you want here?

> I think Mads gave a clear statement for a recursive commit default
> behavior below - fine. Then let's build the rest around that
> consistently.

Right. You wrote a private mail to me where you summed up the gap
between the current behavior and consistent behavior. Could you write
that to the list too?

Then we can summarize what we've discussed in this thread and try to
agree on what to fix and how.

> Transparency and "status vs add, remove and commit"
>
> Yes, definitely add, remove, addremove, move, etc should support
> relative paths into subs, e.g. "hg add sub1/file.c" should add file.c
> to sub repo sub1. Actually "add -S" allows this already - but the
> others don't (yet).

There is not much controversy around remove and addremove: they should
just get their -S flag. The move command is a bit tricky: we don't have
a way of saying "this file came from repository X" so we should probably
abort if you try to move a file from one subrepo to another.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list