Two experimental features: subrepos and shared repos

[Arne Babenhauserheide]

Am Mittwoch, 17. Juni 2009 13:08:15 schrieb Mads Kiilerich:
> On 06/17/2009 09:39 AM, Arne Babenhauserheide wrote:
> > I disagree, but I'm not really sure about it. For me subrepos would be
> > most useful if I could just treat the whole set as one repository (with
> > recursion).

> Arne, I based on your arguments I actually think we mostly agree. But I
> don't understand why you make this conclusion based on the arguments you
> give. Could you perhaps elaborate?

I think it's because I perceive the "one commit message for all" as a smaller 
part of the implementation. 

It's important on the long run (because it seems to give direction), but it 
isn't crucial for me. 

Maybe it could be judged by principle of last surprise: What would surprise 
users the least? 

Currently I know only one place where Mercurial asks me something directly: 
pushing or pulling where the protocol asks back (authenthication). In all 
other cases it either works OR stops. 


So from the consistency view there are only the options commit in all or 
require a clean state for all subrepos before allowing a commit in the main 
repo. And I think the second would suck for large repos. Doing it differently 
would be a surprise. 

On the other hand it would also be a surprise to do a local change in main and 
fixing a bug in a subrepo, committing and pushing the main repo, and then 
having QA nag because you forgot to add the bug ID ("but I didn't commit in 
the library repo!"). This could be lessened by adding an information in the 
commit message that there also was a commit in a subrepo and how to change it. 
This would require a way to amend exactly that last commit, though. 

For this it would be nice to have an "amend" option as in git: 

$ hg commit -m "tiny change"
committing change in shared_lib as "tiny change"
committing change in private_lib as "tiny change"
...
(to change this and use distinct commit messages in the subrepos 
you can use "hg commit --amend --distinct-messages" 
before you do any other operations). 

The example message is _very_ preliminary :)

> > Subrepo with recursing commit would allow me to really bind the repos
> > together and simply distribute my work into multiple repos while keeping
> > my workflow intact.
>
> Wouldn't that be solved nicely by commit recursing over subrepos and
> make individual commits in each subrepo?
>
> As it is now the outer repo will get a changeset with the an updated
> subrepo state and the same commit comment as the "real" commit in the
> subrepo. Do you really like that?

I wouldn't mind it, but I can imagine some nasty surprises here. 

But to a realworld example: 

I work on a roleplaying project (pen-and-paper). We have one main repo (1w6) 
and subrepos for the different game worlds and stories (campaigns). 

One of our developers mostly works in his game world. I on the other hand work 
in all repos at the same time. 

But when I go to a session, I only need the data from the current story. 

When I work on the ruleset, though, I sometimes have to modify parts in all 
repositories and for this it would be nice to be able to just say "changed the 
name of the ability score 15 from 'very good' to 'experienced'". 

> > The only thing I worry about is the commit message, since that might not
> > fit for the subrepos (for example "FIX bug 423", though the library uses
> > a completely different bugtracker). In that case I could still make the
> > commits one by one, though.
>
> Exactly. And I think that is a very good argument for why commit
> shouldn't commit automatically in all subrepos.

How about this: Check the state of every subrepo and then prompt for a message 
for each modified subrepo. Afterwards commit in the main repo. 

(Is that what you do?)

For less formal workflows (for example my local work) it would be nice, 
though, if I could just tell Mercurial to use one commit message for all 
subrepos. 

> > 1) I want people who clone this repo to have the dependency-repos at
> > once, and
>
> Where the important part is that the dependency-repos are shared?

They are shared in both cases. The important distinction is that in usecase 1 
the dependency isn't changed as part of the normal application development 
process. The subrepo implementation just reduces the pain of dependency 
gathering. 

For examply I currently have many projects which depend on pyYAML. If others 
want to join I can either say "first install yaml" or just include a snapshot 
of pyYAML in my repository. 

With subrepos I can just add it as subrepo and everyone who clones my source 
repo will get the dependency and can directly run my code. 

> > 2) I want to work transparently in many repositories.
>
> Where subrepos aren't shared? Yes, that seems to be what is addressed
> now. But I don't understand why anybody should want to do that.

No. The subrepos are still shared among many projects. The developers just 
don't have to worry about that. Just commit, pull and push as usual and do 
your testing. But "hg up 1.2.1" gives you the exact state of the group as it 
was for release 1.2.1, even though other projects might have changed the 
libraries in the meantime. 

It's about what my distribution does (Gentoo) when it installs dependencies, 
but with only exact version dependencies instead of "2 > version > 1.3.1-r4". 

And since branching and merging are fast in Mercurial, it wouldn't hurt the 
library if development diverges. 

It would even be beneficial if several projects worked in different named 
branches of the library, because this would allow easy merging of library 
improvements from one project into the other. 

Another example with the above yaml implementation: I could locally 
fix/improve/adapt stuff in yaml and simply keep it in a seperate (public) repo 
to which I could easily merge improvements in the mainline yaml. 

All this doesn't depend on the way _commit messages_ are given when I commit, 
though. 

> > The needs of usecase 2 are currently being addressed by the subrepo
> > extension, but the needs of usecase 1 aren't, since these would just need
> > cloning the subrepos and always keeping them in the state needed for the
> > main repo.
>
> I assume that support for cloning/updating subrepos will come soon

I hope so, too! 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090618/0b593643/attachment.pgp