[PATCH 0 of 4 ] revert: add support for reverting

Angel Ezquerra angel.ezquerra at gmail.com
Thu Mar 29 07:46:41 CDT 2012


On Thu, Mar 29, 2012 at 2:04 PM, Martin Geisler <mg at aragost.com> wrote:
> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>
>> The first patch refactors the revert function on the commands module,
>> moving most of its code into cmdutil.revert.
>>
>> The second and third patches add support for reverting modified subrepos.
>
> Is it 100% clear that 'hg revert' means running 'hg update X' where X is
> the revision listed in .hgsubstate? Could it not mean running 'hg
> revert' in the subrepos?
>
> If it meant running 'hg revert', then
>
>  hg revert some-sub-repo/foo.txt
>
> would be consistent with
>
>  hg revert some-sub-repo
>
> If we imagined that .hgsubstate was continiously updated to match the
> actual state of the subrepos, then a subrepo that was updated to a new
> revision would show up as
>
>  hg status
>  M .hgsubstate
>  hg diff
>  diff --git a/.hgsubstate b/.hgsubstate
>  --- a/.hgsubstate
>  +++ b/.hgsubstate
>  @@ -1,1 +1,1 @@
>  -710f0e4efbfed026597643138323f73e18b565ff some-sub-repo
>  +28902045051d1ffda5c85499d313d72e73d694c8 some-sub-repo
>
> I think your patch makes
>
>  hg revert some-sub-repo
>
> equivalent to
>
>  hg revert .hgsubstate
>
> which in turn should mean that 'hg update 710f0e4efbfe' was executed in
> some-sub-repo.
>
> This is just some quick ideas I had when I thought of this problem. I
> hope they make sense :)

Yes they do! It's great to see I'm not the only one thinking about
this stuff! :-)

There are several reasons why I think that 'hg revert subrepo' means
running 'hg update X' where X is the revision listed in .hgsubstate
for the given subrepo:

1. When the user says "hg revert subrepo -r rev" it is safe to assume
that he wants to revert the subrepo to the state that it had in
revision rev. As far as the outer repo is concerned, the state of the
subrepo _is_ the subrepo revision. Thus reverting the subrepo must
mean to revert its revision, not its _contents_.

2. In my (extensive!) use of subrepos I can't recall ever needing to
revert the _contents_ of a subrepo. However I quite regularly need to
revert the state of a subrepo. I've often watched other users use
subrepos (often answering their questions) and I'd say that their
experience is the same.

3. If we don't update on revert, reverting and committing a subrepo
would need you to create a new revision on the subrepo (i.e. you'd
need to go into the subrepo and commit).

4. IMHO reverting a repo to a previous revision (using --all) and
committing the result should create a changeset whose contents should
be identical to the reverted revision. If we revert on subrepos
performs an update that will be the case. If it simply did a revert
--all on each subrepo the result would not be the same because it
would require a new commit on each subrepo, thus making the .hgsubsate
file different in the original and the reverted revision.

For these reasons it is 100% clear to me that the right thing to do is
to update the subrepos when reverting them.

However I understand that it may be handy (although I've personally
never needed it) to be able to easily revert the contents of a subrepo
as well. One solution would be to add a "-noupdate" (or -no-update?)
flag to revert, which would avoid the "update" step when reverting a
subrepo.

BTW, in your "continously updated .hgsubsate file" scenario you cannot
simply do 'hg update .hgsubstate' to revert a subrepo because you may
have modified more than one subrepo. Reverting .hgsubsate would revert
_all_ subrepos.

>> The last patch is the one I'm most unsure about.
>> It adds support for reverting added subrepos. It is based on
>> automatically modifying the .hgsub and .hgsubstate files. I'm not sure
>> that is the best approach.
>
> I'm also not sure. Since the used had to edit .hgsub to add the subrepo
> in the first place, wouldn't it be natural for him to edit it again to
> un-add the subrepo? Or he could run 'hg revert .hgsub' to get back to
> where he was.

I think that it would in fact be great to add support for adding
subrepos to both hg add and hg remove/forget. Those could simply
automatically add or remove the proper line to the .hgsub file.

I think that would be a big step towards making subrepos "first class
mercurial citizens". The fact that you must (create and) edit the
.hgsub file is an unnecessary detail that confuses users IMHO. The
number of times that I've had to explain how the .hgsub and
.hgsubstate files work on mercurial to new users is endless. It'd be
so much nicer (and less prone to errors!) to be able to tell them:

"Just do 'hg add subrepo' to add a subrepo. Do not foget to commit, as usual!"

If we did that, implementing the last patch (and one that would add
support for reverting removed subrepos as well) would be trivial.

> Btw, I don't think you need to edit .hgsubstate in the working copy. As
> far as I know, it's not used for anything and commit rewrittes it
> anyway.

I kind of figured that could be the case, but I wasn't sure. I'll take
it into account on a future version of that patch.

Cheers,

Angel


More information about the Mercurial-devel mailing list