Two experimental features: subrepos and shared repos

[Arne Babenhauserheide]

Am Mittwoch, 17. Juni 2009 05:43:22 schrieb till plewe:
> > Further: subrepos will often be used for shared libraries. The subrepo
> > will be used in other contexts too, and commit messages should thus be
> > self-contained and not mention the outer repo. Similarly the commit
> > message in the outer repo shouldn't reference implementation details of
> > code not in the repo.
...
> I completely agree. I think commits (and also merges) should be done
> one repo at a time. Otherwise I would probably prefer to use a single repo
> distributed over several directories over using subrepos.

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

One of my uses of Mercurial is for Python scripting, and there I have many 
different projects depending on libraries I wrote myself. 

Because it's my own library I tend to improve things quite often - and most 
times in different main projects. Currently that means, I have to go into each 
library repo and commit there manually, when I improve it. Since I'm lazy, 
this lead to just cloning the library repo and cluttering it with different 
projects - which I don't really like, but prefer over having to clone all 
subrepositories again. 

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. 

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. 

For people who don't want this binding, there's still the option of just using 
normal repositories in subdirs. 

I think I see different usecases, though: 

1) I want people who clone this repo to have the dependency-repos at once, and
2) I want to work transparently in many repositories. 

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. 

(though keeping them in the state needed for the main repo would require a 
commit in the main repo to abort if there are uncommitted changes in a 
subrepo, so a commit would be necessary anyway)

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/20090617/53228420/attachment.pgp