[PATCH] subrepo: do not push "clean" subrepos when the parent repo is pushed

[Angel Ezquerra]

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

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,

Angel