[PATCH] subrepo: do not push "clean" subrepos when the parent repo is pushed
angel.ezquerra at gmail.com
Thu Feb 14 07:05:07 CST 2013
On Thu, Feb 14, 2013 at 10:54 AM, Isaac Jurado <diptongo at gmail.com> wrote:
> On Thu, Feb 14, 2013 at 1:06 AM, Angel Ezquerra
> <angel.ezquerra at gmail.com> wrote:
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>> # Date 1360795816 -3600
>> # Node ID 26276460d54aecdeb107c82c4e3f2ca7c0c6a8b3
>> # Parent 55b9b294b7544a6a144f627f71f4b770907d5a98
>> subrepo: do not push "clean" subrepos when the parent repo is pushed
>> A clean subrepo is defined as one that has not had its dirstate, bookmarks or
>> phases modified.
>> This patch works by adding a "clean" method to subrepos. In the case of
>> mercurial subrepos, this method calculates a "stamp" (i.e. a set of file hashes)
>> of the repository state at the time of push with a similar "stamp" that was
>> stored on a file when the subrepo was cloned or pushed to a given remote target.
>> If the stamps match the subrepo has no changes that must be pushed to the target
>> repository and thus the push can be skipped.
>> Note that we calculate the stamp file by calculating hashes for several key
>> repository files, such as the dirstate, the bookmarks file and the phaseroots
>> file. This means that our "clean" detection is not perfect, in the sense that
>> if the working directory has been updated to a different revision we will
>> assume that the subrepo is not clean. However, if we update to another revision
>> and back to the original revision the clean() method will correctly detec the
>> subrepo as being clean.
>> Also note that a subrepo being "clean" is not the opposite of it being "dirty".
>> A subrepo is dirty if it updated to a different revision that the one that is
>> pointed to by the subrepo parent or if its working directory is not clean. This
>> is a different concept.
> Have you considered the following situations?
> 1. The .hgsub file changes
> 2. The [subpaths] section redirects pushes to a different location
> from last push.
> I couldn't deduce it from the code so I had to ask.
The patch certainly covers situation #1 because we keep track of the
clean status for each remote path. Changing the .hgsub file will
simply change the remote path (it could also remove a subrepo, in
which case this does not apply; or add it in which case the repo will
just be cloned).
Regarding situation #2 I have not tried it. It is great that you bring
this up. I believe it should probably work because the patch checks
the current remote path, and I believe that is obtained after the
subpath substitution has been done. That being said I'll have to check
that is the case.
Thanks for your comments,
More information about the Mercurial-devel