Comments on NestedRepository wiki page

[Tristan Wibberley]

Hi folks,

I'm eagerly awaiting the nested repository feature in

http://www.selenic.com/mercurial/wiki/index.cgi/NestedRepositories

and I'd like to describe what behaviour I, as a plain old mercurial
user, would expect.


 "Do we need to protect ourselves from overlapping managed files?"

  I would expect to be able to convert a directory of files to a
repository and add the files to that repository. That would
include /moving/ files from the outer repository to the nested one. Say,
if the tiny mercurial C library were useful as its own thing and I
wanted to publish it on its own I would want to:

  hg clone http://.../crew
  hg mv ... # as necessary to gather library parts in one directory
  cd library-dir
  hg init
  cd ..
  hg add # any new files in nested repo or not
  hg rm # any deleted files
  hg commit -m 'updated mercurial to nest library as standalone'
  
  I would expect that the parent repository files would not be removed
but the mere record of a subrepository would represent their removal
from the parent and appearance in the child.

I would expect hg commit from a nested repository directory to apply to
the whole unless I told it otherwise because... [see my next difference
of opinion after the quote]


 "This model assumes that modules will usually only be read, and checked
out at a fixed revision, such that automatically running status queries
or updates in them makes little sense: they won't change often enough to
be worth the effort."

  If the nested repository were not a repository and I were developing a
feature that requires changes to the software in that directory (such as
changing the interfaces it provides) I would normally just make any the
changes necessary in that component to support my feature. This does not
change because that part of my larger software product is also available
on its own. I add the feature and the changes to everything my software
uses that is needed to make the feature work, and then I commit.

  I expect to then have a repository of my software, now with a new
feature, containing the library my software uses - which also has
changes to allow my feature to be implemented. I expect to be able to
make all necessary changes to the software I use as a component and
publish those changes to be seen by others working with the library so
they can pick up the changes that make a significant new product
possible.

Not writing to subcomponents is a workflow that derives from the
nondistributed, nonnested nature of tools like subversion. In a
distributed model I just produce the software necessary to make things
happen, commit it, and publish - nested repositories should let me do
that as if I were working on my own but allow upstream to trivially grab
my enhancements to their software that I have incorporated into my
sources.

-- 
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.