Dealing consistently with subrepositories

abn2bf at magic.ms abn2bf at magic.ms
Thu Mar 31 17:19:43 CDT 2011


Hi Mads, Martin, all,

I'm happy to see the see attention on this topic. As Martin mentioned, we are preparing a Mercural rollout in mulitple, large projects - each with multiple sub components/repos. The inconsistency is one of my major concerns as commands like status or outgoing are actually hiding what will happen in the next step. Partly we can address this by setting aliases (but this should be just a temporary workaround).

Obvioulsy one can debate about the desired default behaviour for the group of commands like commit, status (we also had this debate internally and couldn't agree :-)). I also saw this in this thread: on the one hand you want to ensure consistency (which is definitely a strong argument) on the other hand (if you would be notified by status about pending commits in the subs) you may want to commit the subs with individual commit messages before you commit on the parent. Nobody prevents you to do that - just status needs to show you...

Before we conclude on the default behavior I think there is a common sense that commands must not behave in a surprising way (at least within each group of commands) and there need to be command line options to get to the opposite behaviour (where it makes sense). (Preferrably we'd also allow to have people define their set of aliases to get the opposite default behavior and allow them to get the other behavior via command line option. - I'm aware that this needs some more thoughts as you'd end up with conflicting command line options but one could say 1(default) -1 +1 = 1 :-)).

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. Personally I think this is in many cases the most convenient behavior as I can see from top down all my uncommitted changes. (( I even thought of a command which would locate the top-most parent repo and run a recursive status from there to get the full picture from whereever I'm staying in my project. But I don't want to get you into this right now. I can address this with a small extension :-) ))
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 r/o 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)...

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


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).

Behavior per repo
There was another debate if the behavior of the commands should be per repo. You can argue about that - my fear would be that people would be confused when things behave differently depending on the repo they are working in. Still, there are situations where the per repo behavior would be in line with the expectations. E.g. if you would be able to mark a sub r/o (see the lib example above), you could omit it from recursive status checks/commit/add/addremove etc. In that case the setup clearly states that you are not supposed to commit things in here (if you still modify things you need to know what you are doing.)

Recursive Log
Yes, we'd definitely like a kind of "topographic" log etc. to get a better insight what has actually changed in detail in the subs between two changesets in the parent (based on the experience that the parent's changelog will never capture 100% of its sub's changes). I agree it's not trivial to get to a readable template here.
On the other hand - this might be indeed easier to realize within TortoiseHg (we are used to ClearCase Project Explorer to get this view) or maybe via the web as Martin proposed somewhere earlier in this thread.


We love the simplicity of Mercurial (compared to the commercial tools we used so far).
Let's keep things simple (and consistent) ,-)

greetinX
/Olaf


-----Ursprüngliche Nachricht-----
Von: "Matt Mackall" <mpm at selenic.com>
Gesendet: Mar 30, 2011 4:08:22 PM
An: greg at gerg.ca
Betreff: Re: Dealing consistently with subrepositories

On Tue, 2011-03-29 at 21:29 -0400, greg at gerg.ca wrote:
> On 29 March 2011, Martin Geisler said:
> > This defines a number of equivalence classes and I think we came up with
> > (Olaf, please correct me if I'm wrong):
>
> Disclaimer: I have not yet used subrepos. I'm just keeping my eye on
> them. Given that, this approach seems sensible.
>
> > * status <-> summary
> >
> > I think of 'hg summary' as a condensed version of 'hg status'.
>
> I would tiptoe quietly away from 'hg summary'. It's really a
> condensed version of parents, branch, status, (sometimes) qseries and
> (optionally) incoming/outgoing. Putting all of those commands into
> one equivalence class will lead you to a world of pain.
>
> Also, my gut instinct is that the default default should be
> non-recursive. Commands should only recurse by default if there is a
> *damn* good reason for doing so. push and update are the obvious
> candidates.

Commit must also be in this class. Atomic snapshots are a bedrock design
principle, subrepos are not an exception.

--
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list