Patchwork [6,of,7] strip: introduce a soft strip option

login
register
mail settings
Submitter Boris Feld
Date Jan. 2, 2019, 10:35 p.m.
Message ID <a82909c0da7cc07ea1a4.1546468554@Laptop-Boris.lan>
Download mbox | patch
Permalink /patch/37428/
State Accepted
Headers show

Comments

Boris Feld - Jan. 2, 2019, 10:35 p.m.
# HG changeset patch
# User Boris Feld <boris.feld@octobus.net>
# Date 1539697680 -7200
#      Tue Oct 16 15:48:00 2018 +0200
# Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
# Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
# EXP-Topic archived-phase-UX
# Available At https://bitbucket.org/octobus/mercurial-devel/
#              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
strip: introduce a soft strip option

This is the first user-accessible way to use the archived phase introduced in
4.8. This implements a feature implemented during the Stockholm sprint. The
archived phase behave as stripping, changesets are no longer accessible, but
pulling/unbundling them will make then reappear. The only notable difference
is that unlike hard stripping, soft stripping does not affect obsmarkers.

Adding flag to strip is a good way to provide access to the feature without
taking a too big risk on the final UI we want.

The next changeset will make use of the archived phase for history rewriting
command. However, having a way to manually trigger the feature first seemed
better.

Using the archived phase is faster and less traumatic for the repository.
Pulkit Goyal - Jan. 3, 2019, 3:23 p.m.
On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net> wrote:

> # HG changeset patch
> # User Boris Feld <boris.feld@octobus.net>
> # Date 1539697680 -7200
> #      Tue Oct 16 15:48:00 2018 +0200
> # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
> # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
> # EXP-Topic archived-phase-UX
> # Available At https://bitbucket.org/octobus/mercurial-devel/
> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
> a82909c0da7c
> strip: introduce a soft strip option
>
> This is the first user-accessible way to use the archived phase introduced
> in
> 4.8. This implements a feature implemented during the Stockholm sprint. The
> archived phase behave as stripping, changesets are no longer accessible,
> but
> pulling/unbundling them will make then reappear. The only notable
> difference
> is that unlike hard stripping, soft stripping does not affect obsmarkers.
>
> Adding flag to strip is a good way to provide access to the feature without
> taking a too big risk on the final UI we want.
>
> The next changeset will make use of the archived phase for history
> rewriting
> command. However, having a way to manually trigger the feature first seemed
> better.
>
> Using the archived phase is faster and less traumatic for the repository.
>
> diff --git a/hgext/strip.py b/hgext/strip.py
> --- a/hgext/strip.py
> +++ b/hgext/strip.py
> @@ -76,7 +76,8 @@ def _findupdatetarget(repo, nodes):
>
>      return unode
>
> -def strip(ui, repo, revs, update=True, backup=True, force=None,
> bookmarks=None):
> +def strip(ui, repo, revs, update=True, backup=True, force=None,
> bookmarks=None,
> +          soft=False):
>      with repo.wlock(), repo.lock():
>
>          if update:
> @@ -85,7 +86,10 @@ def strip(ui, repo, revs, update=True, b
>              hg.clean(repo, urev)
>              repo.dirstate.write(repo.currenttransaction())
>
> -        repair.strip(ui, repo, revs, backup)
> +        if soft:
> +            repair.softstrip(ui, repo, revs, backup)
> +        else:
> +            repair.strip(ui, repo, revs, backup)
>
>          repomarks = repo._bookmarks
>          if bookmarks:
> @@ -110,7 +114,10 @@ def strip(ui, repo, revs, update=True, b
>            ('k', 'keep', None, _("do not modify working directory during "
>                                  "strip")),
>            ('B', 'bookmark', [], _("remove revs only reachable from given"
> -                                  " bookmark"), _('BOOKMARK'))],
> +                                  " bookmark"), _('BOOKMARK')),
> +          ('', 'soft', [],
>

Do we plan to accept arguments with `--soft`? If not, the default value
should be None.
Pulkit Goyal - Jan. 3, 2019, 3:25 p.m.
On Thu, Jan 3, 2019 at 8:53 PM Pulkit Goyal <7895pulkit@gmail.com> wrote:

>
>
> On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net> wrote:
>
>> # HG changeset patch
>> # User Boris Feld <boris.feld@octobus.net>
>> # Date 1539697680 -7200
>> #      Tue Oct 16 15:48:00 2018 +0200
>> # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>> # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>> # EXP-Topic archived-phase-UX
>> # Available At https://bitbucket.org/octobus/mercurial-devel/
>> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r
>> a82909c0da7c
>> strip: introduce a soft strip option
>>
>> This is the first user-accessible way to use the archived phase
>> introduced in
>> 4.8. This implements a feature implemented during the Stockholm sprint.
>> The
>> archived phase behave as stripping, changesets are no longer accessible,
>> but
>> pulling/unbundling them will make then reappear. The only notable
>> difference
>> is that unlike hard stripping, soft stripping does not affect obsmarkers.
>>
>> Adding flag to strip is a good way to provide access to the feature
>> without
>> taking a too big risk on the final UI we want.
>>
>> The next changeset will make use of the archived phase for history
>> rewriting
>> command. However, having a way to manually trigger the feature first
>> seemed
>> better.
>>
>> Using the archived phase is faster and less traumatic for the repository.
>>
>
I looked at test-strip.t and was unable to found anything specific to strip
implementation. Can we have a case for soft-stripping in that test?
Augie Fackler - Jan. 3, 2019, 11:01 p.m.
> On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com> wrote:
> 
> 
> 
> On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net> wrote:
> # HG changeset patch
> # User Boris Feld <boris.feld@octobus.net>
> # Date 1539697680 -7200
> #      Tue Oct 16 15:48:00 2018 +0200
> # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
> # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
> # EXP-Topic archived-phase-UX
> # Available At https://bitbucket.org/octobus/mercurial-devel/
> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
> strip: introduce a soft strip option
> 
> This is the first user-accessible way to use the archived phase introduced in
> 4.8. This implements a feature implemented during the Stockholm sprint. The
> archived phase behave as stripping, changesets are no longer accessible, but
> pulling/unbundling them will make then reappear. The only notable difference
> is that unlike hard stripping, soft stripping does not affect obsmarkers.

I’m not thrilled with this: I had envisioned the archived state as not full of garbage, but full of things that might merit revisiting some day. When I strip (or prune it) it’s usually a dead end, whereas I’d like a way to say “this isn’t interesting now, but it might be again some day”.

I have no idea if I’m in the minority, and I know this is very late feedback (because of the holidays I haven’t been at a computer much) but hopefully it’s useful.
Boris Feld - Jan. 4, 2019, 8:50 a.m.
On 03/01/2019 16:23, Pulkit Goyal wrote:
>
>
> On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net
> <mailto:boris.feld@octobus.net>> wrote:
>
>     # HG changeset patch
>     # User Boris Feld <boris.feld@octobus.net
>     <mailto:boris.feld@octobus.net>>
>     # Date 1539697680 -7200
>     #      Tue Oct 16 15:48:00 2018 +0200
>     # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>     # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>     # EXP-Topic archived-phase-UX
>     # Available At https://bitbucket.org/octobus/mercurial-devel/
>     #              hg pull
>     https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>     strip: introduce a soft strip option
>
>     This is the first user-accessible way to use the archived phase
>     introduced in
>     4.8. This implements a feature implemented during the Stockholm
>     sprint. The
>     archived phase behave as stripping, changesets are no longer
>     accessible, but
>     pulling/unbundling them will make then reappear. The only notable
>     difference
>     is that unlike hard stripping, soft stripping does not affect
>     obsmarkers.
>
>     Adding flag to strip is a good way to provide access to the
>     feature without
>     taking a too big risk on the final UI we want.
>
>     The next changeset will make use of the archived phase for history
>     rewriting
>     command. However, having a way to manually trigger the feature
>     first seemed
>     better.
>
>     Using the archived phase is faster and less traumatic for the
>     repository.
>
>     diff --git a/hgext/strip.py b/hgext/strip.py
>     --- a/hgext/strip.py
>     +++ b/hgext/strip.py
>     @@ -76,7 +76,8 @@ def _findupdatetarget(repo, nodes):
>
>          return unode
>
>     -def strip(ui, repo, revs, update=True, backup=True, force=None,
>     bookmarks=None):
>     +def strip(ui, repo, revs, update=True, backup=True, force=None,
>     bookmarks=None,
>     +          soft=False):
>          with repo.wlock(), repo.lock():
>
>              if update:
>     @@ -85,7 +86,10 @@ def strip(ui, repo, revs, update=True, b
>                  hg.clean(repo, urev)
>                  repo.dirstate.write(repo.currenttransaction())
>
>     -        repair.strip(ui, repo, revs, backup)
>     +        if soft:
>     +            repair.softstrip(ui, repo, revs, backup)
>     +        else:
>     +            repair.strip(ui, repo, revs, backup)
>
>              repomarks = repo._bookmarks
>              if bookmarks:
>     @@ -110,7 +114,10 @@ def strip(ui, repo, revs, update=True, b
>                ('k', 'keep', None, _("do not modify working directory
>     during "
>                                      "strip")),
>                ('B', 'bookmark', [], _("remove revs only reachable
>     from given"
>     -                                  " bookmark"), _('BOOKMARK'))],
>     +                                  " bookmark"), _('BOOKMARK')),
>     +          ('', 'soft', [],
>
>
> Do we plan to accept arguments with `--soft`? If not, the default
> value should be None.
Good catch, not sure how it ends up with []. Will fix in V2.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Boris Feld - Jan. 4, 2019, 8:51 a.m.
On 03/01/2019 16:25, Pulkit Goyal wrote:
>
>
> On Thu, Jan 3, 2019 at 8:53 PM Pulkit Goyal <7895pulkit@gmail.com
> <mailto:7895pulkit@gmail.com>> wrote:
>
>
>
>     On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net
>     <mailto:boris.feld@octobus.net>> wrote:
>
>         # HG changeset patch
>         # User Boris Feld <boris.feld@octobus.net
>         <mailto:boris.feld@octobus.net>>
>         # Date 1539697680 -7200
>         #      Tue Oct 16 15:48:00 2018 +0200
>         # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>         # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>         # EXP-Topic archived-phase-UX
>         # Available At https://bitbucket.org/octobus/mercurial-devel/
>         #              hg pull
>         https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>         strip: introduce a soft strip option
>
>         This is the first user-accessible way to use the archived
>         phase introduced in
>         4.8. This implements a feature implemented during the
>         Stockholm sprint. The
>         archived phase behave as stripping, changesets are no longer
>         accessible, but
>         pulling/unbundling them will make then reappear. The only
>         notable difference
>         is that unlike hard stripping, soft stripping does not affect
>         obsmarkers.
>
>         Adding flag to strip is a good way to provide access to the
>         feature without
>         taking a too big risk on the final UI we want.
>
>         The next changeset will make use of the archived phase for
>         history rewriting
>         command. However, having a way to manually trigger the feature
>         first seemed
>         better.
>
>         Using the archived phase is faster and less traumatic for the
>         repository.
>
>
> I looked at test-strip.t and was unable to found anything specific to
> strip implementation. Can we have a case for soft-stripping in that test?
The strip --soft feature is tested in tests/test-phase-archived.t
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Pulkit Goyal - Jan. 4, 2019, 1:09 p.m.
On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf@durin42.com> wrote:

>
>
> > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net>
> wrote:
> > # HG changeset patch
> > # User Boris Feld <boris.feld@octobus.net>
> > # Date 1539697680 -7200
> > #      Tue Oct 16 15:48:00 2018 +0200
> > # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
> > # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
> > # EXP-Topic archived-phase-UX
> > # Available At https://bitbucket.org/octobus/mercurial-devel/
> > #              hg pull https://bitbucket.org/octobus/mercurial-devel/
> -r a82909c0da7c
> > strip: introduce a soft strip option
> >
> > This is the first user-accessible way to use the archived phase
> introduced in
> > 4.8. This implements a feature implemented during the Stockholm sprint.
> The
> > archived phase behave as stripping, changesets are no longer accessible,
> but
> > pulling/unbundling them will make then reappear. The only notable
> difference
> > is that unlike hard stripping, soft stripping does not affect obsmarkers.
>
> I’m not thrilled with this: I had envisioned the archived state as not
> full of garbage, but full of things that might merit revisiting some day.
> When I strip (or prune it) it’s usually a dead end, whereas I’d like a way
> to say “this isn’t interesting now, but it might be again some day”.
>
> I have no idea if I’m in the minority, and I know this is very late
> feedback (because of the holidays I haven’t been at a computer much) but
> hopefully it’s useful.


Interesting idea.

According to my understanding of discussion happened during sprint, we want
to use phases to make strip command and stripping less bad. I like that
goal and very much want us to move in that direction.

Talking about your idea, we might need a phase for things which merit
revisiting someday. Do you mean that archived phase should be used for that
and we should use some other phase for stripping?
Augie Fackler - Jan. 7, 2019, 9:19 p.m.
> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit@gmail.com> wrote:
> 
> 
> 
> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf@durin42.com <mailto:raf@durin42.com>> wrote:
> 
> 
> > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com <mailto:7895pulkit@gmail.com>> wrote:
> > 
> > 
> > 
> > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net <mailto:boris.feld@octobus.net>> wrote:
> > # HG changeset patch
> > # User Boris Feld <boris.feld@octobus.net <mailto:boris.feld@octobus.net>>
> > # Date 1539697680 -7200
> > #      Tue Oct 16 15:48:00 2018 +0200
> > # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
> > # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
> > # EXP-Topic archived-phase-UX
> > # Available At https://bitbucket.org/octobus/mercurial-devel/ <https://bitbucket.org/octobus/mercurial-devel/>
> > #              hg pull https://bitbucket.org/octobus/mercurial-devel/ <https://bitbucket.org/octobus/mercurial-devel/> -r a82909c0da7c
> > strip: introduce a soft strip option
> > 
> > This is the first user-accessible way to use the archived phase introduced in
> > 4.8. This implements a feature implemented during the Stockholm sprint. The
> > archived phase behave as stripping, changesets are no longer accessible, but
> > pulling/unbundling them will make then reappear. The only notable difference
> > is that unlike hard stripping, soft stripping does not affect obsmarkers.
> 
> I’m not thrilled with this: I had envisioned the archived state as not full of garbage, but full of things that might merit revisiting some day. When I strip (or prune it) it’s usually a dead end, whereas I’d like a way to say “this isn’t interesting now, but it might be again some day”.
> 
> I have no idea if I’m in the minority, and I know this is very late feedback (because of the holidays I haven’t been at a computer much) but hopefully it’s useful.
> 
> Interesting idea.
> 
> According to my understanding of discussion happened during sprint, we want to use phases to make strip command and stripping less bad. I like that goal and very much want us to move in that direction.
> 
> Talking about your idea, we might need a phase for things which merit revisiting someday. Do you mean that archived phase should be used for that and we should use some other phase for stripping?

Yes, STRIPPED would be more like INTERNAL (all garbage, fine to delete), whereas ARCHIVED would be "please don't delete this, but hide it by default". Does that make sense?

(I fully acknowledge I kind of am asking for a pony here.)
Boris Feld - Jan. 10, 2019, 5:24 p.m.
On 07/01/2019 22:19, Augie Fackler wrote:
>
>
>> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit@gmail.com
>> <mailto:7895pulkit@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf@durin42.com
>> <mailto:raf@durin42.com>> wrote:
>>
>>
>>
>>     > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com
>>     <mailto:7895pulkit@gmail.com>> wrote:
>>     >
>>     >
>>     >
>>     > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld
>>     <boris.feld@octobus.net <mailto:boris.feld@octobus.net>> wrote:
>>     > # HG changeset patch
>>     > # User Boris Feld <boris.feld@octobus.net
>>     <mailto:boris.feld@octobus.net>>
>>     > # Date 1539697680 -7200
>>     > #      Tue Oct 16 15:48:00 2018 +0200
>>     > # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>>     > # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>>     > # EXP-Topic archived-phase-UX
>>     > # Available At https://bitbucket.org/octobus/mercurial-devel/
>>     > #              hg pull
>>     https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>>     > strip: introduce a soft strip option
>>     >
>>     > This is the first user-accessible way to use the archived phase
>>     introduced in
>>     > 4.8. This implements a feature implemented during the Stockholm
>>     sprint. The
>>     > archived phase behave as stripping, changesets are no longer
>>     accessible, but
>>     > pulling/unbundling them will make then reappear. The only
>>     notable difference
>>     > is that unlike hard stripping, soft stripping does not affect
>>     obsmarkers.
>>
>>     I’m not thrilled with this: I had envisioned the archived state
>>     as not full of garbage, but full of things that might merit
>>     revisiting some day. When I strip (or prune it) it’s usually a
>>     dead end, whereas I’d like a way to say “this isn’t interesting
>>     now, but it might be again some day”.
>>
>>     I have no idea if I’m in the minority, and I know this is very
>>     late feedback (because of the holidays I haven’t been at a
>>     computer much) but hopefully it’s useful.
>>
>>
>> Interesting idea.
>>
>> According to my understanding of discussion happened during sprint,
>> we want to use phases to make strip command and stripping less bad. I
>> like that goal and very much want us to move in that direction.
>>
>> Talking about your idea, we might need a phase for things which merit
>> revisiting someday. Do you mean that archived phase should be used
>> for that and we should use some other phase for stripping?
>
> Yes, STRIPPED would be more like INTERNAL (all garbage, fine to
> delete), whereas ARCHIVED would be "please don't delete this, but hide
> it by default". Does that make sense?
>
> (I fully acknowledge I kind of am asking for a pony here.)
The INTERNAL phase is for internal use only to hide the byproducts
commits of hg commands (eg shelve). No user-created commit should end up
in the INTERNAL phase.

Using the ARCHIVED phase now is a nice trick to make history rewriting
commands faster until obsolescence is activated by default. Once
obsolescence is activated by default, the pony you described should be
yours. In the mean-time, I would prefer not to introduce a third phase
that we would have around forever.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Augie Fackler - Jan. 10, 2019, 6:49 p.m.
> On Jan 10, 2019, at 12:24, Boris FELD <boris.feld@octobus.net> wrote:
> 
> 
> 
> On 07/01/2019 22:19, Augie Fackler wrote:
>> 
>> 
>>> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf@durin42.com> wrote:
>>> 
>>> 
>>> > On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com> wrote:
>>> > 
>>> > 
>>> > 
>>> > On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net> wrote:
>>> > # HG changeset patch
>>> > # User Boris Feld <boris.feld@octobus.net>
>>> > # Date 1539697680 -7200
>>> > #      Tue Oct 16 15:48:00 2018 +0200
>>> > # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>>> > # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>>> > # EXP-Topic archived-phase-UX
>>> > # Available At https://bitbucket.org/octobus/mercurial-devel/
>>> > #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>>> > strip: introduce a soft strip option
>>> > 
>>> > This is the first user-accessible way to use the archived phase introduced in
>>> > 4.8. This implements a feature implemented during the Stockholm sprint. The
>>> > archived phase behave as stripping, changesets are no longer accessible, but
>>> > pulling/unbundling them will make then reappear. The only notable difference
>>> > is that unlike hard stripping, soft stripping does not affect obsmarkers.
>>> 
>>> I’m not thrilled with this: I had envisioned the archived state as not full of garbage, but full of things that might merit revisiting some day. When I strip (or prune it) it’s usually a dead end, whereas I’d like a way to say “this isn’t interesting now, but it might be again some day”.
>>> 
>>> I have no idea if I’m in the minority, and I know this is very late feedback (because of the holidays I haven’t been at a computer much) but hopefully it’s useful.
>>> 
>>> Interesting idea.
>>> 
>>> According to my understanding of discussion happened during sprint, we want to use phases to make strip command and stripping less bad. I like that goal and very much want us to move in that direction.
>>> 
>>> Talking about your idea, we might need a phase for things which merit revisiting someday. Do you mean that archived phase should be used for that and we should use some other phase for stripping?
>> 
>> Yes, STRIPPED would be more like INTERNAL (all garbage, fine to delete), whereas ARCHIVED would be "please don't delete this, but hide it by default". Does that make sense?
>> 
>> (I fully acknowledge I kind of am asking for a pony here.)
> The INTERNAL phase is for internal use only to hide the byproducts commits of hg commands (eg shelve). No user-created commit should end up in the INTERNAL phase.
> 
> Using the ARCHIVED phase now is a nice trick to make history rewriting commands faster until obsolescence is activated by default. Once obsolescence is activated by default, the pony you described should be yours. In the mean-time, I would prefer not to introduce a third phase that we would have around forever.

I guess I was confused by the placement of this functionality in the `strip` command then. I'm not sure where else to put it (given that we already burned the `archive` name for making zipfiles etc.) but maybe strip (-> destroy this change please) is a suboptimal place.

I guess if we mark it as experimental so we can move it later, that seems fine.

(Do I have a more correct understanding now? I think I was talking past the intent here...)

>> 
>> _______________________________________________
>> Mercurial-devel mailing list
>> 
>> Mercurial-devel@mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Boris Feld - Jan. 18, 2019, 12:53 p.m.
On 10/01/2019 19:49, Augie Fackler wrote:
>
>> On Jan 10, 2019, at 12:24, Boris FELD <boris.feld@octobus.net> wrote:
>>
>>
>>
>> On 07/01/2019 22:19, Augie Fackler wrote:
>>>
>>>> On Jan 4, 2019, at 08:09, Pulkit Goyal <7895pulkit@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jan 4, 2019 at 4:31 AM Augie Fackler <raf@durin42.com> wrote:
>>>>
>>>>
>>>>> On Jan 3, 2019, at 10:23 AM, Pulkit Goyal <7895pulkit@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net> wrote:
>>>>> # HG changeset patch
>>>>> # User Boris Feld <boris.feld@octobus.net>
>>>>> # Date 1539697680 -7200
>>>>> #      Tue Oct 16 15:48:00 2018 +0200
>>>>> # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>>>>> # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>>>>> # EXP-Topic archived-phase-UX
>>>>> # Available At https://bitbucket.org/octobus/mercurial-devel/
>>>>> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>>>>> strip: introduce a soft strip option
>>>>>
>>>>> This is the first user-accessible way to use the archived phase introduced in
>>>>> 4.8. This implements a feature implemented during the Stockholm sprint. The
>>>>> archived phase behave as stripping, changesets are no longer accessible, but
>>>>> pulling/unbundling them will make then reappear. The only notable difference
>>>>> is that unlike hard stripping, soft stripping does not affect obsmarkers.
>>>> I’m not thrilled with this: I had envisioned the archived state as not full of garbage, but full of things that might merit revisiting some day. When I strip (or prune it) it’s usually a dead end, whereas I’d like a way to say “this isn’t interesting now, but it might be again some day”.
>>>>
>>>> I have no idea if I’m in the minority, and I know this is very late feedback (because of the holidays I haven’t been at a computer much) but hopefully it’s useful.
>>>>
>>>> Interesting idea.
>>>>
>>>> According to my understanding of discussion happened during sprint, we want to use phases to make strip command and stripping less bad. I like that goal and very much want us to move in that direction.
>>>>
>>>> Talking about your idea, we might need a phase for things which merit revisiting someday. Do you mean that archived phase should be used for that and we should use some other phase for stripping?
>>> Yes, STRIPPED would be more like INTERNAL (all garbage, fine to delete), whereas ARCHIVED would be "please don't delete this, but hide it by default". Does that make sense?
>>>
>>> (I fully acknowledge I kind of am asking for a pony here.)
>> The INTERNAL phase is for internal use only to hide the byproducts commits of hg commands (eg shelve). No user-created commit should end up in the INTERNAL phase.
>>
>> Using the ARCHIVED phase now is a nice trick to make history rewriting commands faster until obsolescence is activated by default. Once obsolescence is activated by default, the pony you described should be yours. In the mean-time, I would prefer not to introduce a third phase that we would have around forever.
> I guess I was confused by the placement of this functionality in the `strip` command then. I'm not sure where else to put it (given that we already burned the `archive` name for making zipfiles etc.) but maybe strip (-> destroy this change please) is a suboptimal place.
>
> I guess if we mark it as experimental so we can move it later, that seems fine.
>
> (Do I have a more correct understanding now? I think I was talking past the intent here...)
Yes you have the correct understanding, the archived phase is designed
to be used in-place of obs-markers when obs-markers are disabled.

When activating the experimental option
`experimental.cleanup-as-archived` it will be transparent for users and
rewriting commands.

All the code and options are experimental so we can modify it as we want
in the future.


>
>>> _______________________________________________
>>> Mercurial-devel mailing list
>>>
>>> Mercurial-devel@mercurial-scm.org
>>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Boris Feld - Jan. 23, 2019, 2:11 p.m.
On 04/01/2019 03:50, Boris FELD wrote:
> On 03/01/2019 16:23, Pulkit Goyal wrote:
>>
>>
>> On Thu, Jan 3, 2019 at 4:14 AM Boris Feld <boris.feld@octobus.net
>> <mailto:boris.feld@octobus.net>> wrote:
>>
>>     # HG changeset patch
>>     # User Boris Feld <boris.feld@octobus.net
>>     <mailto:boris.feld@octobus.net>>
>>     # Date 1539697680 -7200
>>     #      Tue Oct 16 15:48:00 2018 +0200
>>     # Node ID a82909c0da7cc07ea1a46690ffc08e45ebc14af6
>>     # Parent  65488c7d2e933cdb2ab1c36b3887a8a67a24fc60
>>     # EXP-Topic archived-phase-UX
>>     # Available At https://bitbucket.org/octobus/mercurial-devel/
>>     #              hg pull
>>     https://bitbucket.org/octobus/mercurial-devel/ -r a82909c0da7c
>>     strip: introduce a soft strip option
>>
>>     This is the first user-accessible way to use the archived phase
>>     introduced in
>>     4.8. This implements a feature implemented during the Stockholm
>>     sprint. The
>>     archived phase behave as stripping, changesets are no longer
>>     accessible, but
>>     pulling/unbundling them will make then reappear. The only notable
>>     difference
>>     is that unlike hard stripping, soft stripping does not affect
>>     obsmarkers.
>>
>>     Adding flag to strip is a good way to provide access to the
>>     feature without
>>     taking a too big risk on the final UI we want.
>>
>>     The next changeset will make use of the archived phase for
>>     history rewriting
>>     command. However, having a way to manually trigger the feature
>>     first seemed
>>     better.
>>
>>     Using the archived phase is faster and less traumatic for the
>>     repository.
>>
>>     diff --git a/hgext/strip.py b/hgext/strip.py
>>     --- a/hgext/strip.py
>>     +++ b/hgext/strip.py
>>     @@ -76,7 +76,8 @@ def _findupdatetarget(repo, nodes):
>>
>>          return unode
>>
>>     -def strip(ui, repo, revs, update=True, backup=True, force=None,
>>     bookmarks=None):
>>     +def strip(ui, repo, revs, update=True, backup=True, force=None,
>>     bookmarks=None,
>>     +          soft=False):
>>          with repo.wlock(), repo.lock():
>>
>>              if update:
>>     @@ -85,7 +86,10 @@ def strip(ui, repo, revs, update=True, b
>>                  hg.clean(repo, urev)
>>                  repo.dirstate.write(repo.currenttransaction())
>>
>>     -        repair.strip(ui, repo, revs, backup)
>>     +        if soft:
>>     +            repair.softstrip(ui, repo, revs, backup)
>>     +        else:
>>     +            repair.strip(ui, repo, revs, backup)
>>
>>              repomarks = repo._bookmarks
>>              if bookmarks:
>>     @@ -110,7 +114,10 @@ def strip(ui, repo, revs, update=True, b
>>                ('k', 'keep', None, _("do not modify working directory
>>     during "
>>                                      "strip")),
>>                ('B', 'bookmark', [], _("remove revs only reachable
>>     from given"
>>     -                                  " bookmark"), _('BOOKMARK'))],
>>     +                                  " bookmark"), _('BOOKMARK')),
>>     +          ('', 'soft', [],
>>
>>
>> Do we plan to accept arguments with `--soft`? If not, the default
>> value should be None.
> Good catch, not sure how it ends up with []. Will fix in V2. 

Somehow, the V2 never made it to the list but the series is ready. I
just sent them in the list.

Do we want to put them on 4.9 or 5.0?

>>
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel@mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Patch

diff --git a/hgext/strip.py b/hgext/strip.py
--- a/hgext/strip.py
+++ b/hgext/strip.py
@@ -76,7 +76,8 @@  def _findupdatetarget(repo, nodes):
 
     return unode
 
-def strip(ui, repo, revs, update=True, backup=True, force=None, bookmarks=None):
+def strip(ui, repo, revs, update=True, backup=True, force=None, bookmarks=None,
+          soft=False):
     with repo.wlock(), repo.lock():
 
         if update:
@@ -85,7 +86,10 @@  def strip(ui, repo, revs, update=True, b
             hg.clean(repo, urev)
             repo.dirstate.write(repo.currenttransaction())
 
-        repair.strip(ui, repo, revs, backup)
+        if soft:
+            repair.softstrip(ui, repo, revs, backup)
+        else:
+            repair.strip(ui, repo, revs, backup)
 
         repomarks = repo._bookmarks
         if bookmarks:
@@ -110,7 +114,10 @@  def strip(ui, repo, revs, update=True, b
           ('k', 'keep', None, _("do not modify working directory during "
                                 "strip")),
           ('B', 'bookmark', [], _("remove revs only reachable from given"
-                                  " bookmark"), _('BOOKMARK'))],
+                                  " bookmark"), _('BOOKMARK')),
+          ('', 'soft', [],
+          _("simply drop changesets from visible history (EXPERIMENTAL)")),
+         ],
           _('hg strip [-k] [-f] [-B bookmark] [-r] REV...'),
           helpcategory=command.CATEGORY_MAINTENANCE)
 def stripcmd(ui, repo, *revs, **opts):
@@ -235,6 +242,7 @@  def stripcmd(ui, repo, *revs, **opts):
 
 
         strip(ui, repo, revs, backup=backup, update=update,
-              force=opts.get('force'), bookmarks=bookmarks)
+              force=opts.get('force'), bookmarks=bookmarks,
+              soft=opts['soft'])
 
     return 0
diff --git a/mercurial/repair.py b/mercurial/repair.py
--- a/mercurial/repair.py
+++ b/mercurial/repair.py
@@ -252,6 +252,24 @@  def strip(ui, repo, nodelist, backup=Tru
     # extensions can use it
     return backupfile
 
+def softstrip(ui, repo, nodelist, backup=True, topic='backup'):
+    """perform a "soft" strip using the archived phase"""
+    tostrip = [c.node() for c in repo.set('sort(%ln::)', nodelist)]
+    if not tostrip:
+        return None
+
+    newbmtarget, updatebm = _bookmarkmovements(repo, tostrip)
+    if backup:
+        node = tostrip[0]
+        backupfile = _createstripbackup(repo, tostrip, node, topic)
+
+    with repo.transaction('strip') as tr:
+        phases.retractboundary(repo, tr, phases.archived, tostrip)
+        bmchanges = [(m, repo[newbmtarget].node()) for m in updatebm]
+        repo._bookmarks.applychanges(repo, tr, bmchanges)
+    return backupfile
+
+
 def _bookmarkmovements(repo, tostrip):
     # compute necessary bookmark movement
     bm = repo._bookmarks
diff --git a/tests/test-phase-archived.t b/tests/test-phase-archived.t
new file mode 100644
--- /dev/null
+++ b/tests/test-phase-archived.t
@@ -0,0 +1,77 @@ 
+=========================================================
+Test features and behaviors related to the archived phase
+=========================================================
+
+  $ cat << EOF >> $HGRCPATH
+  > [format]
+  > internal-phase=yes
+  > [extensions]
+  > strip=
+  > [experimental]
+  > EOF
+
+  $ hg init repo
+  $ cd repo
+  $ echo  root > a
+  $ hg add a
+  $ hg ci -m 'root'
+
+Test that bundle can unarchive a changeset
+------------------------------------------
+
+  $ echo foo >> a
+  $ hg st
+  M a
+  $ hg ci -m 'unbundletesting'
+  $ hg log -G
+  @  changeset:   1:883aadbbf309
+  |  tag:         tip
+  |  user:        test
+  |  date:        Thu Jan 01 00:00:00 1970 +0000
+  |  summary:     unbundletesting
+  |
+  o  changeset:   0:c1863a3840c6
+     user:        test
+     date:        Thu Jan 01 00:00:00 1970 +0000
+     summary:     root
+  
+  $ hg strip --soft --rev '.'
+  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  saved backup bundle to $TESTTMP/repo/.hg/strip-backup/883aadbbf309-efc55adc-backup.hg
+  $ hg log -G
+  @  changeset:   0:c1863a3840c6
+     tag:         tip
+     user:        test
+     date:        Thu Jan 01 00:00:00 1970 +0000
+     summary:     root
+  
+  $ hg log -G --hidden
+  o  changeset:   1:883aadbbf309
+  |  tag:         tip
+  |  user:        test
+  |  date:        Thu Jan 01 00:00:00 1970 +0000
+  |  summary:     unbundletesting
+  |
+  @  changeset:   0:c1863a3840c6
+     user:        test
+     date:        Thu Jan 01 00:00:00 1970 +0000
+     summary:     root
+  
+  $ hg unbundle .hg/strip-backup/883aadbbf309-efc55adc-backup.hg
+  adding changesets
+  adding manifests
+  adding file changes
+  added 0 changesets with 0 changes to 1 files
+  (run 'hg update' to get a working copy)
+  $ hg log -G
+  o  changeset:   1:883aadbbf309
+  |  tag:         tip
+  |  user:        test
+  |  date:        Thu Jan 01 00:00:00 1970 +0000
+  |  summary:     unbundletesting
+  |
+  @  changeset:   0:c1863a3840c6
+     user:        test
+     date:        Thu Jan 01 00:00:00 1970 +0000
+     summary:     root
+