Matching files in subrepositories
mg at aragost.com
Wed Sep 22 07:48:43 CDT 2010
I visited my client yesterday and dicussed the work I have done on
enhanching subrepositories and the work that remains.
One thing they still miss is a way to distinguish between the files
inside a subrepository and the subrepository itself. This is needed in
this scenario where we have the following setup:
hg init subrepo-match
hg init sub
echo 'sub = sub' > .hgsub
hg add -S
hg commit -m init
echo x >> x
hg commit -m x
echo y > x
in other words -- we have a subrepository with two changesets and a
dirty working copy. The outer repository references the first changeset
in its .hgsubstate.
The central question is: how can we commit *only* the change in the
outer repository's .hgsubstate file?
A simple 'hg commit' in the outer repo will first enter sub/ and make a
commit there, after which it will record the third (the new) changeset
in the .hgsubstate file. We want to record the second changeset.
To put more meat on the story, consider a project that uses a large
number of libraries. A developer wants to test new versions of the
libraries, so he does
cd libX; hg pull; hg update -C; cd ..
cd libY; hg pull; hg update -C; cd ..
and so on. He then builds the software and tests this configuration.
Happy with the results, he wants to commit the new state of each
subrepository in the outer .hgsubstate file.
However, the build and test process modifies some of the tracked files,
and he does not want those local modifications to be part of the commit.
So just like we support a partial commit where people do
hg commit X Y
and excludes other modified files, he want to partially commit the new
working directory parent revision in the .hgsubstate file, and do so
without recursing into the subrepos themselves.
The immediate answer is to suggest a --no-recurse option, but that is
not enough since subrepos can be nested on different levels inside each
other. So some recursion may be needed to match all subrepos.
Klaus (a developer at the company I work for) has suggested that we
solve the problem by extending our match syntax with a syntax for
matching repository boundaries:
Please see his message again and let us know if the above use case make
more sense to you. Nobody replied to my two last mails in the thread,
hence this new mail.
Professional Mercurial support
More information about the Mercurial-devel