| Submitter | Ed Morley |
|---|---|
| Date | Feb. 21, 2014, 4:31 p.m. |
| Message ID | <e74d0479759cbea6edb6.1393000265@ed-laptop> |
| Download | mbox | patch |
| Permalink | /patch/3731/ |
| State | Rejected |
| Headers | show |
Comments
On 02/21/2014 05:31 PM, Ed Morley wrote: > # HG changeset patch > # User Ed Morley <emorley@mozilla.com> > # Date 1392999130 0 > # Fri Feb 21 16:12:10 2014 +0000 > # Node ID e74d0479759cbea6edb632273345d55f96374d70 > # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd > util: set the hidden attribute on .hg/ during creation on windows (issue4178) > > Windows has no concept of dotfiles/directories being hidden - instead, it > requires that a file-is-hidden attribute be set. This patch adds an optional > parameter to util.makedir/util.makedirs - which is used to set the hidden > attribute when the .hg directory is created on Windows. > > This has the advantage that both the OS filesystem search & also editors > grepping repositories can easily exclude the .hg directory, without needing to > exclude it manually every time. Mercurial is based on the unix tradition where all files starting with '.' are hidden. If we really want to set the 'hidden' attribute on windows, couldn't win32.makedir just do that if the directory starts with '.'? That would also raise the question if files like .hgignore and directories like .hglf also should be ignored ... and if we want to set that flag at all. If not, it would be easy to make an extension that wraps win32.makedir to set the hidden flag on dirs starting with '.'. /Mads
On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: > # HG changeset patch > # User Ed Morley <emorley@mozilla.com> > # Date 1392999130 0 > # Fri Feb 21 16:12:10 2014 +0000 > # Node ID e74d0479759cbea6edb632273345d55f96374d70 > # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd > util: set the hidden attribute on .hg/ during creation on windows (issue4178) > > Windows has no concept of dotfiles/directories being hidden - instead, it > requires that a file-is-hidden attribute be set. This patch adds an optional > parameter to util.makedir/util.makedirs - which is used to set the hidden > attribute when the .hg directory is created on Windows. > > This has the advantage that both the OS filesystem search & also editors > grepping repositories can easily exclude the .hg directory, without needing to > exclude it manually every time. I think 9 years in, this is probably too surprising a change. We could have done this out of the gate.. but no one cared enough to even mention it for the first 7 years.
On Mar 7, 2014, at 2:43 PM, Matt Mackall <mpm@selenic.com> wrote: > On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: >> # HG changeset patch >> # User Ed Morley <emorley@mozilla.com> >> # Date 1392999130 0 >> # Fri Feb 21 16:12:10 2014 +0000 >> # Node ID e74d0479759cbea6edb632273345d55f96374d70 >> # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd >> util: set the hidden attribute on .hg/ during creation on windows (issue4178) >> >> Windows has no concept of dotfiles/directories being hidden - instead, it >> requires that a file-is-hidden attribute be set. This patch adds an optional >> parameter to util.makedir/util.makedirs - which is used to set the hidden >> attribute when the .hg directory is created on Windows. >> >> This has the advantage that both the OS filesystem search & also editors >> grepping repositories can easily exclude the .hg directory, without needing to >> exclude it manually every time. > > I think 9 years in, this is probably too surprising a change. We could > have done this out of the gate.. but no one cared enough to even mention > it for the first 7 years. OOC, why? It's already hidden on all other platforms, and that strikes me as a Good Thing. Why do we want to leave windows out in the cold here? > > -- > Mathematics is the supreme nostalgia of our time. > > > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@selenic.com > http://selenic.com/mailman/listinfo/mercurial-devel
On Fri, 2014-03-07 at 16:10 -0500, Augie Fackler wrote: > On Mar 7, 2014, at 2:43 PM, Matt Mackall <mpm@selenic.com> wrote: > > > On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: > >> # HG changeset patch > >> # User Ed Morley <emorley@mozilla.com> > >> # Date 1392999130 0 > >> # Fri Feb 21 16:12:10 2014 +0000 > >> # Node ID e74d0479759cbea6edb632273345d55f96374d70 > >> # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd > >> util: set the hidden attribute on .hg/ during creation on windows (issue4178) > >> > >> Windows has no concept of dotfiles/directories being hidden - instead, it > >> requires that a file-is-hidden attribute be set. This patch adds an optional > >> parameter to util.makedir/util.makedirs - which is used to set the hidden > >> attribute when the .hg directory is created on Windows. > >> > >> This has the advantage that both the OS filesystem search & also editors > >> grepping repositories can easily exclude the .hg directory, without needing to > >> exclude it manually every time. > > > > I think 9 years in, this is probably too surprising a change. We could > > have done this out of the gate.. but no one cared enough to even mention > > it for the first 7 years. > > OOC, why? It's already hidden on all other platforms, and that strikes > me as a Good Thing. Why what? Why has basically no one cared to date? I can't answer that. Why is it too big of a surprise? Because suddenly you can't navigate to .hg/hgrc in Explorer and file|open dialogs in editors. More generally, I'd say it's a matter of OS culture. Dealing with hidden files is an everyday situation for typical Unix users, whereas I expect it's a quite rare and surprising occurrence for Windows users. I think if .hg suddenly disappears from new repos, the average Windows dev won't just say "oh, it's probably just hidden now", instead they'll suffer hours/days of confusion. Since we have about two people in all of recorded history asking for it, the cost/benefit does not appear (remotely) favorable.
On 2014-03-07 22:54, Matt Mackall wrote: > On Fri, 2014-03-07 at 16:10 -0500, Augie Fackler wrote: >> On Mar 7, 2014, at 2:43 PM, Matt Mackall <mpm@selenic.com> wrote: >> >>> On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: >>>> # HG changeset patch >>>> # User Ed Morley <emorley@mozilla.com> >>>> # Date 1392999130 0 >>>> # Fri Feb 21 16:12:10 2014 +0000 >>>> # Node ID e74d0479759cbea6edb632273345d55f96374d70 >>>> # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd >>>> util: set the hidden attribute on .hg/ during creation on windows (issue4178) >>>> >>>> Windows has no concept of dotfiles/directories being hidden - instead, it >>>> requires that a file-is-hidden attribute be set. This patch adds an optional >>>> parameter to util.makedir/util.makedirs - which is used to set the hidden >>>> attribute when the .hg directory is created on Windows. >>>> >>>> This has the advantage that both the OS filesystem search & also editors >>>> grepping repositories can easily exclude the .hg directory, without needing to >>>> exclude it manually every time. >>> >>> I think 9 years in, this is probably too surprising a change. We could >>> have done this out of the gate.. but no one cared enough to even mention >>> it for the first 7 years. >> >> OOC, why? It's already hidden on all other platforms, and that strikes >> me as a Good Thing. > > Why what? Why has basically no one cared to date? I can't answer that. > > Why is it too big of a surprise? Because suddenly you can't navigate > to .hg/hgrc in Explorer and file|open dialogs in editors. > > More generally, I'd say it's a matter of OS culture. Dealing with hidden > files is an everyday situation for typical Unix users, whereas I expect > it's a quite rare and surprising occurrence for Windows users. I think > if .hg suddenly disappears from new repos, the average Windows dev won't > just say "oh, it's probably just hidden now", instead they'll suffer > hours/days of confusion. > > Since we have about two people in all of recorded history asking for it, > the cost/benefit does not appear (remotely) favorable. Perhaps a compromise could be made by setting the hidden flag on .hg/store on new repositories... Regarding the proposed behavior change as by the patch of Ed Morley, I think it might indeed be a bit surprising to not see the .hg folder in explorer inside new repositories (for users who have not tweaked the explorer setting) - given that we now have been used to see .hg on all repositories. As per the culture, a difference can probably be made between developers using Windows and other Windows users. I think chances that a typical developer has set the "Show hidden files, folders, and drives" setting in explorer is pretty high. At least this is one of the few early tweaks I make on a fresh Windows install for my personal use.
On Sat, Mar 8, 2014 at 1:15 AM, Adrian Buehlmann <adrian@cadifra.com> wrote: > On 2014-03-07 22:54, Matt Mackall wrote: >> On Fri, 2014-03-07 at 16:10 -0500, Augie Fackler wrote: >>> On Mar 7, 2014, at 2:43 PM, Matt Mackall <mpm@selenic.com> wrote: >>> >>>> On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: >>>>> # HG changeset patch >>>>> # User Ed Morley <emorley@mozilla.com> >>>>> # Date 1392999130 0 >>>>> # Fri Feb 21 16:12:10 2014 +0000 >>>>> # Node ID e74d0479759cbea6edb632273345d55f96374d70 >>>>> # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd >>>>> util: set the hidden attribute on .hg/ during creation on windows (issue4178) >>>>> >>>>> Windows has no concept of dotfiles/directories being hidden - instead, it >>>>> requires that a file-is-hidden attribute be set. This patch adds an optional >>>>> parameter to util.makedir/util.makedirs - which is used to set the hidden >>>>> attribute when the .hg directory is created on Windows. >>>>> >>>>> This has the advantage that both the OS filesystem search & also editors >>>>> grepping repositories can easily exclude the .hg directory, without needing to >>>>> exclude it manually every time. >>>> >>>> I think 9 years in, this is probably too surprising a change. We could >>>> have done this out of the gate.. but no one cared enough to even mention >>>> it for the first 7 years. >>> >>> OOC, why? It's already hidden on all other platforms, and that strikes >>> me as a Good Thing. >> >> Why what? Why has basically no one cared to date? I can't answer that. >> >> Why is it too big of a surprise? Because suddenly you can't navigate >> to .hg/hgrc in Explorer and file|open dialogs in editors. >> >> More generally, I'd say it's a matter of OS culture. Dealing with hidden >> files is an everyday situation for typical Unix users, whereas I expect >> it's a quite rare and surprising occurrence for Windows users. I think >> if .hg suddenly disappears from new repos, the average Windows dev won't >> just say "oh, it's probably just hidden now", instead they'll suffer >> hours/days of confusion. >> >> Since we have about two people in all of recorded history asking for it, >> the cost/benefit does not appear (remotely) favorable. > > Perhaps a compromise could be made by setting the hidden flag on > .hg/store on new repositories... > > Regarding the proposed behavior change as by the patch of Ed Morley, I > think it might indeed be a bit surprising to not see the .hg folder in > explorer inside new repositories (for users who have not tweaked the > explorer setting) - given that we now have been used to see .hg on all > repositories. > > As per the culture, a difference can probably be made between developers > using Windows and other Windows users. I think chances that a typical > developer has set the "Show hidden files, folders, and drives" setting > in explorer is pretty high. At least this is one of the few early tweaks > I make on a fresh Windows install for my personal use. I agree with Matt and Adrian. I think mercurial windows users have been "trained" over the years to expect to see an .hg folder at the root of their repositories. It would be very surprising if this were no longer the case (plus old repos would have it and new ones would not?). Cheers, Angel
On Sat, 2014-03-08 at 01:15 +0100, Adrian Buehlmann wrote: > On 2014-03-07 22:54, Matt Mackall wrote: > > On Fri, 2014-03-07 at 16:10 -0500, Augie Fackler wrote: > >> On Mar 7, 2014, at 2:43 PM, Matt Mackall <mpm@selenic.com> wrote: > >> > >>> On Fri, 2014-02-21 at 16:31 +0000, Ed Morley wrote: > >>>> # HG changeset patch > >>>> # User Ed Morley <emorley@mozilla.com> > >>>> # Date 1392999130 0 > >>>> # Fri Feb 21 16:12:10 2014 +0000 > >>>> # Node ID e74d0479759cbea6edb632273345d55f96374d70 > >>>> # Parent 0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd > >>>> util: set the hidden attribute on .hg/ during creation on windows (issue4178) > >>>> > >>>> Windows has no concept of dotfiles/directories being hidden - instead, it > >>>> requires that a file-is-hidden attribute be set. This patch adds an optional > >>>> parameter to util.makedir/util.makedirs - which is used to set the hidden > >>>> attribute when the .hg directory is created on Windows. > >>>> > >>>> This has the advantage that both the OS filesystem search & also editors > >>>> grepping repositories can easily exclude the .hg directory, without needing to > >>>> exclude it manually every time. > >>> > >>> I think 9 years in, this is probably too surprising a change. We could > >>> have done this out of the gate.. but no one cared enough to even mention > >>> it for the first 7 years. > >> > >> OOC, why? It's already hidden on all other platforms, and that strikes > >> me as a Good Thing. > > > > Why what? Why has basically no one cared to date? I can't answer that. > > > > Why is it too big of a surprise? Because suddenly you can't navigate > > to .hg/hgrc in Explorer and file|open dialogs in editors. > > > > More generally, I'd say it's a matter of OS culture. Dealing with hidden > > files is an everyday situation for typical Unix users, whereas I expect > > it's a quite rare and surprising occurrence for Windows users. I think > > if .hg suddenly disappears from new repos, the average Windows dev won't > > just say "oh, it's probably just hidden now", instead they'll suffer > > hours/days of confusion. > > > > Since we have about two people in all of recorded history asking for it, > > the cost/benefit does not appear (remotely) favorable. > > Perhaps a compromise could be made by setting the hidden flag on > .hg/store on new repositories... How is this not going to confuse/surprise a veteran hg user? In the 9 years this project has existed, this super-obvious idea of using the hidden attribute has come up only twice, so the demonstrated demand/need for this feature is next to zero. Meanwhile, there's good reason to believe this will confuse some users. We like to add features where risk ~= 0 and reward/risk >> 1. This feature has reward ~= 0 and risk/reward >> 1. It is basically the opposite of the sort of change I'm likely to accept.
On 2014-03-08 22:05, Matt Mackall wrote: > On Sat, 2014-03-08 at 01:15 +0100, Adrian Buehlmann wrote: >> Perhaps a compromise could be made by setting the hidden flag on >> .hg/store on new repositories... > > How is this not going to confuse/surprise a veteran hg user? I'd expect almost no one would even notice it, as users generally have no reason to navigate into .hg/store with tools like explorer. But I'm fine with your decision.
On Sat, 2014-03-08 at 22:51 +0100, Adrian Buehlmann wrote: > On 2014-03-08 22:05, Matt Mackall wrote: > > On Sat, 2014-03-08 at 01:15 +0100, Adrian Buehlmann wrote: > >> Perhaps a compromise could be made by setting the hidden flag on > >> .hg/store on new repositories... > > > > How is this not going to confuse/surprise a veteran hg user? > > I'd expect almost no one would even notice it, as users generally have > no reason to navigate into .hg/store with tools like explorer. Oh, I see. I missed the 'store' part and only caught the 'new repositories' part. Sorry, yes, that is different. What happens when you copy a folder^H^H^H^H^H^Hdirectory in Explorer that contains a hidden directory? We don't want that to break either.
On 3/9/2014 1:49 PM, Matt Mackall wrote: > On Sat, 2014-03-08 at 22:51 +0100, Adrian Buehlmann wrote: >> On 2014-03-08 22:05, Matt Mackall wrote: >>> On Sat, 2014-03-08 at 01:15 +0100, Adrian Buehlmann wrote: >>>> Perhaps a compromise could be made by setting the hidden flag on >>>> .hg/store on new repositories... >>> >>> How is this not going to confuse/surprise a veteran hg user? >> >> I'd expect almost no one would even notice it, as users generally have >> no reason to navigate into .hg/store with tools like explorer. > > Oh, I see. I missed the 'store' part and only caught the 'new > repositories' part. Sorry, yes, that is different. > > What happens when you copy a folder^H^H^H^H^H^Hdirectory in Explorer > that contains a hidden directory? We don't want that to break either. The hidden directory is copied. I support the change. Even though it is backwards incompatible behavior, I think setting the hidden attribute is the right thing to do. Setting the hidden attribute conveys the message "don't be mucking around in here." Users shouldn't be directly editing any files in .hg except for hgrc (are there any others?) and making the directory hidden will help reinforce that. I'd like to think the upcoming 3.0 release is a good opportunity to make changes like this.
On Sun, 2014-03-09 at 23:36 -0700, Gregory Szorc wrote: > On 3/9/2014 1:49 PM, Matt Mackall wrote: > > On Sat, 2014-03-08 at 22:51 +0100, Adrian Buehlmann wrote: > >> On 2014-03-08 22:05, Matt Mackall wrote: > >>> On Sat, 2014-03-08 at 01:15 +0100, Adrian Buehlmann wrote: > >>>> Perhaps a compromise could be made by setting the hidden flag on > >>>> .hg/store on new repositories... > >>> > >>> How is this not going to confuse/surprise a veteran hg user? > >> > >> I'd expect almost no one would even notice it, as users generally have > >> no reason to navigate into .hg/store with tools like explorer. > > > > Oh, I see. I missed the 'store' part and only caught the 'new > > repositories' part. Sorry, yes, that is different. > > > > What happens when you copy a folder^H^H^H^H^H^Hdirectory in Explorer > > that contains a hidden directory? We don't want that to break either. > > The hidden directory is copied. Ok, how about xcopy? Since that has a /h flag, I suspect the answer is no. We can only guess at the thousands of habits our users may have formed that might conflict with this idea in a surprising way... so this really warrants some thorough defensive thinking beforehand. (Folks, if you're reading 'surprise' here and not hearing 'tragic data loss' in your head, you may be missing why this is a big deal.)
On 10 March 2014 16:03:15, Matt Mackall wrote: > Ok, how about xcopy? Since that has a /h flag, I suspect the answer is > no. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true says it doesn't copy hidden files by default. So I agree, this may be more disruptive than it first appears. Would you accept a patch for a Mercurial-bundled extension? :-) Ed
On 03/10/2014 12:52 PM, Ed Morley wrote: > On 10 March 2014 16:03:15, Matt Mackall wrote: >> Ok, how about xcopy? Since that has a /h flag, I suspect the answer is >> no. > > http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true > says it doesn't copy hidden files by default. > > So I agree, this may be more disruptive than it first appears. > Would you accept a patch for a Mercurial-bundled extension? :-) What would that extension do? opt-in to turn mercurial repo hidden on window?
On 14 April 2014 06:03:55, Pierre-Yves David wrote: > On 03/10/2014 12:52 PM, Ed Morley wrote: >> So I agree, this may be more disruptive than it first appears. >> Would you accept a patch for a Mercurial-bundled extension? :-) > > What would that extension do? opt-in to turn mercurial repo hidden on > window? Actually, it appears there is a third party extension for this already: http://mercurial.selenic.com/wiki/Win32xattrsExtension
On Thu, 24 Apr 2014 11:39:18 +0100, Ed Morley wrote: > On 14 April 2014 06:03:55, Pierre-Yves David wrote: > > On 03/10/2014 12:52 PM, Ed Morley wrote: > >> So I agree, this may be more disruptive than it first appears. > >> Would you accept a patch for a Mercurial-bundled extension? :-) > > > > What would that extension do? opt-in to turn mercurial repo hidden on > > window? > > Actually, it appears there is a third party extension for this already: > http://mercurial.selenic.com/wiki/Win32xattrsExtension Oops, it's outdated and won't work with recent Mercurial versions. I'll remove it from the list of third-party extensions. Regards,
Patch
diff -r 0e2877f8605d -r e74d0479759c mercurial/hg.py --- a/mercurial/hg.py +++ b/mercurial/hg.py @@ -157,7 +157,7 @@ def share(ui, source, dest=None, update= if not os.path.isdir(root): os.mkdir(root) - util.makedir(roothg, notindexed=True) + util.makedir(roothg, notindexed=True, hidden=True) requirements = '' try: @@ -326,7 +326,7 @@ def clone(ui, peeropts, source, dest=Non cleandir = hgdir try: destpath = hgdir - util.makedir(destpath, notindexed=True) + util.makedir(destpath, notindexed=True, hidden=True) except OSError, inst: if inst.errno == errno.EEXIST: cleandir = None diff -r 0e2877f8605d -r e74d0479759c mercurial/localrepo.py --- a/mercurial/localrepo.py +++ b/mercurial/localrepo.py @@ -197,7 +197,7 @@ class localrepository(object): if create: if not self.wvfs.exists(): self.wvfs.makedirs() - self.vfs.makedir(notindexed=True) + self.vfs.makedir(notindexed=True, hidden=True) requirements = self._baserequirements(create) if self.ui.configbool('format', 'usestore', True): self.vfs.mkdir("store") diff -r 0e2877f8605d -r e74d0479759c mercurial/posix.py --- a/mercurial/posix.py +++ b/mercurial/posix.py @@ -459,7 +459,7 @@ def termwidth(): pass return 80 -def makedir(path, notindexed): +def makedir(path, notindexed, hidden): os.mkdir(path) def unlinkpath(f, ignoremissing=False): diff -r 0e2877f8605d -r e74d0479759c mercurial/scmutil.py --- a/mercurial/scmutil.py +++ b/mercurial/scmutil.py @@ -181,8 +181,8 @@ class abstractvfs(object): def lstat(self, path=None): return os.lstat(self.join(path)) - def makedir(self, path=None, notindexed=True): - return util.makedir(self.join(path), notindexed) + def makedir(self, path=None, notindexed=True, hidden=False): + return util.makedir(self.join(path), notindexed, hidden) def makedirs(self, path=None, mode=None): return util.makedirs(self.join(path), mode) diff -r 0e2877f8605d -r e74d0479759c mercurial/util.py --- a/mercurial/util.py +++ b/mercurial/util.py @@ -886,10 +886,10 @@ class atomictempfile(object): if safehasattr(self, '_fp'): # constructor actually did something self.discard() -def makedirs(name, mode=None, notindexed=False): +def makedirs(name, mode=None, notindexed=False, hidden=False): """recursive directory creation with parent mode inheritance""" try: - makedir(name, notindexed) + makedir(name, notindexed, hidden) except OSError, err: if err.errno == errno.EEXIST: return @@ -898,8 +898,8 @@ def makedirs(name, mode=None, notindexed parent = os.path.dirname(os.path.abspath(name)) if parent == name: raise - makedirs(parent, mode, notindexed) - makedir(name, notindexed) + makedirs(parent, mode, notindexed, hidden) + makedir(name, notindexed, hidden) if mode is not None: os.chmod(name, mode) diff -r 0e2877f8605d -r e74d0479759c mercurial/win32.py --- a/mercurial/win32.py +++ b/mercurial/win32.py @@ -62,7 +62,9 @@ class _BY_HANDLE_FILE_INFORMATION(ctypes _FILE_FLAG_BACKUP_SEMANTICS = 0x02000000 # SetFileAttributes +# http://msdn.microsoft.com/en-us/library/windows/desktop/gg258117%28v=vs.85%29.aspx _FILE_ATTRIBUTE_NORMAL = 0x80 +_FILE_ATTRIBUTE_HIDDEN = 0x2 _FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 0x2000 # Process Security and Access Rights @@ -469,7 +471,9 @@ def unlink(f): # leaving some potentially serious inconsistencies. pass -def makedir(path, notindexed): +def makedir(path, notindexed, hidden): os.mkdir(path) if notindexed: _kernel32.SetFileAttributesA(path, _FILE_ATTRIBUTE_NOT_CONTENT_INDEXED) + if hidden: + _kernel32.SetFileAttributesA(path, _FILE_ATTRIBUTE_HIDDEN)