[PATCH] shelve: always backup shelves instead of deleting them

[Durham Goode]

On 6/26/15, 4:53 PM, "Matt Mackall" <mpm at selenic.com> wrote:

>On Fri, 2015-06-26 at 17:42 +0000, Durham Goode wrote:
>> 
>> On 6/26/15, 9:05 AM, "Colin Chan" <colinchan at fb.com> wrote:
>> 
>> >
>> >On 06/26/2015 03:14 AM, Pierre-Yves David wrote:
>> >>
>> >>
>> >> On 06/24/2015 03:54 PM, Durham Goode wrote:
>> >>>
>> >>>
>> >>> On 6/24/15, 3:47 PM, "Pierre-Yves David"
>> >>><pierre-yves.david at ens-lyon.org>
>> >>> wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>> On 06/24/2015 12:16 PM, Colin Chan wrote:
>> >>>>> # HG changeset patch
>> >>>>> # User Colin Chan <colinchan at fb.com>
>> >>>>> # Date 1434989752 25200
>> >>>>> #      Mon Jun 22 09:15:52 2015 -0700
>> >>>>> # Node ID 7a02a3b3941cb62203b6efc145e58c543e8b8909
>> >>>>> # Parent  7fdd1782fc4ee9da87d8af13e806dc9055db2c38
>> >>>>> shelve: always backup shelves instead of deleting them
>> >>>>>
>> >>>>> Instead of being deleted, shelve files are now moved into the
>> >>>>> .hg/shelve-backup directory. This is designed to be very similar
>>to
>> >>>>>how
>> >>>>> strip
>> >>>>> saves backpus into .ht/strip-backup. The goal is to prevent data
>>loss
>> >>>>> especially
>> >>>>> when using unshelve (e.g.,
>> >>>>>http://bz.selenic.com/show_bug.cgi?id=4732)
>> >>>>> at the
>> >>>>> expense of using more disk space over time.
>> >>>>
>> >>>> This changes seems strange to me, We should never delete a shelve
>> >>>>until
>> >>>> the whole unshelving process is done. It seems to be the current
>> >>>>intend
>> >>>> of the code, if it happen to currently not be the case, it should
>>be
>> >>>> easy to fix.
>> >>>
>> >>> We have had users do dumb things, where they do an unshelve, then
>>get
>> >>> confused (or mercurial does something weird and unexpected) and they
>> >>> unintentionally overwrite their working copy.  Shelve gives us an
>> >>> opportunity to store a checkpoint of their work permanently, so I
>> >>> think we
>> >>> should do this.
>> >>
>> >> Shelve is expected to be a very light weight operation. The shelve
>> >> bundle can contains a lot of heavy data (because it contains any
>>draft
>> >> changesets under the wdir when we shelve). I do not think we can
>> >> reasonably backup all this by default in all cases.
>> 
>> We already do store every draft commit anyone ever made, either in the
>> repo, or in the strip-backups. This shelve-backup seems like it would be
>> significantly smaller compared to that.
>
>That's not always true. We recently had a user complain that a single
>shelve was over a gigabyte. That was because he had a local-only repo
>that was all draft (because he never pushed it anywhere). He didn't
>necessarily use any history editing.
>
>If we had bundlepatches rather than our current trick, they could be a
>lot lighter.

What if we only kept the backup shelves around for a limited time?  Like,
every time we do a shelve/unshelve we delete any shelve-backups older than
a month.  That provides the recoverability behavior, without the permanent
growth.