Patchwork util: set the hidden attribute on .hg/ during creation on windows (issue4178)

login
register
mail settings
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

Ed Morley - Feb. 21, 2014, 4:31 p.m.
# 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.
Mads Kiilerich - Feb. 22, 2014, 3:52 p.m.
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
Matt Mackall - March 7, 2014, 7:43 p.m.
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.
Augie Fackler - March 7, 2014, 9:10 p.m.
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
Matt Mackall - March 7, 2014, 9:54 p.m.
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.
Adrian Buehlmann - March 8, 2014, 12:15 a.m.
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.
Didly - March 8, 2014, 1:36 a.m.
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
Matt Mackall - March 8, 2014, 9:05 p.m.
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.
Adrian Buehlmann - March 8, 2014, 9:51 p.m.
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.
Matt Mackall - March 9, 2014, 8:49 p.m.
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.
Gregory Szorc - March 10, 2014, 6:36 a.m.
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.
Matt Mackall - March 10, 2014, 4:03 p.m.
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.)
Ed Morley - March 10, 2014, 4:52 p.m.
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
Pierre-Yves David - April 14, 2014, 5:03 a.m.
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?
Ed Morley - April 24, 2014, 10:39 a.m.
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
Yuya Nishihara - April 24, 2014, 1:17 p.m.
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)