Patchwork revert: allow configuring the .orig file location

login
register
mail settings
Submitter Zainab Zahid
Date Aug. 11, 2015, 4:07 a.m.
Message ID <92707bacbef0292af147.1439266033@zzahid-mbp1.local>
Download mbox | patch
Permalink /patch/10190/
State Superseded
Commit 080276d377d9131c1fd4f538f7def95d669eba9f
Delegated to: Augie Fackler
Headers show

Comments

Zainab Zahid - Aug. 11, 2015, 4:07 a.m.
# HG changeset patch
# User Zainab Zahid <zzahid@fb.com>
# Date 1438967257 25200
#      Fri Aug 07 10:07:37 2015 -0700
# Node ID 92707bacbef0292af14701d0e812cbbf7239f754
# Parent  eabba9c75061254ff62827f92df0f32491c74b3d
revert: allow configuring the .orig file location

Adding support for a 'revertbackuppath' entry under section [ui] in the configuration file.
It allows user to specify where .orig files should be stored relative to the repo.
In case of no revertbackuppath entry, we fallback to the default behaviour of moving old
versions of a file to a file name <oldpath>.orig. This will prevent cluttering of the
 working copy.
Augie Fackler - Aug. 11, 2015, 8:02 p.m.
On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
> # HG changeset patch
> # User Zainab Zahid <zzahid@fb.com>
> # Date 1438967257 25200
> #      Fri Aug 07 10:07:37 2015 -0700
> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
> revert: allow configuring the .orig file location

Why? Is having .orig in ignores insufficient?

(I'm -0 on this patch because I can't think of a VCS tool that offers
it, and everyone's been fine with that for the past N decades...)

>
> Adding support for a 'revertbackuppath' entry under section [ui] in the configuration file.
> It allows user to specify where .orig files should be stored relative to the repo.
> In case of no revertbackuppath entry, we fallback to the default behaviour of moving old
> versions of a file to a file name <oldpath>.orig. This will prevent cluttering of the
>  working copy.
>
> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
> --- a/mercurial/cmdutil.py
> +++ b/mercurial/cmdutil.py
> @@ -3037,7 +3037,7 @@
>                      xlist.append(abs)
>                      if dobackup and (backup <= dobackup
>                                       or wctx[abs].cmp(ctx[abs])):
> -                            bakname = "%s.orig" % rel
> +                            bakname = _getrevertbackuppath(ui, repo, rel)
>                              ui.note(_('saving current version of %s as %s\n') %
>                                      (rel, bakname))
>                              if not opts.get('dry_run'):
> @@ -3069,6 +3069,26 @@
>      finally:
>          wlock.release()
>
> +def _getrevertbackuppath(ui, repo, filepath):
> +    '''customize where .orig files are created
> +
> +    Fetch user defined path from config file: [ui] revertbackuppath = <path>
> +    Fall back to default (filepath) if not specified
> +    '''
> +    revertbackuppath = ui.config('ui', 'revertbackuppath', None)
> +    if revertbackuppath is None:
> +        return filepath + ".orig"
> +
> +    filepathfromroot = os.path.relpath(filepath, start=repo.root)
> +    revertpath = repo.wjoin(revertbackuppath, filepathfromroot);
> +
> +    revertbackupdir = repo.vfs.dirname(revertpath)
> +    if not repo.vfs.exists(revertbackupdir):
> +        ui.note(_('creating directory: %s\n') % revertbackupdir)
> +        util.makedirs(revertbackupdir)
> +
> +    return revertpath + ".orig"
> +
>  def _revertprefetch(repo, ctx, *files):
>      """Let extension changing the storage layer prefetch content"""
>      pass
> diff --git a/tests/test-revert.t b/tests/test-revert.t
> --- a/tests/test-revert.t
> +++ b/tests/test-revert.t
> @@ -86,6 +86,23 @@
>    saving current version of e as e.orig
>    reverting e
>
> +Test creation of backup (.orig) file in configured file location
> +----------------------------------------------------------------
> +
> +  $ cat $HGRCPATH > hgrc_bak
> +  $ cat >> $HGRCPATH << EOF
> +  > [ui]
> +  > revertbackuppath= .hg/origbackups
> +  > EOF
> +  $ echo z > e
> +  $ hg revert --all -v
> +  creating directory: $TESTTMP/repo/.hg/origbackups
> +  saving current version of e as $TESTTMP/repo/.hg/origbackups/e.orig
> +  reverting e
> +  $ cp $TESTTMP/repo/.hg/origbackups/e.orig .
> +  $ cp hgrc_bak $HGRCPATH
> +  $ rm hgrc_bak
> +
>  revert on clean file (no change)
>  --------------------------------
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Durham Goode - Aug. 12, 2015, 4:25 a.m.
On 8/11/15 1:02 PM, Augie Fackler wrote:
> On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
>> # HG changeset patch
>> # User Zainab Zahid <zzahid@fb.com>
>> # Date 1438967257 25200
>> #      Fri Aug 07 10:07:37 2015 -0700
>> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
>> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
>> revert: allow configuring the .orig file location
> Why? Is having .orig in ignores insufficient?
>
> (I'm -0 on this patch because I can't think of a VCS tool that offers
> it, and everyone's been fine with that for the past N decades...)
We get lots of complaints that .orig files mess with tools, IDE's, 
greps, etc.  It seems straight forward enough to dump them elsewhere.
>
>> Adding support for a 'revertbackuppath' entry under section [ui] in the configuration file.
>> It allows user to specify where .orig files should be stored relative to the repo.
>> In case of no revertbackuppath entry, we fallback to the default behaviour of moving old
>> versions of a file to a file name <oldpath>.orig. This will prevent cluttering of the
>>   working copy.
>>
>> diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
>> --- a/mercurial/cmdutil.py
>> +++ b/mercurial/cmdutil.py
>> @@ -3037,7 +3037,7 @@
>>                       xlist.append(abs)
>>                       if dobackup and (backup <= dobackup
>>                                        or wctx[abs].cmp(ctx[abs])):
>> -                            bakname = "%s.orig" % rel
>> +                            bakname = _getrevertbackuppath(ui, repo, rel)
>>                               ui.note(_('saving current version of %s as %s\n') %
>>                                       (rel, bakname))
>>                               if not opts.get('dry_run'):
>> @@ -3069,6 +3069,26 @@
>>       finally:
>>           wlock.release()
>>
>> +def _getrevertbackuppath(ui, repo, filepath):
>> +    '''customize where .orig files are created
>> +
>> +    Fetch user defined path from config file: [ui] revertbackuppath = <path>
>> +    Fall back to default (filepath) if not specified
>> +    '''
>> +    revertbackuppath = ui.config('ui', 'revertbackuppath', None)
>> +    if revertbackuppath is None:
>> +        return filepath + ".orig"
>> +
>> +    filepathfromroot = os.path.relpath(filepath, start=repo.root)
>> +    revertpath = repo.wjoin(revertbackuppath, filepathfromroot);
>> +
>> +    revertbackupdir = repo.vfs.dirname(revertpath)
>> +    if not repo.vfs.exists(revertbackupdir):
>> +        ui.note(_('creating directory: %s\n') % revertbackupdir)
>> +        util.makedirs(revertbackupdir)
>> +
>> +    return revertpath + ".orig"
>> +
>>   def _revertprefetch(repo, ctx, *files):
>>       """Let extension changing the storage layer prefetch content"""
>>       pass
>> diff --git a/tests/test-revert.t b/tests/test-revert.t
>> --- a/tests/test-revert.t
>> +++ b/tests/test-revert.t
>> @@ -86,6 +86,23 @@
>>     saving current version of e as e.orig
>>     reverting e
>>
>> +Test creation of backup (.orig) file in configured file location
>> +----------------------------------------------------------------
>> +
>> +  $ cat $HGRCPATH > hgrc_bak
>> +  $ cat >> $HGRCPATH << EOF
>> +  > [ui]
>> +  > revertbackuppath= .hg/origbackups
>> +  > EOF
>> +  $ echo z > e
>> +  $ hg revert --all -v
>> +  creating directory: $TESTTMP/repo/.hg/origbackups
>> +  saving current version of e as $TESTTMP/repo/.hg/origbackups/e.orig
>> +  reverting e
>> +  $ cp $TESTTMP/repo/.hg/origbackups/e.orig .
>> +  $ cp hgrc_bak $HGRCPATH
>> +  $ rm hgrc_bak
>> +
>>   revert on clean file (no change)
>>   --------------------------------
>>
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel@selenic.com
>> https://selenic.com/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Augie Fackler - Aug. 12, 2015, 3:09 p.m.
On Wed, Aug 12, 2015 at 12:25 AM, Durham Goode <durham@fb.com> wrote:
> On 8/11/15 1:02 PM, Augie Fackler wrote:
>>
>> On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
>>>
>>> # HG changeset patch
>>> # User Zainab Zahid <zzahid@fb.com>
>>> # Date 1438967257 25200
>>> #      Fri Aug 07 10:07:37 2015 -0700
>>> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
>>> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
>>> revert: allow configuring the .orig file location
>>
>> Why? Is having .orig in ignores insufficient?
>>
>> (I'm -0 on this patch because I can't think of a VCS tool that offers
>> it, and everyone's been fine with that for the past N decades...)
>
> We get lots of complaints that .orig files mess with tools, IDE's, greps,
> etc.  It seems straight forward enough to dump them elsewhere.

As a fraction of users, how bad is this? If it's 1% of your userbase
or some other low level, I'm inclined to tell them to suck it up, as
every feature introduces some extra maintenance complexity. Have you
pointed them to 'hg revert --no-backup'?
Gregory Szorc - Aug. 12, 2015, 4:07 p.m.
Is there a config option to disable creation of .orig files? Or, do I need to create aliases to add --no-backup to every command?

> On Aug 12, 2015, at 08:09, Augie Fackler <raf@durin42.com> wrote:
> 
>> On Wed, Aug 12, 2015 at 12:25 AM, Durham Goode <durham@fb.com> wrote:
>>> On 8/11/15 1:02 PM, Augie Fackler wrote:
>>> 
>>>> On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
>>>> 
>>>> # HG changeset patch
>>>> # User Zainab Zahid <zzahid@fb.com>
>>>> # Date 1438967257 25200
>>>> #      Fri Aug 07 10:07:37 2015 -0700
>>>> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
>>>> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
>>>> revert: allow configuring the .orig file location
>>> 
>>> Why? Is having .orig in ignores insufficient?
>>> 
>>> (I'm -0 on this patch because I can't think of a VCS tool that offers
>>> it, and everyone's been fine with that for the past N decades...)
>> 
>> We get lots of complaints that .orig files mess with tools, IDE's, greps,
>> etc.  It seems straight forward enough to dump them elsewhere.
> 
> As a fraction of users, how bad is this? If it's 1% of your userbase
> or some other low level, I'm inclined to tell them to suck it up, as
> every feature introduces some extra maintenance complexity. Have you
> pointed them to 'hg revert --no-backup'?
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Martin von Zweigbergk - Aug. 12, 2015, 4:28 p.m.
Besides the anti-recommended [defaults] section, I think you have to create
an alias for each. But perhaps this is a valid use case for the [defaults]
section? The problem, as I understand it, is if you're running scripts that
expect the .orig file to be created, which seems unlikely in this
particular case.

On Wed, Aug 12, 2015, 09:08 Gregory Szorc <gregory.szorc@gmail.com> wrote:

> Is there a config option to disable creation of .orig files? Or, do I need
> to create aliases to add --no-backup to every command?
>
> > On Aug 12, 2015, at 08:09, Augie Fackler <raf@durin42.com> wrote:
> >
> >> On Wed, Aug 12, 2015 at 12:25 AM, Durham Goode <durham@fb.com> wrote:
> >>> On 8/11/15 1:02 PM, Augie Fackler wrote:
> >>>
> >>>> On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
> >>>>
> >>>> # HG changeset patch
> >>>> # User Zainab Zahid <zzahid@fb.com>
> >>>> # Date 1438967257 25200
> >>>> #      Fri Aug 07 10:07:37 2015 -0700
> >>>> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
> >>>> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
> >>>> revert: allow configuring the .orig file location
> >>>
> >>> Why? Is having .orig in ignores insufficient?
> >>>
> >>> (I'm -0 on this patch because I can't think of a VCS tool that offers
> >>> it, and everyone's been fine with that for the past N decades...)
> >>
> >> We get lots of complaints that .orig files mess with tools, IDE's,
> greps,
> >> etc.  It seems straight forward enough to dump them elsewhere.
> >
> > As a fraction of users, how bad is this? If it's 1% of your userbase
> > or some other low level, I'm inclined to tell them to suck it up, as
> > every feature introduces some extra maintenance complexity. Have you
> > pointed them to 'hg revert --no-backup'?
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel@selenic.com
> > https://selenic.com/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
>
Durham Goode - Aug. 12, 2015, 5 p.m.
On 8/12/15 8:09 AM, Augie Fackler wrote:
> On Wed, Aug 12, 2015 at 12:25 AM, Durham Goode <durham@fb.com> wrote:
>> On 8/11/15 1:02 PM, Augie Fackler wrote:
>>> On Mon, Aug 10, 2015 at 09:07:13PM -0700, Zainab Zahid wrote:
>>>> # HG changeset patch
>>>> # User Zainab Zahid <zzahid@fb.com>
>>>> # Date 1438967257 25200
>>>> #      Fri Aug 07 10:07:37 2015 -0700
>>>> # Node ID 92707bacbef0292af14701d0e812cbbf7239f754
>>>> # Parent  eabba9c75061254ff62827f92df0f32491c74b3d
>>>> revert: allow configuring the .orig file location
>>> Why? Is having .orig in ignores insufficient?
>>>
>>> (I'm -0 on this patch because I can't think of a VCS tool that offers
>>> it, and everyone's been fine with that for the past N decades...)
>> We get lots of complaints that .orig files mess with tools, IDE's, greps,
>> etc.  It seems straight forward enough to dump them elsewhere.
> As a fraction of users, how bad is this? If it's 1% of your userbase
> or some other low level, I'm inclined to tell them to suck it up, as
> every feature introduces some extra maintenance complexity. Have you
> pointed them to 'hg revert --no-backup'?
It's not a large percentage, but then again, the majority of users don't 
give any feedback at all.  When they ask "why can't we just put the orig 
files somewhere else", me answering "suck it up" or "because it adds 
complexity" is kind of an embarrassing response for me for a relatively 
simple issue.

Also, part of what I'm trying to do is set up Mercurial so that the 
defaults (for our users at least) result in the fewest questions for 
us.  This is just one of a number of nagging issues that cause 
questions, and the questions really add up when you onboard hundreds of 
new people each month. This particular case is one where the solution 
has zero downsides for the user, and trivial downsides for us hg developers.

In addition, --no-backup isn't really great since they do want backups, 
just not in their working copy. In fact, I think the refactor this patch 
does (of moving the .orig path creation logic somewhere central) is 
something we want anyway. This way we can reuse that logic elsewhere 
(like in hg update -C, so it wouldn't lose data either).
Augie Fackler - Aug. 12, 2015, 5:11 p.m.
On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham@fb.com> wrote:
>> As a fraction of users, how bad is this? If it's 1% of your userbase
>> or some other low level, I'm inclined to tell them to suck it up, as
>> every feature introduces some extra maintenance complexity. Have you
>> pointed them to 'hg revert --no-backup'?
>
> It's not a large percentage, but then again, the majority of users don't
> give any feedback at all.  When they ask "why can't we just put the orig
> files somewhere else", me answering "suck it up" or "because it adds
> complexity" is kind of an embarrassing response for me for a relatively
> simple issue.

You're asking for a feature that to my knowledge NO version control
system has ever offered. It's also tiptoeing up to the line that will
probably make mpm nervous about scripts breaking (though I'm
personally less worried about that...). I get that it's relatively
simple, but a lot of "relatively simple" things in a complex codepath
(revert counts as one of those just from the reviews I've done for
marmoute!) add up to a nightmare for long-term maintainers.

>
> Also, part of what I'm trying to do is set up Mercurial so that the defaults
> (for our users at least) result in the fewest questions for us.  This is
> just one of a number of nagging issues that cause questions, and the
> questions really add up when you onboard hundreds of new people each month.
> This particular case is one where the solution has zero downsides for the
> user, and trivial downsides for us hg developers.

A FAQ entry would probably also have zero downsides for your users and
have even fewer problems for maintainers.

>
> In addition, --no-backup isn't really great since they do want backups, just
> not in their working copy. In fact, I think the refactor this patch does (of
> moving the .orig path creation logic somewhere central) is something we want
> anyway. This way we can reuse that logic elsewhere (like in hg update -C, so
> it wouldn't lose data either).

Fascinating. Are these users that have never used source control? Or
is there some mysterious feature in another VCS that you could/should
be pointing to as historical evidence for this kind of feature being
worthwhile?

(To be clear: I'm not wholly opposed to this, but I'm completely
baffled by the request given that it's something I've *never once*
heard a complaint about in 8 years of working on hg and 10 years
working on VCS tooling. I'd like to figure out what's going on before
moving the needle too far on new features we can't remove.)
Durham Goode - Aug. 12, 2015, 5:19 p.m.
On 8/12/15 10:11 AM, Augie Fackler wrote:
> On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham@fb.com> wrote:
>>> As a fraction of users, how bad is this? If it's 1% of your userbase
>>> or some other low level, I'm inclined to tell them to suck it up, as
>>> every feature introduces some extra maintenance complexity. Have you
>>> pointed them to 'hg revert --no-backup'?
>> It's not a large percentage, but then again, the majority of users don't
>> give any feedback at all.  When they ask "why can't we just put the orig
>> files somewhere else", me answering "suck it up" or "because it adds
>> complexity" is kind of an embarrassing response for me for a relatively
>> simple issue.
> You're asking for a feature that to my knowledge NO version control
> system has ever offered. It's also tiptoeing up to the line that will
> probably make mpm nervous about scripts breaking (though I'm
> personally less worried about that...). I get that it's relatively
> simple, but a lot of "relatively simple" things in a complex codepath
> (revert counts as one of those just from the reviews I've done for
> marmoute!) add up to a nightmare for long-term maintainers.
I don't actually know how other version control systems handle this, so 
I can't really comment on that.

If it would be less maintenance, I'd be fine making this config a 
boolean that just tells mercurial to dump the orig files in 
.hg/origfile-backups or something.  To take away the security and some 
complexity costs.
>
>> Also, part of what I'm trying to do is set up Mercurial so that the defaults
>> (for our users at least) result in the fewest questions for us.  This is
>> just one of a number of nagging issues that cause questions, and the
>> questions really add up when you onboard hundreds of new people each month.
>> This particular case is one where the solution has zero downsides for the
>> user, and trivial downsides for us hg developers.
> A FAQ entry would probably also have zero downsides for your users and
> have even fewer problems for maintainers.
Unfortunately the percentage of people who read FAQs before asking 
questions is rather low :/
>
>> In addition, --no-backup isn't really great since they do want backups, just
>> not in their working copy. In fact, I think the refactor this patch does (of
>> moving the .orig path creation logic somewhere central) is something we want
>> anyway. This way we can reuse that logic elsewhere (like in hg update -C, so
>> it wouldn't lose data either).
> Fascinating. Are these users that have never used source control? Or
> is there some mysterious feature in another VCS that you could/should
> be pointing to as historical evidence for this kind of feature being
> worthwhile?
I see this feature as being the same as the setting in a build system 
that lets you determine where the build outputs go.  It's just a way of 
saying 'dump your crap over here and out of my way'.

If the feature isn't worthwhile for upstream (I'll wait for Matt to 
chime in), we can just submit a patch that does the refactor, then do an 
internal extension to make it configurable.
>
> (To be clear: I'm not wholly opposed to this, but I'm completely
> baffled by the request given that it's something I've *never once*
> heard a complaint about in 8 years of working on hg and 10 years
> working on VCS tooling. I'd like to figure out what's going on before
> moving the needle too far on new features we can't remove.)
Augie Fackler - Aug. 12, 2015, 8:18 p.m.
On Wed, Aug 12, 2015 at 1:19 PM, Durham Goode <durham@fb.com> wrote:
>
>
> On 8/12/15 10:11 AM, Augie Fackler wrote:
>>
>> On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham@fb.com> wrote:
>>>>
>>>> As a fraction of users, how bad is this? If it's 1% of your userbase
>>>> or some other low level, I'm inclined to tell them to suck it up, as
>>>> every feature introduces some extra maintenance complexity. Have you
>>>> pointed them to 'hg revert --no-backup'?
>>>
>>> It's not a large percentage, but then again, the majority of users don't
>>> give any feedback at all.  When they ask "why can't we just put the orig
>>> files somewhere else", me answering "suck it up" or "because it adds
>>> complexity" is kind of an embarrassing response for me for a relatively
>>> simple issue.
>>
>> You're asking for a feature that to my knowledge NO version control
>> system has ever offered. It's also tiptoeing up to the line that will
>> probably make mpm nervous about scripts breaking (though I'm
>> personally less worried about that...). I get that it's relatively
>> simple, but a lot of "relatively simple" things in a complex codepath
>> (revert counts as one of those just from the reviews I've done for
>> marmoute!) add up to a nightmare for long-term maintainers.
>
> I don't actually know how other version control systems handle this, so I
> can't really comment on that.

It's been pointed out to me that git doesn't store .orig files at all
(yikes). Between that and the comparison between these .orig files and
emacs foo~ droppings, I've been pretty well convinced that this
functionality makes sense (rather than being dangerous.)

That said, this patch appears to only touch the tip of the iceberg:

hg locate 'set:added() or modified() or clean()'  | xargs egrep
--include='*.py'  -- '\.orig['\"\'\]

so it might be helpful to have the config name not mention revert? I
think? Hopefully Matt has some idea on what color we can paint that
part of the bike shed.
Sean Farley - Aug. 13, 2015, 9:27 p.m.
Durham Goode <durham@fb.com> writes:

> On 8/12/15 10:11 AM, Augie Fackler wrote:
>> On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham@fb.com> wrote:
>>>> As a fraction of users, how bad is this? If it's 1% of your userbase
>>>> or some other low level, I'm inclined to tell them to suck it up, as
>>>> every feature introduces some extra maintenance complexity. Have you
>>>> pointed them to 'hg revert --no-backup'?
>>> It's not a large percentage, but then again, the majority of users don't
>>> give any feedback at all.  When they ask "why can't we just put the orig
>>> files somewhere else", me answering "suck it up" or "because it adds
>>> complexity" is kind of an embarrassing response for me for a relatively
>>> simple issue.
>> You're asking for a feature that to my knowledge NO version control
>> system has ever offered. It's also tiptoeing up to the line that will
>> probably make mpm nervous about scripts breaking (though I'm
>> personally less worried about that...). I get that it's relatively
>> simple, but a lot of "relatively simple" things in a complex codepath
>> (revert counts as one of those just from the reviews I've done for
>> marmoute!) add up to a nightmare for long-term maintainers.
> I don't actually know how other version control systems handle this, so 
> I can't really comment on that.
>
> If it would be less maintenance, I'd be fine making this config a 
> boolean that just tells mercurial to dump the orig files in 
> .hg/origfile-backups or something.  To take away the security and some 
> complexity costs.
>>
>>> Also, part of what I'm trying to do is set up Mercurial so that the defaults
>>> (for our users at least) result in the fewest questions for us.  This is
>>> just one of a number of nagging issues that cause questions, and the
>>> questions really add up when you onboard hundreds of new people each month.
>>> This particular case is one where the solution has zero downsides for the
>>> user, and trivial downsides for us hg developers.
>> A FAQ entry would probably also have zero downsides for your users and
>> have even fewer problems for maintainers.
> Unfortunately the percentage of people who read FAQs before asking 
> questions is rather low :/
>>
>>> In addition, --no-backup isn't really great since they do want backups, just
>>> not in their working copy. In fact, I think the refactor this patch does (of
>>> moving the .orig path creation logic somewhere central) is something we want
>>> anyway. This way we can reuse that logic elsewhere (like in hg update -C, so
>>> it wouldn't lose data either).
>> Fascinating. Are these users that have never used source control? Or
>> is there some mysterious feature in another VCS that you could/should
>> be pointing to as historical evidence for this kind of feature being
>> worthwhile?
> I see this feature as being the same as the setting in a build system 
> that lets you determine where the build outputs go.  It's just a way of 
> saying 'dump your crap over here and out of my way'.
>
> If the feature isn't worthwhile for upstream (I'll wait for Matt to 
> chime in), we can just submit a patch that does the refactor, then do an 
> internal extension to make it configurable.

For what it's worth, I've wanted this before but 1) forgot to ask and 2)
didn't have time to implement.
Matt Mackall - Aug. 13, 2015, 9:41 p.m.
On Wed, 2015-08-12 at 16:18 -0400, Augie Fackler wrote:
> On Wed, Aug 12, 2015 at 1:19 PM, Durham Goode <durham@fb.com> wrote:
> >
> >
> > On 8/12/15 10:11 AM, Augie Fackler wrote:
> >>
> >> On Wed, Aug 12, 2015 at 1:00 PM, Durham Goode <durham@fb.com> wrote:
> >>>>
> >>>> As a fraction of users, how bad is this? If it's 1% of your userbase
> >>>> or some other low level, I'm inclined to tell them to suck it up, as
> >>>> every feature introduces some extra maintenance complexity. Have you
> >>>> pointed them to 'hg revert --no-backup'?
> >>>
> >>> It's not a large percentage, but then again, the majority of users don't
> >>> give any feedback at all.  When they ask "why can't we just put the orig
> >>> files somewhere else", me answering "suck it up" or "because it adds
> >>> complexity" is kind of an embarrassing response for me for a relatively
> >>> simple issue.
> >>
> >> You're asking for a feature that to my knowledge NO version control
> >> system has ever offered. It's also tiptoeing up to the line that will
> >> probably make mpm nervous about scripts breaking (though I'm
> >> personally less worried about that...). I get that it's relatively
> >> simple, but a lot of "relatively simple" things in a complex codepath
> >> (revert counts as one of those just from the reviews I've done for
> >> marmoute!) add up to a nightmare for long-term maintainers.
> >
> > I don't actually know how other version control systems handle this, so I
> > can't really comment on that.
> 
> It's been pointed out to me that git doesn't store .orig files at all
> (yikes). Between that and the comparison between these .orig files and
> emacs foo~ droppings, I've been pretty well convinced that this
> functionality makes sense (rather than being dangerous.)
> 
> That said, this patch appears to only touch the tip of the iceberg:
> 
> hg locate 'set:added() or modified() or clean()'  | xargs egrep
> --include='*.py'  -- '\.orig['\"\'\]
> 
> so it might be helpful to have the config name not mention revert? I
> think? Hopefully Matt has some idea on what color we can paint that
> part of the bike shed.

Probably ui.origbackuppath.

Patch

diff --git a/mercurial/cmdutil.py b/mercurial/cmdutil.py
--- a/mercurial/cmdutil.py
+++ b/mercurial/cmdutil.py
@@ -3037,7 +3037,7 @@ 
                     xlist.append(abs)
                     if dobackup and (backup <= dobackup
                                      or wctx[abs].cmp(ctx[abs])):
-                            bakname = "%s.orig" % rel
+                            bakname = _getrevertbackuppath(ui, repo, rel)
                             ui.note(_('saving current version of %s as %s\n') %
                                     (rel, bakname))
                             if not opts.get('dry_run'):
@@ -3069,6 +3069,26 @@ 
     finally:
         wlock.release()
 
+def _getrevertbackuppath(ui, repo, filepath):
+    '''customize where .orig files are created
+
+    Fetch user defined path from config file: [ui] revertbackuppath = <path>
+    Fall back to default (filepath) if not specified
+    '''
+    revertbackuppath = ui.config('ui', 'revertbackuppath', None)
+    if revertbackuppath is None:
+        return filepath + ".orig"
+
+    filepathfromroot = os.path.relpath(filepath, start=repo.root)
+    revertpath = repo.wjoin(revertbackuppath, filepathfromroot);
+
+    revertbackupdir = repo.vfs.dirname(revertpath)
+    if not repo.vfs.exists(revertbackupdir):
+        ui.note(_('creating directory: %s\n') % revertbackupdir)
+        util.makedirs(revertbackupdir)
+
+    return revertpath + ".orig"
+
 def _revertprefetch(repo, ctx, *files):
     """Let extension changing the storage layer prefetch content"""
     pass
diff --git a/tests/test-revert.t b/tests/test-revert.t
--- a/tests/test-revert.t
+++ b/tests/test-revert.t
@@ -86,6 +86,23 @@ 
   saving current version of e as e.orig
   reverting e
 
+Test creation of backup (.orig) file in configured file location
+----------------------------------------------------------------
+ 
+  $ cat $HGRCPATH > hgrc_bak
+  $ cat >> $HGRCPATH << EOF
+  > [ui]
+  > revertbackuppath= .hg/origbackups
+  > EOF
+  $ echo z > e
+  $ hg revert --all -v
+  creating directory: $TESTTMP/repo/.hg/origbackups
+  saving current version of e as $TESTTMP/repo/.hg/origbackups/e.orig
+  reverting e
+  $ cp $TESTTMP/repo/.hg/origbackups/e.orig .
+  $ cp hgrc_bak $HGRCPATH
+  $ rm hgrc_bak
+
 revert on clean file (no change)
 --------------------------------