[PATCH] cleanup: remove compatibility code for Python < 2.7.4

[Manuel Jacob]

# HG changeset patch
# User Manuel Jacob 
# Date 1590717976 -7200
#  Fri May 29 04:06:16 2020 +0200
# Node ID bc05bbecf2c270b2b5533be84d1311840abcba00
# Parent  34b43eef01ed4612512ce105ed2f85ce591fe005
# EXP-Topic minimum-python-2.7.4-cleanup
cleanup: remove compatibility code for Python < 2.7.4

The minimum supported Python version was recently raised to 2.7.4.

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -2844,7 +2844,7 @@ if pyplatform.python_implementation() ==
 # [1]: fixed by changeset 67dc99a989cd in the cpython hg repo.
 #
 # Here we workaround the EINTR issue for fileobj.__iter__. Other methods
-# like "read*" are ignored for now, as Python < 2.7.4 is a minority.
+# like "read*" work fine, as we do not support Python < 2.7.4.
 #
 # Although we can workaround the EINTR issue for fp.__iter__, it is slower:
 # "for x in fp" is 4x faster than "for x in iter(fp.readline, '')" in
@@ -2856,39 +2856,6 @@ if pyplatform.python_implementation() ==
 # affects things like pipes, sockets, ttys etc. We treat "normal" (S_ISREG)
 # files approximately as "fast" files and use the fast (unsafe) code path,
 # to minimize the performance impact.
-if sys.version_info >= (2, 7, 4):
-# fp.readline deals with EINTR correctly, use it as a workaround.
-def _safeiterfile(fp):
-return iter(fp.readline, b'')
-
-else:
-# fp.read* are broken too, manually deal with EINTR in a stupid way.
-# note: this may block longer than necessary because of bufsize.
-def _safeiterfile(fp, bufsize=4096):
-fd = fp.fileno()
-line = b''
-while True:
-try:
-buf = os.read(fd, bufsize)
-except OSError as ex:
-# os.read only raises EINTR before any data is read
-if ex.errno == errno.EINTR:
-continue
-else:
-raise
-line += buf
-if b'\n' in buf:
-splitted = line.splitlines(True)
-line = b''
-for l in splitted:
-if l[-1] == b'\n':
-yield l
-else:
-line = l
-if not buf:
-break
-if line:
-yield line
 
 def iterfile(fp):
 fastpath = True
@@ -2897,7 +2864,8 @@ if pyplatform.python_implementation() ==
 if fastpath:
 return fp
 else:
-return _safeiterfile(fp)
+# fp.readline deals with EINTR correctly, use it as a workaround.
+return iter(fp.readline, b'')
 
 
 else:

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

[PATCH 1 of 2] cleanup: remove compatibility code for Python < 2.7.1

[Manuel Jacob]

# HG changeset patch
# User Manuel Jacob 
# Date 1590716588 -7200
#  Fri May 29 03:43:08 2020 +0200
# Node ID 6c86927b3d35a364fdfba9a2e45bea64d1ba7cf6
# Parent  5d77f571a56371a8dd2ae309437985e8751d152b
# EXP-Topic minimum-python-2.7.4-cleanup
cleanup: remove compatibility code for Python < 2.7.1

The minimum supported Python version was recently raised to 2.7.4.

diff --git a/mercurial/windows.py b/mercurial/windows.py
--- a/mercurial/windows.py
+++ b/mercurial/windows.py
@@ -476,9 +476,6 @@ def shellsplit(s):
 
 def quotecommand(cmd):
 """Build a command string suitable for os.popen* calls."""
-if sys.version_info < (2, 7, 1):
-# Python versions since 2.7.1 do this extra quoting themselves
-return b'"' + cmd + b'"'
 return cmd
 
 

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

[PATCH 2 of 2] cleanup: eliminate procutil.quotecommand()

[Manuel Jacob]

# HG changeset patch
# User Manuel Jacob 
# Date 1590717367 -7200
#  Fri May 29 03:56:07 2020 +0200
# Node ID 34b43eef01ed4612512ce105ed2f85ce591fe005
# Parent  6c86927b3d35a364fdfba9a2e45bea64d1ba7cf6
# EXP-Topic minimum-python-2.7.4-cleanup
cleanup: eliminate procutil.quotecommand()

After some compatibility code was removed, the function was the identity
function on all platforms.

diff --git a/hgext/convert/cvs.py b/hgext/convert/cvs.py
--- a/hgext/convert/cvs.py
+++ b/hgext/convert/cvs.py
@@ -226,8 +226,7 @@ class convert_cvs(converter_source):
 cmd = [rsh, host] + cmd
 
 # popen2 does not support argument lists under Windows
-cmd = [procutil.shellquote(arg) for arg in cmd]
-cmd = procutil.quotecommand(b' '.join(cmd))
+cmd = b' '.join(procutil.shellquote(arg) for arg in cmd)
 self.writep, self.readp = procutil.popen2(cmd)
 
 self.realroot = root
diff --git a/hgext/convert/gnuarch.py b/hgext/convert/gnuarch.py
--- a/hgext/convert/gnuarch.py
+++ b/hgext/convert/gnuarch.py
@@ -217,7 +217,7 @@ class gnuarch_source(common.converter_so
 cmdline = [procutil.shellquote(arg) for arg in cmdline]
 bdevnull = pycompat.bytestr(os.devnull)
 cmdline += [b'>', bdevnull, b'2>', bdevnull]
-cmdline = procutil.quotecommand(b' '.join(cmdline))
+cmdline = b' '.join(cmdline)
 self.ui.debug(cmdline, b'\n')
 return os.system(pycompat.rapply(procutil.tonativestr, cmdline))
 
diff --git a/hgext/convert/subversion.py b/hgext/convert/subversion.py
--- a/hgext/convert/subversion.py
+++ b/hgext/convert/subversion.py
@@ -1235,7 +1235,7 @@ class svn_source(converter_source):
 arg = encodeargs(args)
 hgexe = procutil.hgexecutable()
 cmd = b'%s debugsvnlog' % procutil.shellquote(hgexe)
-stdin, stdout = procutil.popen2(procutil.quotecommand(cmd))
+stdin, stdout = procutil.popen2(cmd)
 stdin.write(arg)
 try:
 stdin.close()
diff --git a/hgext/extdiff.py b/hgext/extdiff.py
--- a/hgext/extdiff.py
+++ b/hgext/extdiff.py
@@ -233,7 +233,6 @@ def _systembackground(cmd, environ=None,
 ''' like 'procutil.system', but returns the Popen object directly
 so we don't have to wait on it.
 '''
-cmd = procutil.quotecommand(cmd)
 env = procutil.shellenviron(environ)
 proc = subprocess.Popen(
 procutil.tonativestr(cmd),
diff --git a/mercurial/chgserver.py b/mercurial/chgserver.py
--- a/mercurial/chgserver.py
+++ b/mercurial/chgserver.py
@@ -320,7 +320,7 @@ class channeledsystem(object):
 self.channel = channel
 
 def __call__(self, cmd, environ, cwd=None, type=b'system', cmdtable=None):
-args = [type, procutil.quotecommand(cmd), os.path.abspath(cwd or b'.')]
+args = [type, cmd, os.path.abspath(cwd or b'.')]
 args.extend(b'%s=%s' % (k, v) for k, v in pycompat.iteritems(environ))
 data = b'\0'.join(args)
 self.out.write(struct.pack(b'>cI', self.channel, len(data)))
diff --git a/mercurial/posix.py b/mercurial/posix.py
--- a/mercurial/posix.py
+++ b/mercurial/posix.py
@@ -538,10 +538,6 @@ def shellsplit(s):
 return pycompat.shlexsplit(s, posix=True)
 
 
-def quotecommand(cmd):
-return cmd
-
-
 def testpid(pid):
 '''return False if pid dead, True if running or not sure'''
 if pycompat.sysplatform == b'OpenVMS':
diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
--- a/mercurial/sshpeer.py
+++ b/mercurial/sshpeer.py
@@ -179,7 +179,6 @@ def _makeconnection(ui, sshcmd, args, re
 )
 
 ui.debug(b'running %s\n' % cmd)
-cmd = procutil.quotecommand(cmd)
 
 # no buffer allow the use of 'select'
 # feel free to remove buffering and select usage when we ultimately
diff --git a/mercurial/utils/procutil.py b/mercurial/utils/procutil.py
--- a/mercurial/utils/procutil.py
+++ b/mercurial/utils/procutil.py
@@ -73,7 +73,6 @@ findexe = platform.findexe
 getuser = platform.getuser
 getpid = os.getpid
 hidewindow = platform.hidewindow
-quotecommand = platform.quotecommand
 readpipe = platform.readpipe
 setbinary = platform.setbinary
 setsignalhandler = platform.setsignalhandler
@@ -138,7 +137,7 @@ def popen(cmd, mode=b'rb', bufsize=-1):
 
 def _popenreader(cmd, bufsize):
 p = subprocess.Popen(
-tonativestr(quotecommand(cmd)),
+tonativestr(cmd),
 shell=True,
 bufsize=bufsize,
 close_fds=closefds,
@@ -149,7 +148,7 @@ def _popenreader(cmd, bufsize):
 
 def _popenwriter(cmd, bufsize):
 p = subprocess.Popen(
-tonativestr(quotecommand(cmd)),
+tonativestr(cmd),
 shell=True,
 bufsize=bufsize,
 close_fds=closefds,
@@ -395,7 +394,6 @@ def system(cmd, environ=None, cwd=None, 
 stdout.flush()
 except Exception:
 pass
-cmd = quotecommand(cmd)
 env = shellenviron(environ)
 if out is None or isstdout(out):
 rc = subprocess.call(

D8592: filemerge: add __bytes__ for absentfilectx

[durin42 (Augie Fackler)]

durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  This will at _least_ aid some upcoming debugging.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8592

AFFECTED FILES
  mercurial/filemerge.py

CHANGE DETAILS

diff --git a/mercurial/filemerge.py b/mercurial/filemerge.py
--- a/mercurial/filemerge.py
+++ b/mercurial/filemerge.py
@@ -98,6 +98,9 @@
 self._ctx = ctx
 self._f = f
 
+def __bytes__(self):
+return b'absent file %s@%s' % (self._f, self._ctx)
+
 def path(self):
 return self._f
 



To: durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D8591: mergestate: move staticmethod _filectxorabsent to module level

[durin42 (Augie Fackler)]

durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  I suspect this was a static method just because it made merge.py feel
  less messy, but now we have a mergestate package so we can do better.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8591

AFFECTED FILES
  mercurial/mergestate.py

CHANGE DETAILS

diff --git a/mercurial/mergestate.py b/mercurial/mergestate.py
--- a/mercurial/mergestate.py
+++ b/mercurial/mergestate.py
@@ -30,6 +30,12 @@
 bits = bits[:-2] + bits[-1:]
 return b'\0'.join(bits)
 
+def _filectxorabsent(hexnode, ctx, f):
+if hexnode == nullhex:
+return filemerge.absentfilectx(ctx, f)
+else:
+return ctx[f]
+
 
 # Merge state record types. See ``mergestate`` docs for more.
 RECORD_LOCAL = b'L'
@@ -600,8 +606,8 @@
 actx = self._repo[anccommitnode]
 else:
 actx = None
-fcd = self._filectxorabsent(localkey, wctx, dfile)
-fco = self._filectxorabsent(onode, octx, ofile)
+fcd = _filectxorabsent(localkey, wctx, dfile)
+fco = _filectxorabsent(onode, octx, ofile)
 # TODO: move this to filectxorabsent
 fca = self._repo.filectx(afile, fileid=anode, changectx=actx)
 # "premerge" x flags
@@ -679,12 +685,6 @@
 
 return complete, r
 
-def _filectxorabsent(self, hexnode, ctx, f):
-if hexnode == nullhex:
-return filemerge.absentfilectx(ctx, f)
-else:
-return ctx[f]
-
 def preresolve(self, dfile, wctx):
 """run premerge process for dfile
 



To: durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: planned work: minimal/partial Rust executable utility

[Gregory Szorc]

On Thu, May 28, 2020 at 12:40 PM Gregory Szorc 
wrote:

> On Thu, May 28, 2020 at 11:22 AM Augie Fackler  wrote:
>
>>
>>
>> > On May 28, 2020, at 10:10, Pierre-Yves David <
>> pierre-yves.da...@ens-lyon.org> wrote:
>> >
>> > We plan to start sending patches to build a minimal Rust executable
>> capable of fulfilling "some" operations to "some" extend. The idea is to
>> start small by building a tiny tool that:
>> >
>> > * focuses on usage inside script/prompt (where having a different
>> executable for some special action is fine),
>> > * explicitly only support a tiny subset of commands/flags,
>> > * help getting more building blocks in the `hg-core` crate,
>> > * respect the `hg` command line for everything it supports (to make it
>> a good base for something bigger).
>> > * is not called `hg` since it is not fully compatible with hg, yet
>> (maybe rhg ? or fhg ?)
>> > * last, but not least, help our new developer Antoine Cezar to get
>> familiar with the Mercurial internals and Rust code.
>> >
>> > In practice, here are the current plans for the first batch:
>> >
>> > 0) ignore configs (and extensions) for now,
>> > 1) crash (with a specific return code) if anything unknown is seen,
>> > 2) implement the following basic operations (in this order):
>> >* hg root [it gets us  a basic executable]
>> >* hg files [it gets us requirement checking and dirstate reading]
>> >* hg files --rev REV [it gets us basic read-only revlog support]
>> >* hg cat --rev REV [it gets us full revlog support (eg: fn cache and
>> co)]
>> >
>> > Once this is done, we probably make further plans (eg: config parsing,
>> basic revspec support, more commands,… who knows)
>> >
>> >
>> > What do you think?
>>
>> I think this makes a lot of sense. I can see it used in two ways:
>>
>> 1) We've often talked about a `hg buildshellprompthelper` command (name
>> is bad, please figure out a better one) that could emit a shell function to
>> efficiently and supportedly emit things people want in their prompt, and
>> then depending on what was requested we could use a native-code helper
>> binary instead of the full `hg`)
>>
>> 2) The "PyOxidizer delegating binary" thing that Martin mentioned.
>>
>> I worry a little bit around the margins of novel storage formats etc and
>> how we support those, but erroring out for now is probably adequate.
>>
>
> My assumption is the end state of any work in this area will be a native
> [Rust] binary that:
>
> a) Is capable of servicing an `hg` command without starting a Python
> interpreter
> b) Is capable of acting as a command server and client
> c) Starts a Python interpreter and dispatches to Python code when pure
> Rust code paths don't exist or are unwanted
> d) Eventually becomes the `hg` in some (all?) distributions of Mercurial
>
> I question whether it is worth building out one-off binaries if we assume
> this will be the end state.
>
> I think we should:
>
> 1. Use `pyoxidizer init-rust-project` to create a skeleton for a Rust
> executable project. Say in `rust/hgcli`
> 2. Hook up a `pyoxidizer.bzl` so it can run the Python Mercurial that we
> have today
> 3. Teach `run-tests.py`, `Makefile`, etc to build and use the new
> executable in a turnkey manner
> 4. Start hacking up `main()` to inject Rust code before the Python
> interpreter is started (via environment variables, minimal argument
> parsing, or whatever)
>
> Alternatively, we can inject PyOxidizer later, after we have a stub
> executable. But I suspect it will be drastically easier to do from the
> beginning, as that approach forces you to think about the interactions
> between Rust and Python sooner rather than later. Plus, the sooner this
> happens, the sooner it benefits end-users. Having chg baked into the
> executable so it is easier to use will be a huge win for users. If we were
> talking about a science experiment, I'd be inclined to start simple now.
> But Mercurial will be around for years, so why accrue technical debt
> against something that is part of the project's long-term vision.
>
> PyOxidizer should hopefully be stable enough that its presence doesn't
> hinder progress that much. Although I may need to land some features in
> PyOxidizer to help with e.g. reducing build times and not making iterative
> development as painful.
>
> Also, Eden's public source code has GPL'd Rust sources for things like
> configuration file and argument parsing. See e.g.
> https://phab.mercurial-scm.org/D7575. Their implementations largely
> conform with Mercurial's and we can probably get a Rust binary doing
> everything up to command dispatch in pure Rust with only a few days of
> effort.
>

Oh, note that we don't need to go full PyOxidizer: we could just use the
`pyembed` crate (part of PyOxidizer project) to manage an embedded Python
interpreter. (PyOxidizer provides the convenient "build system" that is
needed to manage the `pyembed` crate.) I think one of the most important
things in this project is to be thinking about 

Re: planned work: minimal/partial Rust executable utility

[Gregory Szorc]

On Thu, May 28, 2020 at 11:22 AM Augie Fackler  wrote:

>
>
> > On May 28, 2020, at 10:10, Pierre-Yves David <
> pierre-yves.da...@ens-lyon.org> wrote:
> >
> > We plan to start sending patches to build a minimal Rust executable
> capable of fulfilling "some" operations to "some" extend. The idea is to
> start small by building a tiny tool that:
> >
> > * focuses on usage inside script/prompt (where having a different
> executable for some special action is fine),
> > * explicitly only support a tiny subset of commands/flags,
> > * help getting more building blocks in the `hg-core` crate,
> > * respect the `hg` command line for everything it supports (to make it a
> good base for something bigger).
> > * is not called `hg` since it is not fully compatible with hg, yet
> (maybe rhg ? or fhg ?)
> > * last, but not least, help our new developer Antoine Cezar to get
> familiar with the Mercurial internals and Rust code.
> >
> > In practice, here are the current plans for the first batch:
> >
> > 0) ignore configs (and extensions) for now,
> > 1) crash (with a specific return code) if anything unknown is seen,
> > 2) implement the following basic operations (in this order):
> >* hg root [it gets us  a basic executable]
> >* hg files [it gets us requirement checking and dirstate reading]
> >* hg files --rev REV [it gets us basic read-only revlog support]
> >* hg cat --rev REV [it gets us full revlog support (eg: fn cache and
> co)]
> >
> > Once this is done, we probably make further plans (eg: config parsing,
> basic revspec support, more commands,… who knows)
> >
> >
> > What do you think?
>
> I think this makes a lot of sense. I can see it used in two ways:
>
> 1) We've often talked about a `hg buildshellprompthelper` command (name is
> bad, please figure out a better one) that could emit a shell function to
> efficiently and supportedly emit things people want in their prompt, and
> then depending on what was requested we could use a native-code helper
> binary instead of the full `hg`)
>
> 2) The "PyOxidizer delegating binary" thing that Martin mentioned.
>
> I worry a little bit around the margins of novel storage formats etc and
> how we support those, but erroring out for now is probably adequate.
>

My assumption is the end state of any work in this area will be a native
[Rust] binary that:

a) Is capable of servicing an `hg` command without starting a Python
interpreter
b) Is capable of acting as a command server and client
c) Starts a Python interpreter and dispatches to Python code when pure Rust
code paths don't exist or are unwanted
d) Eventually becomes the `hg` in some (all?) distributions of Mercurial

I question whether it is worth building out one-off binaries if we assume
this will be the end state.

I think we should:

1. Use `pyoxidizer init-rust-project` to create a skeleton for a Rust
executable project. Say in `rust/hgcli`
2. Hook up a `pyoxidizer.bzl` so it can run the Python Mercurial that we
have today
3. Teach `run-tests.py`, `Makefile`, etc to build and use the new
executable in a turnkey manner
4. Start hacking up `main()` to inject Rust code before the Python
interpreter is started (via environment variables, minimal argument
parsing, or whatever)

Alternatively, we can inject PyOxidizer later, after we have a stub
executable. But I suspect it will be drastically easier to do from the
beginning, as that approach forces you to think about the interactions
between Rust and Python sooner rather than later. Plus, the sooner this
happens, the sooner it benefits end-users. Having chg baked into the
executable so it is easier to use will be a huge win for users. If we were
talking about a science experiment, I'd be inclined to start simple now.
But Mercurial will be around for years, so why accrue technical debt
against something that is part of the project's long-term vision.

PyOxidizer should hopefully be stable enough that its presence doesn't
hinder progress that much. Although I may need to land some features in
PyOxidizer to help with e.g. reducing build times and not making iterative
development as painful.

Also, Eden's public source code has GPL'd Rust sources for things like
configuration file and argument parsing. See e.g.
https://phab.mercurial-scm.org/D7575. Their implementations largely conform
with Mercurial's and we can probably get a Rust binary doing everything up
to command dispatch in pure Rust with only a few days of effort.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: planned work: minimal/partial Rust executable utility

[Augie Fackler]

> On May 28, 2020, at 10:10, Pierre-Yves David  
> wrote:
> 
> We plan to start sending patches to build a minimal Rust executable capable 
> of fulfilling "some" operations to "some" extend. The idea is to start small 
> by building a tiny tool that:
> 
> * focuses on usage inside script/prompt (where having a different executable 
> for some special action is fine),
> * explicitly only support a tiny subset of commands/flags,
> * help getting more building blocks in the `hg-core` crate,
> * respect the `hg` command line for everything it supports (to make it a good 
> base for something bigger).
> * is not called `hg` since it is not fully compatible with hg, yet (maybe rhg 
> ? or fhg ?)
> * last, but not least, help our new developer Antoine Cezar to get familiar 
> with the Mercurial internals and Rust code.
> 
> In practice, here are the current plans for the first batch:
> 
> 0) ignore configs (and extensions) for now,
> 1) crash (with a specific return code) if anything unknown is seen,
> 2) implement the following basic operations (in this order):
>* hg root [it gets us  a basic executable]
>* hg files [it gets us requirement checking and dirstate reading]
>* hg files --rev REV [it gets us basic read-only revlog support]
>* hg cat --rev REV [it gets us full revlog support (eg: fn cache and co)]
> 
> Once this is done, we probably make further plans (eg: config parsing, basic 
> revspec support, more commands,… who knows)
> 
> 
> What do you think?

I think this makes a lot of sense. I can see it used in two ways:

1) We've often talked about a `hg buildshellprompthelper` command (name is bad, 
please figure out a better one) that could emit a shell function to efficiently 
and supportedly emit things people want in their prompt, and then depending on 
what was requested we could use a native-code helper binary instead of the full 
`hg`)

2) The "PyOxidizer delegating binary" thing that Martin mentioned.

I worry a little bit around the margins of novel storage formats etc and how we 
support those, but erroring out for now is probably adequate.

> 
> -- 
> Pierre-Yves David
> ___
> 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: planned work: minimal/partial Rust executable utility

[Pierre-Yves David]

On 5/28/20 6:03 PM, Martin von Zweigbergk wrote:
That sounds like what Greg has advocated for some time, and also what FB 
has done internally.


I think Greg's plan was to incrementally add more code to what's 
currently a very thin wrapper created by PyOxidizer. Then there would be 
no need for a separate binary. I think that sounds like a good idea. 
Would that work for you?


The current plan is to build something even simpler without a PyOxidizer 
or delegation (we don't have config parsing nor extension compatibility 
so we cannot achieve full compatibility for now). What you describe is 
definitly in the area of "something we could build of a the simplistic 
base).



On Thu, May 28, 2020 at 7:17 AM Pierre-Yves David 
mailto:pierre-yves.da...@ens-lyon.org>> 
wrote:


We plan to start sending patches to build a minimal Rust executable
capable of fulfilling "some" operations to "some" extend. The idea
is to
start small by building a tiny tool that:

* focuses on usage inside script/prompt (where having a different
executable for some special action is fine),
* explicitly only support a tiny subset of commands/flags,
* help getting more building blocks in the `hg-core` crate,
* respect the `hg` command line for everything it supports (to make
it a
good base for something bigger).
* is not called `hg` since it is not fully compatible with hg, yet
(maybe rhg ? or fhg ?)
* last, but not least, help our new developer Antoine Cezar to get
familiar with the Mercurial internals and Rust code.

In practice, here are the current plans for the first batch:

0) ignore configs (and extensions) for now,
1) crash (with a specific return code) if anything unknown is seen,
2) implement the following basic operations (in this order):
      * hg root [it gets us  a basic executable]
      * hg files [it gets us requirement checking and dirstate reading]
      * hg files --rev REV [it gets us basic read-only revlog support]
      * hg cat --rev REV [it gets us full revlog support (eg: fn cache
and co)]

Once this is done, we probably make further plans (eg: config parsing,
basic revspec support, more commands,… who knows)


What do you think?

-- 
Pierre-Yves David

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org

https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel



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

Re: planned work: minimal/partial Rust executable utility

[Martin von Zweigbergk via Mercurial-devel]

That sounds like what Greg has advocated for some time, and also what FB
has done internally.

I think Greg's plan was to incrementally add more code to what's currently
a very thin wrapper created by PyOxidizer. Then there would be no need for
a separate binary. I think that sounds like a good idea. Would that work
for you?

On Thu, May 28, 2020 at 7:17 AM Pierre-Yves David <
pierre-yves.da...@ens-lyon.org> wrote:

> We plan to start sending patches to build a minimal Rust executable
> capable of fulfilling "some" operations to "some" extend. The idea is to
> start small by building a tiny tool that:
>
> * focuses on usage inside script/prompt (where having a different
> executable for some special action is fine),
> * explicitly only support a tiny subset of commands/flags,
> * help getting more building blocks in the `hg-core` crate,
> * respect the `hg` command line for everything it supports (to make it a
> good base for something bigger).
> * is not called `hg` since it is not fully compatible with hg, yet
> (maybe rhg ? or fhg ?)
> * last, but not least, help our new developer Antoine Cezar to get
> familiar with the Mercurial internals and Rust code.
>
> In practice, here are the current plans for the first batch:
>
> 0) ignore configs (and extensions) for now,
> 1) crash (with a specific return code) if anything unknown is seen,
> 2) implement the following basic operations (in this order):
>  * hg root [it gets us  a basic executable]
>  * hg files [it gets us requirement checking and dirstate reading]
>  * hg files --rev REV [it gets us basic read-only revlog support]
>  * hg cat --rev REV [it gets us full revlog support (eg: fn cache
> and co)]
>
> Once this is done, we probably make further plans (eg: config parsing,
> basic revspec support, more commands,… who knows)
>
>
> What do you think?
>
> --
> Pierre-Yves David
> ___
> 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

planned work: minimal/partial Rust executable utility

[Pierre-Yves David]

We plan to start sending patches to build a minimal Rust executable 
capable of fulfilling "some" operations to "some" extend. The idea is to 
start small by building a tiny tool that:


* focuses on usage inside script/prompt (where having a different 
executable for some special action is fine),

* explicitly only support a tiny subset of commands/flags,
* help getting more building blocks in the `hg-core` crate,
* respect the `hg` command line for everything it supports (to make it a 
good base for something bigger).
* is not called `hg` since it is not fully compatible with hg, yet 
(maybe rhg ? or fhg ?)
* last, but not least, help our new developer Antoine Cezar to get 
familiar with the Mercurial internals and Rust code.


In practice, here are the current plans for the first batch:

0) ignore configs (and extensions) for now,
1) crash (with a specific return code) if anything unknown is seen,
2) implement the following basic operations (in this order):
* hg root [it gets us  a basic executable]
* hg files [it gets us requirement checking and dirstate reading]
* hg files --rev REV [it gets us basic read-only revlog support]
* hg cat --rev REV [it gets us full revlog support (eg: fn cache 
and co)]


Once this is done, we probably make further plans (eg: config parsing, 
basic revspec support, more commands,… who knows)



What do you think?

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

D8590: githelp: add some minimal help for pickaxe functionality

[durin42 (Augie Fackler)]

durin42 created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REVISION SUMMARY
  Due to a conversation in work chat, I realized this is actually pretty
  well-hidden in Mercurial.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8590

AFFECTED FILES
  hgext/githelp.py
  tests/test-githelp.t

CHANGE DETAILS

diff --git a/tests/test-githelp.t b/tests/test-githelp.t
--- a/tests/test-githelp.t
+++ b/tests/test-githelp.t
@@ -318,3 +318,10 @@
   hg journal --all
   
   note: in hg commits can be deleted from repo but we always have backups
+
+  $ hg githelp -- git log -Gnarf
+  hg grep --diff narf
+  $ hg githelp -- git log -S narf
+  hg grep --diff narf
+  $ hg githelp -- git log --pickaxe-regex narf
+  hg grep --diff narf
diff --git a/hgext/githelp.py b/hgext/githelp.py
--- a/hgext/githelp.py
+++ b/hgext/githelp.py
@@ -628,8 +628,17 @@
 (b'', b'stat', None, b''),
 (b'', b'graph', None, b''),
 (b'p', b'patch', None, b''),
+(b'G', b'grep-diff', b'', b''),
+(b'S', b'pickaxe-regex', b'', b''),
 ]
 args, opts = parseoptions(ui, cmdoptions, args)
+grep_pat = opts.get(b'grep_diff') or opts.get(b'pickaxe_regex')
+if grep_pat:
+cmd = Command(b'grep')
+cmd[b'--diff'] = grep_pat
+ui.status(b'%s\n' % bytes(cmd))
+return
+
 ui.status(
 _(
 b'note: -v prints the entire commit message like Git does. To '



To: durin42, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

mercurial@44860: 5 new changesets

[Mercurial Commits]

5 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/b7808443ed6a
changeset:   44856:b7808443ed6a
user:Augie Fackler 
date:Mon May 18 14:59:59 2020 -0400
summary: mergestate: split out merge state handling code from main merge 
module

https://www.mercurial-scm.org/repo/hg/rev/e607099d8b93
changeset:   44857:e607099d8b93
user:Augie Fackler 
date:Mon May 18 16:00:26 2020 -0400
summary: context: implement mergestate() method

https://www.mercurial-scm.org/repo/hg/rev/5d8ae9248a70
changeset:   44858:5d8ae9248a70
user:Valentin Gatien-Baron 
date:Tue May 26 07:03:11 2020 -0400
summary: scmutil: speed up relativization of paths when it's a no-op

https://www.mercurial-scm.org/repo/hg/rev/15e26cc0e2c6
changeset:   44859:15e26cc0e2c6
user:Valentin Gatien-Baron 
date:Mon May 25 20:02:15 2020 -0400
summary: sshpeer: add test showing that -q silences remote errors

https://www.mercurial-scm.org/repo/hg/rev/5d77f571a563
changeset:   44860:5d77f571a563
bookmark:@
tag: tip
user:Valentin Gatien-Baron 
date:Mon May 25 22:47:12 2020 -0400
summary: sshpeer: make client print (likely) server errors on stderr (BC)

-- 
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

mercurial@44855: 3 new changesets

[Mercurial Commits]

3 new changesets in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/ba5688e3b3bd
changeset:   44853:ba5688e3b3bd
user:Augie Fackler 
date:Mon May 18 13:18:05 2020 -0400
summary: relnotes: add API change note per request in D8502

https://www.mercurial-scm.org/repo/hg/rev/572f98a6f6af
changeset:   44854:572f98a6f6af
user:Augie Fackler 
date:Mon May 18 12:41:16 2020 -0400
summary: tests: add coverage for repo.changelog.findmissing() in 
test-git-interop.t

https://www.mercurial-scm.org/repo/hg/rev/1d2d353e5c4a
changeset:   44855:1d2d353e5c4a
bookmark:@
tag: tip
user:Augie Fackler 
date:Mon May 18 12:45:45 2020 -0400
summary: tests: add coverage for repo.changelog.children() in the git 
extension

-- 
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