Re: [PATCH 4 of 5 v4] revlog: REVIDX_ISLARGEFILE flag

[Augie Fackler]

> On Dec 2, 2016, at 9:51 PM, Pierre-Yves David 
>  wrote:
> 
>> One aspect Augie and I discussed was to keep a few placeholder flags for
>> home brewed extensions to register transforms on.
> 
> Do you have some specific example in mind, or just having some USR1-USR4 
> reserve for in-house usage?

It was more the USR1-USR4 idea, but I’m still not sure if it’s a good one. It 
feels risky on some level, but I can’t get beyond a bad gut feeling about it.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] histedit: make --keep work more like graft and use default phase for copies

[Pierre-Yves David]

On 11/28/2016 01:58 AM, Augie Fackler wrote:



On Nov 27, 2016, at 7:38 PM, Pierre-Yves David  
wrote:

here is my current understanding of the situation:

 Before this patch:
 --

 1) histedit was refusing to run on public changeset in all cases
   (regardless of --keep usage)

 2) histedit was preserving the phrase of changeset it touch in all
cases: (draft → draft, secret → secret, public not allowed)
(note, this phase preserving behavior in all cases match rebase).

 This patch is doing two things:
 ---

 a) allow histedit on public changeset if --keep is present,

 b) change histedit --keep to use 'new-commit' phase,


As Augie pointed, the first change (allow public with --keep) make perfect 
sense.

On the other hand, I'm not sure about what's motivate (b). I'm not sure if 
there is an actual use case behind it or if it is just a reaction to histedit 
preserving the public phases.


Based on my (foggy, because it was over a week ago) recollection of the irc 
conversation I had with Mads, the intent of the patch was to use the new-commit 
phase only in the case of histediting a public change with —keep. That may be 
revisionist memory though based on this review thread though, so take it with a 
grain of salt.


The behavior of this patch is to use 'new-commit' for all cases. The 
commit message agree with that.



In all cases, this behavior change regarding phase preservation is problematic 
for two reasons:

1) consistency: rebase still preserve phase when --keep is used. I think it is 
important to have a consistent behavior between the two commands on this point.

2) backward compatibility: it is likely that we currently have existing users 
of histedit at rely on the fact secret changesets stay secret with 'histedit 
--keep', changing that behavior would lead them to turn 'secret' content draft 
and risk to push/publish it by mistake after upgrading.


Fair point. Can I interest one of the two of you into drafting either a revised 
version of this patch or followups that can be landed at the same time that 
moves us to the following state:

histedit allows operation on public nodes with --keep, and uses the default 
phase for any public changes that got copied (“rewritten” but not really) by 
such a histedit, while preserving the rest?


One can just reuse the code used by rebase to implement the very same 
logic: 
https://www.mercurial-scm.org/repo/hg/file/342d0cb4f446/hgext/rebase.py#l806


(nice attempt to snip me on this, but I've no intend to get dragged into 
this ;-))


Cheers,

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

Re: [PATCH 5 of 5 v4] changegroup3: enable on 'lfs' repo requirements

[Pierre-Yves David]

On 11/30/2016 06:35 AM, Martin von Zweigbergk wrote:

+cc:remi

On Nov 29, 2016 13:51, "Kyle Lippincott via Mercurial-devel" <
mercurial-devel@mercurial-scm.org> wrote:



On Tue, Nov 29, 2016 at 9:37 AM, Augie Fackler  wrote:


On Tue, Nov 29, 2016 at 07:59:11AM +0100, Pierre-Yves David wrote:

[cc martin because I've a question about some code mentioning

'treemanifest'


On 11/23/2016 06:39 PM, Remi Chaintron wrote:

# HG changeset patch
# User Remi Chaintron 
# Date 1479916365 0
#  Wed Nov 23 15:52:45 2016 +
# Branch stable
# Node ID b421c16161aed491fec20b600df5f1278b07bc1a
# Parent  75ee4746c198f039a39400e855e9335afc34f1dd
changegroup3: enable on 'lfs' repo requirements

`changegroup3` is required by the `lfs` extension in order to send

flags for

revlog objects over the wire.


It seems like the commit message needs to be updated too.


diff --git a/mercurial/changegroup.py b/mercurial/changegroup.py
--- a/mercurial/changegroup.py
+++ b/mercurial/changegroup.py
@@ -879,14 +879,16 @@
# Changegroup versions that can be applied to the repo
def supportedincomingversions(repo):
versions = allsupportedversions(repo.ui)
-if 'treemanifest' in repo.requirements:
+if ('treemanifest' in repo.requirements or
+'lfs' in repo.requirements):
versions.add('03')


I've not seen 'lfs' used anywhere yet so this changeset seems a bit
premature. Given the code in this series I would expect the next step to

be

a minimal usage of the new code (either by porting some of censor or by
using a test extension). Then we can start working on exchanging these
flagged changesets.

In addition, this piece of code is suspicious. If we have a changelog

'03'

available, we should be using it. I'm not sure why we only consider it

when

treemanifest is used. Martin: is this the remain of a period where the

'03'

format was experimental? Did we actually tested the new format now? Can

we

drop this special case?


Martin is on vacation (and you didn't add him to CC?), but we've been
using changegroup3 extensively, and I think we're happy with it. Added
spectral to confirm.



Yes, we've been using changegroup3 internally without issues for a while
now. It's required for treemanifests and I'm pretty sure is required by
recent versions of narrowhg.  I'm fine with freezing it and making it
non-experimental.


I agree, let's make it non-experimental. I assume that also means it's on
by default and will be used be getbundle.


Yes please, we should do this ☺

Make sure we have a way to control the changegroup used though the 
'devel.legacy' class of option and that it is still tested.



IIRC, "hg bundle" will still
produce a cg2 bundle, though, unless cg3 is forced by the presence of the
treemanifest requirement. So, in the same way, you'll still need to force
it to use cg3 when the lfs requirement is there.
Looking at the patch, that
seems to mean removing the first hunk (after the patch the makes cg3 on by
default), but keeping the second hunk (and third). Or maybe I'm just
confusing it with how there is no way to specify cg3 to "hg bundle", but
once it's on by default, it will get picked up. On that case, there will
instead be some BC concern in that people with a new hg can not share a
bundle with people with an old (current) hg. As I said, I'm not sure which,
so please check for yourself (I guess I'm talking to Remi here).


bundle have various options to control what it is generating, it is 
likely that they is already a way to select the changegroup version to 
'03' from the command line (or we should had it).


At some point we can spin a new 'bundle' version that will use cg3 (and 
improvement like bookmark as port etc). We must make sure version that 
exist now stay consistent with their definition at the time they were 
introduced.


Cheers,

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

Re: [PATCH 4 of 5 v4] revlog: REVIDX_ISLARGEFILE flag

[Pierre-Yves David]

On 11/29/2016 06:02 PM, Rémi Chaintron wrote:

On Tue, 29 Nov 2016 at 06:59 Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:




On 11/23/2016 06:39 PM, Remi Chaintron wrote:

# HG changeset patch
# User Remi Chaintron 
# Date 1479922644 0
#  Wed Nov 23 17:37:24 2016 +
# Branch stable
# Node ID 75ee4746c198f039a39400e855e9335afc34f1dd
# Parent  da91f91e979d6bf807912e956cf2f29573ede56f
revlog: REVIDX_ISLARGEFILE flag

Add the REVIDX_ISLARGEFILE flag for the `lfs` extension to interact with
revisions by registering transforms in the flagprocessor.


small naming question: Should we actually call this 'lfs'/'LARGEFILE'.
Of courses. the extension using it is intended for large file. However,
the core semantic of this 'flag' seems to be "the content is stored
outsided of revlog". This external storage could be applied to any use
cases (eg, fetching sensitive content from a secure server on update).

What do you think about adapting the name to reflect this?



 That's a good point, and it depends on what we want to do with these
flags. My understanding was that we wanted them to represent extension
flags (at least a few of them).


Extensions are more volatile than usecase/behavior. For example you are 
introducing a LFS extensions to handle largefile, while we already had 
an extension to handle largefile. In addition, in a couple of year the 
LFS protocol might be extinct and someone else will use create a new 
extension to achieve the same effect using a node-rail.elm protocol on 
the uber-cloud platefor. Having these people able to reuse that flag 
would be great.



One aspect to consider is that if we were to rename this flag to something
more generic (such as "REVIDX_EXTERNAL_STORAGE" for example), we might end
up in a situation where this is used by different extensions with different
behaviors, that might then become incompatible.


So a flag should result in a similar class of behavior. In our case this 
is "Fetch the content from outside the revlog file".



One solution moving forward might be to allow extensions to register
several transforms on a single flag, but this will make handling
non-commutative operations more doable. This might be something worth
iterating over, though.


From the top of my head, a simple idea here would be to have a 
'protocol key' defined as part of a basic format to be expected from the 
flag usage. In our case we would have a 'lfs' protocol for the 
EXT_STORAGE flag. The lfs extensions registed an handler for EXT_STORAGE 
and "pass" if the protocol is not 'lfs' (or anything else it handles). 
Extensions collaborate so that the one who can handle it get to do it, 
but only one 'protocol'/extension gets into play. There is not 
commutative operation involved.



One aspect Augie and I discussed was to keep a few placeholder flags for
home brewed extensions to register transforms on.


Do you have some specific example in mind, or just having some USR1-USR4 
reserve for in-house usage?


Cheers,

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

Re: [PATCH 2 of 5 v4] revlog: add flagprocessor

[Pierre-Yves David]

On 11/29/2016 06:16 PM, Rémi Chaintron wrote:

Thanks for the awesome review.
I included the changes in my current version and will update the stack
once I'm done with all required changes.

The approach I'm currently following relies on getting rid of the
flagprocessor object, instead relying on a single revlog.processflags()
method and an OrderedDict containing the flags and their associated
transforms.


I don't think OrderedDict is suitable here. OrderedDict remember order 
it which value have been added. Inserting something in that order (or 
manipulating the order in genera) is a bit impractical. Your dict + list 
approach was good in my opinion.



The hybrid "no flags" design is going away too, which makes the code
really simpler.

On Tue, 29 Nov 2016 at 06:59 Pierre-Yves David
>
wrote:

>
>  # max size of revlog with inline data
>  _maxinline = 131072
> @@ -76,6 +80,76 @@
>
>  _nullhash = hashlib.sha1(nullid)
>
> +class flagprocessor(object):
> +"""process revlog objects contents based on flags
> +
> +flagprocessor objects are the interface between revlog
objects and
> +subclasses/extensions needing to change or update the
contents of revlog
> +objects, based on flags.
> +
> +The role of the flagprocessor is to apply transforms
registered by
> +extensions and revlog subclasses in the order defined by
> +REVIDX_FLAGS_PROCESSING_ORDER and the type (read or write) of
operation.
> +This allows the flag processor to modify the contents of
revlog objects and
> +handle the composition of non-commutative operations.
> +"""
> +
> +def __init__(self, revlogobject):
> +self.transformmap = {}
> +self.revlogobject = revlogobject

I'm not sure why we need a full object here, it seems like we just need
a dictionary mapping 'flag' to 'processors' and a function running them.
In the Mercurial code base we try to avoid creating too much new class.
It seems like we could do without the class here (unless I'm missing
something).

In addition to this local custom:

* an individual flagprocessor object is created for each revlog. I'm not
sure why? Can't we just use one mapping (as we do for ordering?)

* having a the revlog referencing the flagprocessor which itself
reference the revlog create a reference cycle. We avoid creating
reference cycle in Mercurial (both for design purpose and because python
is not great with them)


Good point, I have now removed the flagprocessor altogether, which looks
much nicer!


> +
> +def register(self, transformmap):
> +"""Register transforms to be applied for flags.
> +
> +``transformmap`` - a map of flag to transform
> +"""
> +for flag in transformmap:
> +if flag in REVIDX_FLAGS_PROCESSING_ORDER:
> +self.transformmap[flag] = transformmap[flag]

* unknown flag seems to be silently ignored. It would be better to just
fail here.

* we have a mechanism to load extra elements (like flag processors are).
Have a look at 'mercurial.dispatch.extraloaders' (or use a registrar
API, but that one is probably overkill here)

* we do not handle collision at all, if multiple extensions try to
register a process for the same flag, we should not let the last one
just overwrite the other one. (Abort is the simplest handling).


As part of moving the flagprocessor out, I now have a single
'processflags(self, text, flags, reverse=True)' method in revlog, which
I updated to take care of unknown flags (which was previously done in
'revlog.revision()').

Collisions were explicitly not handled, as we were until now relying on
a flag per extension, but this is something I'm happy to discuss.


We cannot exclude the change for a collision, especially because 
multiple extension could use the same flag without having registered it 
with Mercurial ever. In addition, as discussed in Patch4 it would make 
sense to have multiple extensions implement different variant of the 
same flag/behavior.




The current updated version I'm working on simply relies on the
following constant:
REVIDX_FLAGS_TRANSFORMS = collections.OrderedDict({
REVIDX_ISCENSORED: None,
REVIDX_ISLFS: None,
})
This takes care of both the ordering and a way to register transforms,
but this enforces using only one transform per flag.


Not that in the example you provide, You are feeding a dict to 
OrderedDict, so the ordering is lost before reaching the OrderedDict.


In addition, using an ordered dict makes is hard to third party 
extension to add and use any non-declared flag.



> +
> +def unregister(self, transformmap):
> +"""Unregister transforms for flags."""
> +for flag in 

Re: [PATCH 08 of 10 V10] pull: use `bookmarks` bundle2 part

[Pierre-Yves David]

Sorry for the long delay, I've been far too busy in November,

There is a couple thing that you could do to help getting a lower 
latency on such review. (actual answer to actual question are available 
inline)


[CCing me on patch series]

Do not automatically CC me on all your series (especially the 10 patches 
ones). Otherwise part I really should be looking at get drown into other 
works.


  I've a special email folder for "stuff on Mercurial-devel that I'm a 
direct recipient to". This usually get a handful of email per day in it 
and help me to keep low latency on active discussion. The low amount of 
email there means the reply to my question will stand out even if tens 
or hundred of emails have stacked in my mail mercurial-devel folder. In 
addition, these are email with ongoing discussion for most of them will 
have a couple of focused questions that I can be processed quickly. 
CCing me on new series defeat these two properties: the traffic in that 
folder get too high for me to handle it without a proper chunk of time 
and getting new patches in there means I needs to do a full review of 
the content instead of replying to  simple question.


  So do not worry and do not CC me on resent. I'll spot resend when I 
scan through patchwork and look at them, especially if they are close to 
completion.


[Getting my attention on specific questions]

That said, if a discussion get to a point were people want my attention 
on a specific details, feel free to CC me so that I can spot the 
question (this will only work if this is not drown as a reply of a 
series I'm not CC one in the first place). In addition you can reply to 
some specific patch in your series and CC me if you thing some specific 
patches/hunks especially needs my attention.


[send smaller series]

It is recommended to send series of 6 patches or less. In the case of 
this series, there is some intermediate group that can be identified. 
eg: patches 1-3 (they got push independently),  patches 4-5 (move to 
binary encoding internally) and patches 6-10 (bundle2 part).

Having smaller series:
 * will make them easier to pick up for reviewers,
 * reduce overall traffic on the list because later patch in the series 
are likely to get impacted by the review of the earlier one,
 * avoid getting to V11 for your series (as each bits, can start at V1) 
This make it simpler for other to follow the feedback a series received 
in the past.


[upgrade your email client]

I'm not sure what you are using now, but it seems unable to provide a 
text version with proper quoting. (see how Greg and your answer get 
mixed). Using an email that actually can do email would help other 
people to follow the review discussion.


On 11/22/2016 11:14 AM, Stanislau Hlebik wrote:

From: Gregory Szorc 
Date: Tuesday, November 22, 2016 at 3:48 AM
To: Stanislau Hlebik 
Cc: mercurial-devel , Pierre-Yves David 

Subject: Re: [PATCH 08 of 10 V10] pull: use `bookmarks` bundle2 part

On Sun, Nov 20, 2016 at 4:14 AM, Stanislau Hlebik 
> wrote:
# HG changeset patch
# User Stanislau Hlebik >
# Date 1479373181 28800
#  Thu Nov 17 00:59:41 2016 -0800
# Node ID 2ac3e9d5983f18f94a1df84317d1d2f1bd9b88b8
# Parent  5af41d2c5226c36d5a1f999ff3d99d8694ae68b9
pull: use `bookmarks` bundle2 part

Apply changes from `bookmarks` part.

diff --git a/mercurial/exchange.py b/mercurial/exchange.py
--- a/mercurial/exchange.py
+++ b/mercurial/exchange.py
@@ -1335,9 +1335,13 @@
 kwargs['cg'] = pullop.fetch
 if 'listkeys' in pullop.remotebundle2caps:
 kwargs['listkeys'] = ['phases']
-if pullop.remotebookmarks is None:
-# make sure to always includes bookmark data when migrating
-# `hg incoming --bundle` to using this function.
+
+if pullop.remotebookmarks is None:
+# make sure to always includes bookmark data when migrating
+# `hg incoming --bundle` to using this function.
+if 'bookmarks' in pullop.remotebundle2caps:
+kwargs['bookmarks'] = True
+elif 'listkeys' in pullop.remotebundle2caps:

This is already inside an `if 'listkeys' in pullop.remotebundle2caps:` block, so this can 
simply be "else:".

No, it’s not inside `if 'listkeys' in pullop.remotebundle2caps:`, it’s in 
different block so I have to use elif

 kwargs['listkeys'].append('bookmarks')

 # If this is a full pull / clone and the server supports the clone bundles
@@ -1365,10 +1369,23 @@
 _pullbundle2extraprepare(pullop, kwargs)
 bundle = pullop.remote.getbundle('pull', **kwargs)
 try:
-op = bundle2.processbundle(pullop.repo, bundle, pullop.gettransaction)
+bundleopbehavior = {
+'processbookmarksmode': 'diverge',
+'explicitbookmarks': pullop.explicitbookmarks,
+'remotepath': 

Re: File Name Patterns Plan

[Pierre-Yves David]

On 11/24/2016 08:22 PM, FUJIWARA Katsunori wrote:

At Thu, 24 Nov 2016 17:04:38 +0100,
Pierre-Yves David wrote:


Recently, Foozy created a Plan page for the matcher issues:

https://www.mercurial-scm.org/wiki/FileNamePatternsPlan

It is a good start but there is a couple of elements that are
missing or still a bit fuzzy to me.


Thank you for comments !

I'll investigate and update Wiki page later, to prevent my sleepy
brain from incorrectly thinking :-)

This reply is just FYI about easy/clear points, to refer until
updating Wiki page, even though you may know them already.

We should open new discussion thread citing some of points, which this
mail metions, in devel-ml ASAP, to avoid scattering discussion log
here and there, shouldn't we ?



1) Default matcher:

   What is the default pattern mode ?

   When one do `hg files FOO` how is FOO processed. It seems like to be
   'relpath:'. Double checking this would be useful and mentioning it
   on the page is important.


Basically:

  ===  =
  (default)
  casetype recursion
  ===  =
  -I/-X   glob:   o
  "glob:" in hgignore relglob:o (*1)
  pattern in fileset  glob:   x (*2)
  other "glob:"   glob:   x (*2)
  otherwise   relpath:o (*2) (*3)
  ===  =

(*1) treated as "include" of match.match() internally
(*2) treated as "pats" of match.match() internally
(*3) usually, via scmutil.match() with default="relpath"

But:


2) Difference in command behavior:

   There seems to be some commands behaving differently than other,
   notably `hg locates` have some strange kind of
   raw-non-recursive-any-rooted matching by default. It seems to go back to
   'relpath:' when using -I

   I wonder if there is other commands like this. It might be useful to
   search for the default matcher on a command/flag basis.


Oh, I overlooked that:

  - "hg files" uses "relpath:" as default of scmutil.match(), but
  - "hg locate" uses "relglob:" explicitly

(early commits introducing "hg files" may know why)


not really edf07a804ac41433e37d92a9809c6a9ec669c8ad is not very 
talkative about it:


  files: add new command unifying locate and manifest functionality

The fact 'hg locate' used a different pattern-type by default might have 
been one of the motivation. I wonder is there is other "inconsistent" 
extension.



3) Recursion behavior,

There is some data about this in the page, but I think we need more
formal representation to have a clear view of the situation.

The existing 'path:' and 'relpath:' are recursive in all cases,
while 'glob:' and 're:' variants are only recursive with -I/-E.
This is a key point because as far as I understand fixing this is a
core goal of the current plan.


  while 'glob:' variants are only recursive with -I/-X

  ('re:' is always recursive)


Gah… So we have:

 path → recursive
 glob → not recursive (because you can make it recursive using '**")
 re → not recursive (because you can make it nont recursive using '$')




However, Foozy point out that using 'set:' with -I disable the
automatic recursion for 're' and 'glob', but not for 'path', so we
have more "variants" here.


  using 'set:' with -I disable the automatic recursion for 'glob', but
  not for 're' and 'path'

  ('re:' is always recursive)


But in that context we can use '$' to disable the recursion ?


(bonus point: Rodrigo use case can we fulfilled by adding 'set:' to
his selector.)

I also wonder if there is other variants than "pattern", "-I" and
"-I + set:".

Having a table with 'pattern-type / usage' listing the recursive
case would probably be a good start.


I'll investigate.



4) Reading from file,

   Foozy mention the pattern name in some file (hgignore) does not
   match pattern name on the command line.

   I think it would be useful to be a bit more formal here. What kind
   of file do we read pattern from? Do we have difference from 1 file
   to another? what are the translation (and default), etc.


match.readpatternfile() substitutes pattern-type in files read in.

glob => relglob
re   => relre

https://www.mercurial-scm.org/repo/hg/file/4.0/mercurial/match.py#l666

In Mercurial core, .hgignore (and files indirectly included by it or
hgrc) is only one case.


We should probably make sure the wiki page contains this.


5) Pattern-type table

   Foozy made many table explaining how variants are covered by
   pattern type. Having a pattern centric summary will be useful.

   Proposal for columns:

   * pattern type;
   * from cli or file;
   * matching mode (raw, glob, or re),
   * rooting (root, cwd or any),
   * recursive when used as Pattern
   * recursive when used with -I

   Having the same table for the proposed keyword would help to
   understand inconsistency and similarity with


I'll update Wiki page.

[Bug 5437] New: Selecting a partial chunk in revert -i reverts the whole chunk

[bugzilla]

https://bz.mercurial-scm.org/show_bug.cgi?id=5437

Bug ID: 5437
   Summary: Selecting a partial chunk in revert -i reverts the
whole chunk
   Product: Mercurial
   Version: default branch
  Hardware: PC
OS: Mac OS
Status: UNCONFIRMED
  Severity: feature
  Priority: wish
 Component: Mercurial
  Assignee: bugzi...@selenic.com
  Reporter: dur...@fb.com
CC: mercurial-de...@selenic.com

When using ui.interface=curses, you can run 'hg revert -i --all' to
interactively select which parts you want to revert.  But if you choose only
certain lines from a chunk, revert will actually revert the entire chunk.

It repros at the tip of default, and in 3.9.  So I assume it's not a recent
regression.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3 V3] memctx: allow the memlightctx thats reusing the manifest node

[Augie Fackler]

On Fri, Nov 25, 2016 at 12:15:57PM +, Mateusz Kwapich wrote:
> I like the relocate idea. It would be an useful abstractions - we have a
> lot of things that are rewriting one commit at a time.

These patches are queued with the rename of the class performed. Thanks!

>
> Excerpts from Jun Wu's message of 2016-11-22 22:18:59 +:
> > Excerpts from Augie Fackler's message of 2016-11-21 18:26:16 -0500:
> > > Also, could histedit be updated to use this for 'mess' actions
> > > perhaps? Probably not easy, but if it is I'd love to see an in-tree
> > > client of this class. Can you take a look?
> >
> > It does not work if "mess" happens after other csets creating new manifests.
> >
> > Instead of making it a special for histedit. I'm always more interested in
> > a general purpose lower-level function doing some kind of "rebase" in core,
> > that smartly deals with this case and handles bookmark and dirstate parent
> > movements (and obsmarker creation) automatically.
> >
> > There are currently multiple places reinventing the logic over and over:
> >   - absorb / collate
> >   - rebase
> >   - histedit
> >   - evolve
> >
> > And once we have this API in core, we can migrate the above commands to use
> > it.
> >
> > I'm thinking about something like:
> >
> >   relocate(origctx, newparents, fileoverrides, metaoverrides, obsoleted,
> >transaction)
> >   # origctx: context
> >   # newparents: [node]
> >   # fileoverrides: abstract dict, keys: path, value: (content, mode, 
> > renamed)
> >   # metaoverrides: dict with defined set of keys. to override metadata like
> >   #commit message etc.
> >   # obsoleted: bool, could also be a non-bool to provide more metadata
> >
> > Then relocate will choose what *ctx to use internally. For absorb,
> > metaoverrides is empty, for metaedit, fileoverrides is empty. For rebase,
> > both are empty. For histedit, depends.
> >
> > Two things I'd like to make sure they are considered while developing the
> > API:
> >
> >   1. Giant files friendly - if we need to commit two giant files, we don't
> >  need to keep both of them in memory. "fileoverrides" being an abstract
> >  dict should solve this.
> >   2. Commit hooks friendly - if any commit hook is requiring a working copy,
> >  fallback to the slow path that writs the disk. (this could be the most
> >  complex part of the implementation, but I guess crecord-alike already
> >  has similar things). We also need to have ways to mark a commit hook as
> >  "do not require on-disk working copy" - could be a config option, or
> >  checking some magic string in the hook itself.
> >
> > If we decide to go this way, I could help start some more formal discussion
> > (a plan page or so) - hopefully we can collect enough corner cases that
> > need support, have a final decision about the API soon.
> >
> > CC smf because it could be related to your memctx work.
>
> --
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 8 of 8 V2] protocol: send application/mercurial-0.2 responses to capable clients

[Durham Goode]

Cc Jeremy

On 12/2/16, 1:41 PM, "Augie Fackler"  wrote:

On Mon, Nov 28, 2016 at 10:58:25PM -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1480399779 28800
> #  Mon Nov 28 22:09:39 2016 -0800
> # Node ID b39ac39041fb47bee2ff9aa49212b84ad83138ae
> # Parent  64c2f7a3f0f2ea73552d6134035335699e450833
> protocol: send application/mercurial-0.2 responses to capable clients

I'm overall happy with this, maybe wait a few days for other comments
on your negotiation protocol (Kyle, maybe you want to take a look?
perhaps someone from Facebook too? Durham, I didn't have an email for
jsgf but it seems like he might be a good one to have a glance at this
stuff) design and then send the patches I didn't take as a v3 (with at
least the one test cleanup I pointed out), and we'll land this?

Thanks!

>
> With this commit, the HTTP transport now parses the X-HgProto header
> to determine what media type and compression engine to use for
> responses. So far, we only compress responses that are already being
> compressed with zlib today (stream response types to specific
> commands). We can expand things to cover additional response types
> later.
>

[...]


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

Re: [PATCH 8 of 8 V2] protocol: send application/mercurial-0.2 responses to capable clients

[Augie Fackler]

On Mon, Nov 28, 2016 at 10:58:25PM -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1480399779 28800
> #  Mon Nov 28 22:09:39 2016 -0800
> # Node ID b39ac39041fb47bee2ff9aa49212b84ad83138ae
> # Parent  64c2f7a3f0f2ea73552d6134035335699e450833
> protocol: send application/mercurial-0.2 responses to capable clients

I'm overall happy with this, maybe wait a few days for other comments
on your negotiation protocol (Kyle, maybe you want to take a look?
perhaps someone from Facebook too? Durham, I didn't have an email for
jsgf but it seems like he might be a good one to have a glance at this
stuff) design and then send the patches I didn't take as a v3 (with at
least the one test cleanup I pointed out), and we'll land this?

Thanks!

>
> With this commit, the HTTP transport now parses the X-HgProto header
> to determine what media type and compression engine to use for
> responses. So far, we only compress responses that are already being
> compressed with zlib today (stream response types to specific
> commands). We can expand things to cover additional response types
> later.
>

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

Re: [PATCH 6 of 8 V2] httppeer: assign Vary request header last

[Augie Fackler]

On Mon, Nov 28, 2016 at 10:58:23PM -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1480396071 28800
> #  Mon Nov 28 21:07:51 2016 -0800
> # Node ID df89cc275198b7ebebf2f9a477a1886c5fef2288
> # Parent  36c296adbfabc1f7301dd6f94b5f4515e6a61b81
> httppeer: assign Vary request header last

Took this one too, it's inevitable we'll want this cleanup.

>
> In preparation for adding another value to it in a subsequent patch.
>
> While I was here, I added some empty lines because walls of text
> are hard to read.
>
> diff --git a/mercurial/httppeer.py b/mercurial/httppeer.py
> --- a/mercurial/httppeer.py
> +++ b/mercurial/httppeer.py
> @@ -111,6 +111,7 @@ class httppeer(wireproto.wirepeer):
>  self.ui.debug("sending %s command\n" % cmd)
>  q = [('cmd', cmd)]
>  headersize = 0
> +varyheaders = []
>  # Important: don't use self.capable() here or else you end up
>  # with infinite recursion when trying to look up capabilities
>  # for the first time.
> @@ -137,13 +138,11 @@ class httppeer(wireproto.wirepeer):
>  headerfmt = 'X-HgArg-%s'
>  contentlen = headersize - len(headerfmt % '000' + ': \r\n')
>  headernum = 0
> -varyheaders = []
>  for i in xrange(0, len(encargs), contentlen):
>  headernum += 1
>  header = headerfmt % str(headernum)
>  headers[header] = encargs[i:i + contentlen]
>  varyheaders.append(header)
> -headers['Vary'] = ','.join(varyheaders)
>  else:
>  q += sorted(args.items())
>  qs = '?%s' % urlreq.urlencode(q)
> @@ -158,7 +157,10 @@ class httppeer(wireproto.wirepeer):
>  headers['X-HgHttp2'] = '1'
>  if data is not None and 'Content-Type' not in headers:
>  headers['Content-Type'] = 'application/mercurial-0.1'
> +
> +headers['Vary'] = ','.join(varyheaders)
>  req = self.requestbuilder(cu, data, headers)
> +
>  if data is not None:
>  self.ui.debug("sending %s bytes\n" % size)
>  req.add_unredirected_header('Content-Length', '%d' % size)
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 5 of 8 V2] wireproto: advertise supported compression formats in capabilities

[Augie Fackler]

On Mon, Nov 28, 2016 at 10:58:22PM -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1480395590 28800
> #  Mon Nov 28 20:59:50 2016 -0800
> # Node ID 36c296adbfabc1f7301dd6f94b5f4515e6a61b81
> # Parent  52cbc32c11454f5a72ea233ea49fed41eaec6407
> wireproto: advertise supported compression formats in capabilities
>
> This commit introduces support for advertising a server capability
> listing available compression formats.
>

[...]

> diff --git a/tests/test-http-protocol.t b/tests/test-http-protocol.t
> new file mode 100644
> --- /dev/null
> +++ b/tests/test-http-protocol.t
> @@ -0,0 +1,44 @@
> +  $ cat >> $HGRCPATH << EOF
> +  > [web]
> +  > push_ssl = false
> +  > allow_push = *
> +  > EOF
> +
> +  $ hg init server
> +  $ cd server
> +  $ touch a
> +  $ hg -q commit -A -m initial
> +  $ cd ..
> +
> +  $ hg -R server serve -p $HGPORT -d --pid-file hg.pid
> +  $ cat hg.pid >> $DAEMON_PIDS
> +
> +compression formats are advertised in compression capability
> +
> +#if zstd
> +  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' 
> | grep compression
> +  compression=zstd,zlib
> +#else
> +  $ get-with-headers.py 127.0.0.1:$HGPORT '?cmd=capabilities' | tr ' ' '\n' 
> | grep compression
> +  compression=ZL
> +#endif

I'm guessing this ZL is a remnant from the previous cycle and it should be zlib?

> +
> +  $ killdaemons.py
> +
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 8 V2] wireproto: only advertise HTTP-specific capabilities to HTTP peers (BC)

[Augie Fackler]

On Mon, Nov 28, 2016 at 10:58:19PM -0800, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc 
> # Date 1480394802 28800
> #  Mon Nov 28 20:46:42 2016 -0800
> # Node ID e32ff1ce869243618aaab30bb6fba2b13be536ff
> # Parent  05d19f908c3abf62e2ed6d453a8cd52bbc727408
> wireproto: only advertise HTTP-specific capabilities to HTTP peers (BC)

I've taken these two, still looking at the rest.

>
> Previously, the capabilities list was protocol agnostic and we
> advertised the same capabilities list to all clients, regardless of
> transport protocol.
>
> A few capabilities are specific to HTTP. I see no good reason why we
> should advertise them to SSH clients. So this patch limits their
> advertisement to HTTP clients.
>
> This patch is BC, but SSH clients shouldn't be using the removed
> capabilities so there should be no impact.
>
> diff --git a/mercurial/wireproto.py b/mercurial/wireproto.py
> --- a/mercurial/wireproto.py
> +++ b/mercurial/wireproto.py
> @@ -716,10 +716,13 @@ def _capabilities(repo, proto):
>  capsblob = bundle2.encodecaps(bundle2.getrepocaps(repo))
>  caps.append('bundle2=' + urlreq.quote(capsblob))
>  caps.append('unbundle=%s' % ','.join(bundle2.bundlepriority))
> -caps.append(
> -'httpheader=%d' % repo.ui.configint('server', 'maxhttpheaderlen', 
> 1024))
> -if repo.ui.configbool('experimental', 'httppostargs', False):
> -caps.append('httppostargs')
> +
> +if proto.name == 'http':
> +caps.append('httpheader=%d' %
> +repo.ui.configint('server', 'maxhttpheaderlen', 1024))
> +if repo.ui.configbool('experimental', 'httppostargs', False):
> +caps.append('httppostargs')
> +
>  return caps
>
>  # If you are writing an extension and consider wrapping this function. Wrap
> diff --git a/tests/test-ssh-bundle1.t b/tests/test-ssh-bundle1.t
> --- a/tests/test-ssh-bundle1.t
> +++ b/tests/test-ssh-bundle1.t
> @@ -464,8 +464,8 @@ debug output
>running python ".*/dummyssh" user@dummy ('|")hg -R remote serve 
> --stdio('|") (re)
>sending hello command
>sending between command
> -  remote: 371
> -  remote: capabilities: lookup changegroupsubset branchmap pushkey known 
> getbundle unbundlehash batch streamreqs=generaldelta,revlogv1 
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>  unbundle=HG10GZ,HG10BZ,HG10UN httpheader=1024
> +  remote: 355
> +  remote: capabilities: lookup changegroupsubset branchmap pushkey known 
> getbundle unbundlehash batch streamreqs=generaldelta,revlogv1 
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>  unbundle=HG10GZ,HG10BZ,HG10UN
>remote: 1
>preparing listkeys for "bookmarks"
>sending listkeys command
> diff --git a/tests/test-ssh.t b/tests/test-ssh.t
> --- a/tests/test-ssh.t
> +++ b/tests/test-ssh.t
> @@ -467,8 +467,8 @@ debug output
>running python ".*/dummyssh" user@dummy ('|")hg -R remote serve 
> --stdio('|") (re)
>sending hello command
>sending between command
> -  remote: 371
> -  remote: capabilities: lookup changegroupsubset branchmap pushkey known 
> getbundle unbundlehash batch streamreqs=generaldelta,revlogv1 
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>  unbundle=HG10GZ,HG10BZ,HG10UN httpheader=1024
> +  remote: 355
> +  remote: capabilities: lookup changegroupsubset branchmap pushkey known 
> getbundle unbundlehash batch streamreqs=generaldelta,revlogv1 
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>  unbundle=HG10GZ,HG10BZ,HG10UN
>remote: 1
>query 1; heads
>sending batch command
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2] formatter: add overview of API and example as doctest

[Augie Fackler]

On Mon, Nov 28, 2016 at 10:46:04PM +0900, Yuya Nishihara wrote:
> On Sun, 27 Nov 2016 14:26:03 +, Kostia Balytskyi wrote:
> > I like this and previous patch, but if the purpose of this one is to provide
> > examlpes to developers, should we maybe also include debugformatter?
>
> Good point, but debugformatter uses repr() so the output order is unstable.
> I think jsonformatter serves well for debugging output.

Queued, thanks! Maybe I'll get some formatter love on some things now
that I've got some examples :D

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

Re: [PATCH 2 of 2 V2] check-code: add a rule to forbid "cp -r"

[Augie Fackler]

On Wed, Nov 30, 2016 at 07:26:44PM +, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu 
> # Date 1480533784 0
> #  Wed Nov 30 19:23:04 2016 +
> # Node ID ff3e01283fa1843920ad63dc1ff7bc6b0a4dbccb
> # Parent  830986c78bb9697057768d64c8556d1dc03c0674
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #  hg pull https://bitbucket.org/quark-zju/hg-draft -r 
> ff3e01283fa1
> check-code: add a rule to forbid "cp -r"
>
> See the commit message of the previous patch for the reason. In short,
> according to the current POSIX standard, "-r" is "removed", and "-R" is the
> current standard way to do "copy file hierarchies".

Nice work. Thanks much for citing the POSIX chapter and verse too,
because I would have had to go digging for that as "removal" of -r
seems hilarious to me.

Queued.

>
> diff --git a/contrib/check-code.py b/contrib/check-code.py
> --- a/contrib/check-code.py
> +++ b/contrib/check-code.py
> @@ -143,5 +143,6 @@ testpats = [
>  (r'\w =  +\w', "only one space after = allowed"),
>  (r'\bsed\b.*[^\\]\\n', "don't use 'sed ... \\n', use a \\ and a 
> newline"),
> -(r'env.*-u', "don't use 'env -u VAR', use 'unset VAR'")
> +(r'env.*-u', "don't use 'env -u VAR', use 'unset VAR'"),
> +(r'cp.* -r ', "don't use 'cp -r', use 'cp -R'"),
>],
># warnings
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH] posix: give the cached symlink a real target

[Augie Fackler]

On Wed, Nov 30, 2016 at 04:58:28PM +, Jun Wu wrote:
> Looks good to me. Thanks for the fix!
> A small nit inline - probably could be fixed on flight.
>
> Excerpts from Martijn Pieters's message of 2016-11-30 16:51:41 +:
> > # HG changeset patch
> > # User Martijn Pieters 
> > # Date 1480523976 0
> > #  Wed Nov 30 16:39:36 2016 +
> > # Node ID 4053f60f77657f8f54afc72d00bf629b75d0b4b9
> > # Parent  9e29d4e4e08b5996adda49cdd0b497d89e2b16ee
> > posix: give the cached symlink a real target
> >
> > The NamedTemporaryFile file is cleared up so checklink ends up as a dangling
> > symlink, causing cp -r in tests to complain on both Solaris and OS X. Use
> > a permanent file instead when there is a .hg/cache directory.
> >
> > diff --git a/mercurial/posix.py b/mercurial/posix.py
> > --- a/mercurial/posix.py
> > +++ b/mercurial/posix.py
> > @@ -231,10 +231,18 @@
> >  cachedir = None
> >  name = tempfile.mktemp(dir=checkdir, prefix='checklink-')
> >  try:
> > -fd = tempfile.NamedTemporaryFile(dir=checkdir,
> > - prefix='hg-checklink-')
> > +fd = None
> > +if cachedir is None:
> > +fd = tempfile.NamedTemporaryFile(dir=checkdir,
> > + prefix='hg-checklink-')
> > +target = os.path.basename(fd.name)
> > +else:
> > +# create a fixed file to link to; doesn't matter if it
> > +# already exists.
> > +target = 'checklink-target'
> > +open(os.path.join(cachedir, target), 'w')
>
> Should we append ".close()" here to just make things explicit?

Indeed we should, this risks file handle leaks on pypy et al. Queued
with .close() added in flight.

>
> >  try:
> > -os.symlink(os.path.basename(fd.name), name)
> > +os.symlink(target, name)
> >  if cachedir is None:
> >  os.unlink(name)
> >  else:
> > @@ -249,7 +257,8 @@
> >  continue
> >  raise
> >  finally:
> > -fd.close()
> > +if fd is not None:
> > +fd.close()
> >  except AttributeError:
> >  return False
> >  except OSError as inst:
> > diff --git a/tests/test-clone.t b/tests/test-clone.t
> > --- a/tests/test-clone.t
> > +++ b/tests/test-clone.t
> > @@ -33,6 +33,7 @@
> >branch2-served
> >checkisexec
> >checklink
> > +  checklink-target
> >checknoexec
> >rbc-names-v1
> >rbc-revs-v1
> > @@ -50,6 +51,7 @@
> >branch2-served
> >checkisexec
> >checklink
> > +  checklink-target
> >
> >$ cat a
> >a
> > diff --git a/tests/test-hardlinks.t b/tests/test-hardlinks.t
> > --- a/tests/test-hardlinks.t
> > +++ b/tests/test-hardlinks.t
> > @@ -212,6 +212,8 @@
> >2 r4/.hg/branch
> >2 r4/.hg/cache/branch2-served
> >2 r4/.hg/cache/checkisexec
> > +  3 r4/.hg/cache/checklink (?)
> > +  ? r4/.hg/cache/checklink-target (glob)
> >2 r4/.hg/cache/checknoexec
> >2 r4/.hg/cache/rbc-names-v1
> >2 r4/.hg/cache/rbc-revs-v1
> > @@ -250,6 +252,7 @@
> >1 r4/.hg/branch
> >2 r4/.hg/cache/branch2-served
> >2 r4/.hg/cache/checkisexec
> > +  2 r4/.hg/cache/checklink-target
> >2 r4/.hg/cache/checknoexec
> >2 r4/.hg/cache/rbc-names-v1
> >2 r4/.hg/cache/rbc-revs-v1
> > diff --git a/tests/test-tags.t b/tests/test-tags.t
> > --- a/tests/test-tags.t
> > +++ b/tests/test-tags.t
> > @@ -674,6 +674,7 @@
> >branch2-served
> >checkisexec
> >checklink
> > +  checklink-target
> >hgtagsfnodes1
> >rbc-names-v1
> >rbc-revs-v1
> > @@ -700,6 +701,7 @@
> >branch2-served
> >checkisexec
> >checklink
> > +  checklink-target
> >hgtagsfnodes1
> >rbc-names-v1
> >rbc-revs-v1
> ___
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] push: add a message when pushing phases but not changes

[Jeremy Wall (zaphar)]

# HG changeset patch
# User Jeremy Wall (zaphar) 
# Date 1480542942 21600
#  Wed Nov 30 15:55:42 2016 -0600
# Node ID 9cb1540e417dc79a55944adffb691a3ada01571c
# Parent  9e29d4e4e08b5996adda49cdd0b497d89e2b16ee
push: add a message when pushing phases but not changes

This is an attempt to fix
https://bz.mercurial-scm.org/show_bug.cgi?id=4232

diff -r 9e29d4e4e08b -r 9cb1540e417d mercurial/exchange.py
--- a/mercurial/exchange.py Tue Nov 29 04:11:05 2016 -0800
+++ b/mercurial/exchange.py Wed Nov 30 15:55:42 2016 -0600
@@ -14,6 +14,7 @@
 from .node import (
 hex,
 nullid,
+short,
 )
 from . import (
 base85,
@@ -643,9 +644,20 @@
 def _pushcheckoutgoing(pushop):
 outgoing = pushop.outgoing
 unfi = pushop.repo.unfiltered()
+ui = unfi.ui
 if not outgoing.missing:
-# nothing to push
-scmutil.nochangesfound(unfi.ui, unfi, outgoing.excluded)
+# TODO(jeremy): Question? Should I be worrying about
+# fallbackoutdatedphases here too?
+# phases to push
+if pushop.outdatedphases:
+for outphase in pushop.outdatedphases:
+# TODO(jeremy): Is this the right way to report this?
+ui.status(_("sending phase %s for %s\n") %
+  (outphase.phasestr(), short(outphase.node(
+# TODO(jeremy): Do I still return false?
+else:
+# nothing to push
+scmutil.nochangesfound(ui, unfi, outgoing.excluded)
 return False
 # something to push
 if not pushop.force:
diff -r 9e29d4e4e08b -r 9cb1540e417d tests/test-phases-exchange.t
--- a/tests/test-phases-exchange.t  Tue Nov 29 04:11:05 2016 -0800
+++ b/tests/test-phases-exchange.t  Wed Nov 30 15:55:42 2016 -0600
@@ -384,7 +384,7 @@
   $ hg push ../alpha # from nu
   pushing to ../alpha
   searching for changes
-  no changes found
+  sending phase public for 145e75495359
   [1]
   $ cd ..
   $ cd alpha
@@ -600,7 +600,7 @@
   $ hg push ../alpha
   pushing to ../alpha
   searching for changes
-  no changes found
+  sending phase public for b740e3e5c05d
   [1]
   $ hgph
   o  6 public a-F - b740e3e5c05d
@@ -705,7 +705,7 @@
   $ hg push ../alpha
   pushing to ../alpha
   searching for changes
-  no changes found
+  sending phase draft for 967b449fbc94
   [1]
   $ hgph
   o  9 public a-H - 967b449fbc94
diff -r 9e29d4e4e08b -r 9cb1540e417d tests/test-push-warn.t
--- a/tests/test-push-warn.tTue Nov 29 04:11:05 2016 -0800
+++ b/tests/test-push-warn.tWed Nov 30 15:55:42 2016 -0600
@@ -125,7 +125,7 @@
   $ hg push -r 2 ../c
   pushing to ../c
   searching for changes
-  no changes found
+  sending phase public for d9f42cd1a1ec
   [1]
 
   $ hg push -r 3 ../c
diff -r 9e29d4e4e08b -r 9cb1540e417d tests/test-subrepo.t
--- a/tests/test-subrepo.t  Tue Nov 29 04:11:05 2016 -0800
+++ b/tests/test-subrepo.t  Wed Nov 30 15:55:42 2016 -0600
@@ -1519,7 +1519,13 @@
 (issue3781)
 
   $ cp -r main issue3781
+  cp: main/.hg/cache/checklink: No such file or directory
+  cp: main/s/.hg/cache/checklink: No such file or directory
+  [1]
   $ cp -r main issue3781-dest
+  cp: main/.hg/cache/checklink: No such file or directory
+  cp: main/s/.hg/cache/checklink: No such file or directory
+  [1]
   $ cd issue3781-dest/s
   $ hg phase tip # show we have draft changeset
   5: draft
@@ -1535,7 +1541,8 @@
   searching for changes
   no changes found
   searching for changes
-  no changes found
+  sending phase draft for d6125d9cc876
+  sending phase draft for 8bd5629adcbe
   [1]
 # clean the push cache
   $ rm s/.hg/cache/storehash/*
diff -r 9e29d4e4e08b -r 9cb1540e417d tests/test-treediscovery-legacy.t
--- a/tests/test-treediscovery-legacy.t Tue Nov 29 04:11:05 2016 -0800
+++ b/tests/test-treediscovery-legacy.t Wed Nov 30 15:55:42 2016 -0600
@@ -115,7 +115,7 @@
   $ hg push $remote
   pushing to http://localhost:$HGPORT/
   searching for changes
-  no changes found
+  sending phase public for a19bfa7e7328
   [1]
   $ cd ..
 
diff -r 9e29d4e4e08b -r 9cb1540e417d tests/test-treediscovery.t
--- a/tests/test-treediscovery.tTue Nov 29 04:11:05 2016 -0800
+++ b/tests/test-treediscovery.tWed Nov 30 15:55:42 2016 -0600
@@ -104,7 +104,7 @@
   $ hg push $remote
   pushing to http://localhost:$HGPORT/
   searching for changes
-  no changes found
+  sending phase public for a19bfa7e7328
   [1]
   $ cd ..
 
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: File Name Patterns Plan

[FUJIWARA Katsunori]

At Thu, 24 Nov 2016 17:04:38 +0100,
Pierre-Yves David wrote:
> 
> Recently, Foozy created a Plan page for the matcher issues:
> 
> https://www.mercurial-scm.org/wiki/FileNamePatternsPlan
> 
> It is a good start but there is a couple of elements that are
> missing or still a bit fuzzy to me.
> 
> 
> 1) Default matcher:
> 
>What is the default pattern mode ?
> 
>When one do `hg files FOO` how is FOO processed. It seems like to be
>'relpath:'. Double checking this would be useful and mentioning it
>on the page is important.
> 
> 2) Difference in command behavior:
> 
>There seems to be some commands behaving differently than other,
>notably `hg locates` have some strange kind of
>raw-non-recursive-any-rooted matching by default. It seems to go back to
>'relpath:' when using -I
> 
>I wonder if there is other commands like this. It might be useful to
>search for the default matcher on a command/flag basis.
> 
> 3) Recursion behavior,
> 
> There is some data about this in the page, but I think we need more
> formal representation to have a clear view of the situation.
> 
> The existing 'path:' and 'relpath:' are recursive in all cases,
> while 'glob:' and 're:' variants are only recursive with -I/-E.
> This is a key point because as far as I understand fixing this is a
> core goal of the current plan.
> 
> However, Foozy point out that using 'set:' with -I disable the
> automatic recursion for 're' and 'glob', but not for 'path', so we
> have more "variants" here.
> 
> (bonus point: Rodrigo use case can we fulfilled by adding 'set:' to
> his selector.)
> 
> I also wonder if there is other variants than "pattern", "-I" and
> "-I + set:".
> 
> Having a table with 'pattern-type / usage' listing the recursive
> case would probably be a good start.
> 
> 4) Reading from file,
> 
>Foozy mention the pattern name in some file (hgignore) does not
>match pattern name on the command line.
> 
>I think it would be useful to be a bit more formal here. What kind
>of file do we read pattern from? Do we have difference from 1 file
>to another? what are the translation (and default), etc.
>
> 5) Pattern-type table
> 
>Foozy made many table explaining how variants are covered by
>pattern type. Having a pattern centric summary will be useful.
> 
>Proposal for columns:
> 
>* pattern type;
>* from cli or file;
>* matching mode (raw, glob, or re),
>* rooting (root, cwd or any),
>* recursive when used as Pattern
>* recursive when used with -I
> 
>Having the same table for the proposed keyword would help to
>understand inconsistency and similarity with

For (1) - (5) above, I just revised "Current status" of
FileNamePatternsPlan wiki page like as below.

=
Summary of mode, relative-to, and recursion of each types
=

  = ===  === == =
  mode  root-ed cwd-ed   any-of-path controlcontext
 recursion  depend
 by pattern recursion
  = ===  === == =
  wildcard  --- glob:relglob:by **  o
  regexpre: ---  relre:  by $   x (*A)
  raw stringpath:   relpath: --- (always)   x
  = ===  === == =

(*A) "regexp" mode ignore pattern matches recursively (e.g. 're:^foo$'
 ignores file 'foo/bar'). Detail is explained later.

===
The list of contexts, in which pattern is specified
===

  =  === ===
  pattern for   default type recursion   related API
 of wildcard
  =  === ===
  fileset   glob: x  ctx.match()
  files() template function glob: x  ctx.match()
  diff() template function  glob: o (*1) ctx.match()

  file() revset predicate   glob: x  match.match()
  follow() revset predicate path: x  match.match()
  --include/--exclude   glob: o (*1) match.match()
  hgignore  relre:o (*1) match.match()

  'archive' web command path: - (*2) scmutil.match()
  'hg locate'   relglob:  x  scmutil.match()
  'hg log'  relpath:  x  scmutil.matchandpats()
  others (e.g. 'hg files')  relpath:  x  scmutil.match()
  =  === ===

(*1) treated as 'include'/'exclude' of match.match()
 

mercurial@30554: new changeset

[Mercurial Commits]

New changeset in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/1775975dd439
changeset:   30554:1775975dd439
bookmark:@
tag: tip
user:Kostia Balytskyi 
date:Tue Nov 29 07:20:03 2016 -0800
summary: shelve: move patch extension to a string constant

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

Re: [PATCH 3 of 3] revset: add a changes(file, fromline, toline[, rev]) revset

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2016-12-02 23:19:56 +0900:
> On Fri, 2 Dec 2016 08:38:53 +0100, Denis Laxalde wrote:
> > Yuya Nishihara a écrit :
> > > On Mon, 28 Nov 2016 11:12:35 +0100, Denis Laxalde wrote:
> > >> Denis Laxalde a écrit :
> > >>> # HG changeset patch
> > >>> # User Denis Laxalde 
> > >>> # Date 1480086890 -3600
> > >>> #  Fri Nov 25 16:14:50 2016 +0100
> > >>> # Node ID e88a112076294d9b1639a486e7ef0ec9c1ffa660
> > >>> # Parent  6dd93ae7b35002531308444c87dcf47beb773648
> > >>> # EXP-Topic linerange-log/revset
> > >>> revset: add a changes(file, fromline, toline[, rev]) revset
> > >>
> > >> This is the first step of my work (in progress) about adding a "line
> > >> range" filtering for log discussed in
> > >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/088687.html
> > >>  .
> > >>
> > >> I would have liked to add tests for this revset but it seems to me that
> > >> the current test repositories are not complex enough for this: I'd need
> > >> files with significant content and changes in this content. Any idea how
> > >> I could do this?
> > >
> > > Maybe we can share some bits with test-annotate.t ?
> > 
> > Repositories in these are indeed more complex. So should I append tests
> > in this file or reproduce similar repositories in test-revset.t?
> 
> I *think* adding tests to test-annotate.t is okay since the behavior of
> changes() revset is somewhat similar to annotate.
> 
> Jun might have more data sets for his fastannotate extension?

fastannotate basically reuses the original annotate test cases for the core
algorithm, and with some additional tests about extra features like
wireprotocol, --deleted etc.

Because fastannotate works differently from the vanilla algorithm: it tracks
'!' blocks instead of '=' blocks and it deals with p1 and p2 differently,
the output is slightly different:

bitbucket.org/facebook/hg-experimental/src/27a94a/tests/test-fastannotate-hg.t?#test-fastannotate-hg.t-229
bitbucket.org/facebook/hg-experimental/src/27a94a/tests/test-fastannotate-hg.t?#test-fastannotate-hg.t-324

With the recent bdiff change, fastannotate became more different from the
vanilla annotate:

https://bitbucket.org/facebook/hg-experimental/commits/11c9b13fc1ef778c5636ac04e3812a06c0e4a08f
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 3] context: add a `blockancestors(fromline, toline)` method to filectx

[Yuya Nishihara]

On Fri, 2 Dec 2016 08:36:42 +0100, Denis Laxalde wrote:
> Yuya Nishihara a écrit :
> > On Mon, 28 Nov 2016 10:54:15 +0100, Denis Laxalde wrote:
> >> +def changesrange(fctx1, fctx2, linerange2):
> >> +"""Return `(diffinrange, linerange1)` where `diffinrange` is 
> >> True
> >> +if diff from fctx2 to fctx1 has changes in linerange2 and
> >> +`linerange1` is the new line range for fctx1.
> >> +"""
> >> +diffopts = patch.diffopts(self._repo.ui)
> >
> > Is it intended to take all diff options such as ignorews?
> 
> I'd say so, at least when used from the "changes" revset. Perhaps the
> function could get an opts keyword argument and defaults to this (or
> mdiff.defaultopts maybe) if unspecified. Do you see any case where this
> wouldn't be desirable?

There's an API repo.revs() which ignores user aliases explicitly. I'm not sure
if that is the case for the changes() revset, so asked. (I don't mean changes()
should disregard diff options.)

Another question is if it should see the [diff] section, [annotate], or other?
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@30553: 4 new changesets (3 on stable)

[Mercurial Commits]

4 new changesets (3 on stable) in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/b3b1ae98f6a0
changeset:   30550:b3b1ae98f6a0
branch:  stable
tag: 4.0.1
parent:  30419:819f96b82fa4
user:Wagner Bruna 
date:Fri Nov 25 07:39:02 2016 -0200
summary: i18n-pt_BR: synchronized with 819f96b82fa4

https://www.mercurial-scm.org/repo/hg/rev/80b646ad0f86
changeset:   30551:80b646ad0f86
branch:  stable
user:Kevin Bullock 
date:Thu Dec 01 14:13:23 2016 -0600
summary: Added tag 4.0.1 for changeset b3b1ae98f6a0

https://www.mercurial-scm.org/repo/hg/rev/76e970c8f530
changeset:   30552:76e970c8f530
branch:  stable
user:Kevin Bullock 
date:Thu Dec 01 14:13:28 2016 -0600
summary: Added signature for changeset b3b1ae98f6a0

https://www.mercurial-scm.org/repo/hg/rev/98033f9c0109
changeset:   30553:98033f9c0109
bookmark:@
tag: tip
parent:  30549:9e29d4e4e08b
parent:  30552:76e970c8f530
user:Kevin Bullock 
date:Thu Dec 01 15:55:45 2016 -0600
summary: merge with stable

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

Re: [PATCH 6 of 7] py3: use try/except to check for basestring

[Yuya Nishihara]

On Fri, 2 Dec 2016 04:32:47 +0530, Pulkit Goyal wrote:
> There is something strange. One of the patch you pushed and replied to
> the mail is not the same.

I've queued new versions of these patches.

> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089102.html
> >
> > Added comment.

Er, I don't remember. I guess I would wanted to tell you that I wrote some
comments to that patch.

https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090218.html
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 01 of 10 shelve-ext] shelve: move patch extension to a string constant

[Yuya Nishihara]

On Tue, 29 Nov 2016 07:22:55 -0800, Kostia Balytskyi wrote:
> # HG changeset patch
> # User Kostia Balytskyi 
> # Date 1480432803 28800
> #  Tue Nov 29 07:20:03 2016 -0800
> # Node ID f6f0ab3f7b0ea0e05cfdcd7afd4994ea21988fd9
> # Parent  64b55bffc1c059eb4c11ca195b561ca8a287f59e
> shelve: move patch extension to a string constant

Queued this first patch, thanks.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 02 of 10 shelve-ext] shelve: add an ability to write json to a new type of shelve files

[Yuya Nishihara]

On Tue, 29 Nov 2016 15:55:06 +, Jun Wu wrote:
> Excerpts from Kostia Balytskyi's message of 2016-11-29 07:22:56 -0800:
> > # HG changeset patch
> > # User Kostia Balytskyi 
> > # Date 1480426193 28800
> > #  Tue Nov 29 05:29:53 2016 -0800
> > # Node ID 37119e028c699d9fabd220086e08c754827e709f
> > # Parent  f6f0ab3f7b0ea0e05cfdcd7afd4994ea21988fd9
> > shelve: add an ability to write json to a new type of shelve files
> > 
> > Obsolescense-based shelve only needs metadata stored in .hg/shelved
> > and I think that this metadata should be stored in json for
> > potential extensibility purposes. JSON is not critical here, but
> > I want to avoid storing it in an unstructured text file where
> > order of lines determines their semantical meanings (as now
> > happens in .hg/shelvedstate. .hg/rebasestate and I suspect other
> > state files as well).
> > 
> > If we want, we can refactor it to something else later.
> > 
> > diff --git a/hgext/shelve.py b/hgext/shelve.py
> > --- a/hgext/shelve.py
> > +++ b/hgext/shelve.py
> > @@ -25,6 +25,7 @@ from __future__ import absolute_import
> >  import collections
> >  import errno
> >  import itertools
> > +import json
> 
> I think we avoid using "import json" for some reason (encoding?). There is
> no "import json" in the code base yet.

Yeah, JSON is troublesome because every string must be a valid unicode. If
all strings are known to be ascii or utf-8 for instance, we could use JSON,
but we still have to convert unicode objects back to str.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: mercurial@30549: 7 new changesets

[Thomas Arendsen Hein]

* Kevin Bullock  [20161201 21:24]:
> > On Nov 30, 2016, at 01:39, Thomas Arendsen Hein  
> > wrote:
> > * Gregory Szorc  [20161130 04:53]:
> >> Anyone know what process sends these emails? It would be nice to see the
> >> URLs updated to point to https://www.mercurial-scm.org/repo/hg.
> > 
> > I generate them and just updated the URL.
> > 
> > Thank you for the reminder!
> 
> Thanks! I'd like to make it so that these come directly from the new main 
> repo. Could I convince you to send me the [notify] configuration you use to 
> do this?

Sure, I have no problem with that, but I'm not using the notify
extension, but my own shell script "hg-mailhook" from
https://hg.intevation.de/mercurial/toolbox/

See "hg-mailhook --help" for configuration options.
What I use here in .hg/hgrc of the repository is:

[hooks]
changegroup.mailhook = hg-mailhook "mercurial" \
"https://www.mercurial-scm.org/repo/hg; \
"Mercurial Commits" "h...@intevation.de" \
"Mercurial Devel "


It would be nice to be able to get this output with the notify
extension :)

Regards,
Thomas

-- 
tho...@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel