Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-14 Thread Yuya Nishihara 
On Thu, 13 Oct 2016 17:57:57 +0200, Pierre-Yves David wrote:
> On 10/13/2016 04:13 PM, Yuya Nishihara wrote:
> > On Thu, 13 Oct 2016 16:03:03 +0200, Mads Kiilerich wrote:
> >> On 10/13/2016 03:58 PM, Yuya Nishihara wrote:
> >>> On Thu, 13 Oct 2016 15:46:25 +0200, Mads Kiilerich wrote:
>  On 10/13/2016 03:39 PM, Yuya Nishihara wrote:
> > The series looks good to me. Queued up to the patch 5, thanks.
>  I have also looked into reworking it to increasing the default chunksize
>  to 128k everywhere - that seems a bit cleaner in hindsight. I will send
>  that version if you un-queue it again ;-)
> >>> Unqueue everything?
> >>
> >> I have no changes to the first two so it would be great to keep them ...
> >> but I could also easily resend them - whatever is least trouble ;-)
> >
> > Okay, pruned the following changes from hg-committed:
> 
> Urg, direct pruning on hg-commmitted is problematic as it makes
> changesets disappear on the contributor see (see the related thread on
> the reviewers mailing list a while back and the drophack¹ extension (for
> reviewers only)).
> 
> [1] https://www.mercurial-scm.org/repo/evolve/file/tip/hgext/drophack.py

Oh, but my name is not Matt Mackall. :-)

I pruned them assuming Mads would already start working on new version so
he would have new commits in his local repository.

Do we need to ssh into m-s-o and run "hg drop" ?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Pierre-Yves David 



On 10/13/2016 04:13 PM, Yuya Nishihara wrote:

On Thu, 13 Oct 2016 16:03:03 +0200, Mads Kiilerich wrote:

On 10/13/2016 03:58 PM, Yuya Nishihara wrote:

On Thu, 13 Oct 2016 15:46:25 +0200, Mads Kiilerich wrote:

On 10/13/2016 03:39 PM, Yuya Nishihara wrote:

The series looks good to me. Queued up to the patch 5, thanks.

I have also looked into reworking it to increasing the default chunksize
to 128k everywhere - that seems a bit cleaner in hindsight. I will send
that version if you un-queue it again ;-)

Unqueue everything?


I have no changes to the first two so it would be great to keep them ...
but I could also easily resend them - whatever is least trouble ;-)


Okay, pruned the following changes from hg-committed:


Urg, direct pruning on hg-commmitted is problematic as it makes 
changesets disappear on the contributor see (see the related thread on 
the reviewers mailing list a while back and the drophack¹ extension (for 
reviewers only)).


Cheers,

--
Pierre-Yves David

[1] https://www.mercurial-scm.org/repo/evolve/file/tip/hgext/drophack.py
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Mads Kiilerich 

On 10/13/2016 05:57 PM, Pierre-Yves David wrote:


On 10/13/2016 04:13 PM, Yuya Nishihara wrote:

Okay, pruned the following changes from hg-committed:


Urg, direct pruning on hg-commmitted is problematic as it makes 
changesets disappear on the contributor see (see the related thread on 
the reviewers mailing list a while back and the drophack¹ extension 
(for reviewers only)).


Don't worry; I don't use evolve - this is one of the reasons ;-)

/Mads

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

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Mads Kiilerich 

On 10/13/2016 03:58 PM, Yuya Nishihara wrote:

On Thu, 13 Oct 2016 15:46:25 +0200, Mads Kiilerich wrote:

On 10/13/2016 03:39 PM, Yuya Nishihara wrote:
The series looks good to me. Queued up to the patch 5, thanks. 

I have also looked into reworking it to increasing the default chunksize
to 128k everywhere - that seems a bit cleaner in hindsight. I will send
that version if you un-queue it again ;-)

Unqueue everything?



I have no changes to the first two so it would be great to keep them ... 
but I could also easily resend them - whatever is least trouble ;-)


/Mads

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

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Yuya Nishihara 
On Thu, 13 Oct 2016 15:46:25 +0200, Mads Kiilerich wrote:
> On 10/13/2016 03:39 PM, Yuya Nishihara wrote:
> > On Sat, 08 Oct 2016 01:26:05 +0200, Mads Kiilerich wrote:
> >> # HG changeset patch
> >> # User Mads Kiilerich 
> >> # Date 1475881180 -7200
> >> #  Sat Oct 08 00:59:40 2016 +0200
> >> # Node ID 96315a5833ed015acb7bd8f6d7f1e38db6fa9c50
> >> # Parent  1779dde4c9ef97cb242f8d501655f236f66e5439
> >> largefiles: when setting/clearing x bit on largefiles, don't change other 
> >> bits
> > The series looks good to me. Queued up to the patch 5, thanks.
> 
> I have also looked into reworking it to increasing the default chunksize 
> to 128k everywhere - that seems a bit cleaner in hindsight. I will send 
> that version if you un-queue it again ;-)

Unqueue everything?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Mads Kiilerich 

On 10/13/2016 03:39 PM, Yuya Nishihara wrote:

On Sat, 08 Oct 2016 01:26:05 +0200, Mads Kiilerich wrote:

# HG changeset patch
# User Mads Kiilerich 
# Date 1475881180 -7200
#  Sat Oct 08 00:59:40 2016 +0200
# Node ID 96315a5833ed015acb7bd8f6d7f1e38db6fa9c50
# Parent  1779dde4c9ef97cb242f8d501655f236f66e5439
largefiles: when setting/clearing x bit on largefiles, don't change other bits

The series looks good to me. Queued up to the patch 5, thanks.


I have also looked into reworking it to increasing the default chunksize 
to 128k everywhere - that seems a bit cleaner in hindsight. I will send 
that version if you un-queue it again ;-)


/Mads

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

Re: [PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-13 Thread Yuya Nishihara 
On Sat, 08 Oct 2016 01:26:05 +0200, Mads Kiilerich wrote:
> # HG changeset patch
> # User Mads Kiilerich 
> # Date 1475881180 -7200
> #  Sat Oct 08 00:59:40 2016 +0200
> # Node ID 96315a5833ed015acb7bd8f6d7f1e38db6fa9c50
> # Parent  1779dde4c9ef97cb242f8d501655f236f66e5439
> largefiles: when setting/clearing x bit on largefiles, don't change other bits

The series looks good to me. Queued up to the patch 5, thanks.

> It is only the X bit that it matters to copy from the standin to the largefile
> in the working directory. While it generally doesn't do any harm to copy the
> whole mode, it is also "wrong" to copy more than the X bit we care about. It
> can make a difference if someone should try to handle largefiles differently,
> such as marking them read-only.
> 
> Thus, do similar to what utils.setflags does and set the X bit where there are
> R bits and obey umask.
> 
> diff --git a/hgext/largefiles/lfcommands.py b/hgext/largefiles/lfcommands.py
> --- a/hgext/largefiles/lfcommands.py
> +++ b/hgext/largefiles/lfcommands.py
> @@ -515,9 +515,13 @@ def updatelfiles(ui, repo, filelist=None
>  rellfile = lfile
>  relstandin = lfutil.standin(lfile)
>  if wvfs.exists(relstandin):
> -mode = wvfs.stat(relstandin).st_mode
> -if mode != wvfs.stat(rellfile).st_mode:
> -wvfs.chmod(rellfile, mode)
> +standinexec = wvfs.stat(relstandin).st_mode & 0o100
> +st = wvfs.stat(rellfile).st_mode
> +if standinexec != st & 0o100:
> +st &= ~0o111
> +if standinexec:
> +st |= (st >> 2) & 0o111 & ~util.umask

This 2-bit shift seemed a bit obscure. Any comment would help future readers.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH 1 of 6] largefiles: when setting/clearing x bit on largefiles, don't change other bits

2016-10-07 Thread Mads Kiilerich 
# HG changeset patch
# User Mads Kiilerich 
# Date 1475881180 -7200
#  Sat Oct 08 00:59:40 2016 +0200
# Node ID 96315a5833ed015acb7bd8f6d7f1e38db6fa9c50
# Parent  1779dde4c9ef97cb242f8d501655f236f66e5439
largefiles: when setting/clearing x bit on largefiles, don't change other bits

It is only the X bit that it matters to copy from the standin to the largefile
in the working directory. While it generally doesn't do any harm to copy the
whole mode, it is also "wrong" to copy more than the X bit we care about. It
can make a difference if someone should try to handle largefiles differently,
such as marking them read-only.

Thus, do similar to what utils.setflags does and set the X bit where there are
R bits and obey umask.

diff --git a/hgext/largefiles/lfcommands.py b/hgext/largefiles/lfcommands.py
--- a/hgext/largefiles/lfcommands.py
+++ b/hgext/largefiles/lfcommands.py
@@ -515,9 +515,13 @@ def updatelfiles(ui, repo, filelist=None
 rellfile = lfile
 relstandin = lfutil.standin(lfile)
 if wvfs.exists(relstandin):
-mode = wvfs.stat(relstandin).st_mode
-if mode != wvfs.stat(rellfile).st_mode:
-wvfs.chmod(rellfile, mode)
+standinexec = wvfs.stat(relstandin).st_mode & 0o100
+st = wvfs.stat(rellfile).st_mode
+if standinexec != st & 0o100:
+st &= ~0o111
+if standinexec:
+st |= (st >> 2) & 0o111 & ~util.umask
+wvfs.chmod(rellfile, st)
 update1 = 1
 
 updated += update1
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel