Currently, we export urlparse via util.urlparse then
call util.urlparse.urlparse() and util.urlparse.urlunparse()
in a few places. This is the only url* module exported from
pycompat, making it a one-off. So let's transition to urlreq
to match everything else.
Yes, we double import "urlparse" now on Python 2. This will
be cleaned up in a subsequent patch.
Also, the Python 3 functions trade in str/unicode not bytes.
So we'll likely need to write a custom implementation that
speaks bytes. But moving everyone to an abstracted API
is a good first step.
It is duplicated by urlreq.unquote and is unused. Kill it.
We retain the imports because it is re-exported via util.urlparse,
which is used elsewhere.
Since we no longer access attributes of urlparse at module load time,
this change /should/ result in that module reverting to a lazy module.
pycompat.urlreq.unquote and pycompat.urlunquote effectively alias the
same thing. pycompat.urlunquote is only used once in the code base.
So let's switch to urlreq.unquote.
"Effectively" in the above paragraph is because pycompat.urlreq.unquote
aliases urllib.unquote and pycompat.urlunquote aliases urlparse.unquote
on Python 2. You might think one of urllib.unquote and urlparse.unquote
is an alias to the other, but you would be incorrect. In fact, these
functions are copies of each other. There is even a comment in the
CPython source code saying to keep them in sync. You can't make this
up.
Previously, urlreq.unquote aliased to urllib.parse.unquote,
which returned a str/unicode. We like bytes, so switch urlreq.unquote
to dispatch to urllib.parse.unquote_to_bytes.
This required a minor helper function to register an alias under a
different name from which it points. If this turns into a common
pattern, we could likely teach _registeralias to accept tuple
values defining the mapping. Until then, I didn't feel like
adding complexity to _registeralias.
This patch exports the "getfstype" method. So we can use it to enable
hardlinks for known safe filesystems.
The patch was tested manually via debugshell on a Linux system.
"mercurial.osutil.getfstype" works as expected. It's hard to mount
filesystem on user-space easily. I will add a test for real hardlink support
to indirectly test this patch, after turning on real hardlinks support for
certain whitelisted filesystems.
Currently it only has Linux filesystems, according to my Linux manpage,
built at 2016-03-15.
The code uses "if" instead of "switch" because there could be some
duplicated values.
The next patch will use "statfs", which requires different header files on
different platforms.
Linux:
sys/vfs.h or sys/statfs.h
FreeBSD or OSX:
sys/param.h and sys/mount.h
Therefore test them so we can include the correct ones.
In some mercurial workflows, the default destination for rebase does not
always work well and can lead to confusing behavior. With this flag enabled,
every rebase command will require passing an explicit destination, eliminating
this confusion.
In some mercurial workflows, the default destination for update does not
always work well and can lead to confusing behavior. With this flag enabled,
every update command will require passing an explicit destination, eliminating
this confusion.
We could create a patch of such name, but it wouldn't be processed properly
by mq as parseseries() strips leading/trailing whitespace.
The test of default message (added by 063a2c623014) is no longer be useful
so removed.
This issue was reported as:
https://bitbucket.org/tortoisehg/thg/issues/4693/
Since we are introducing obs-based shelve, we are no longer
stripping temporary nodes, we are obsoleting them. Therefore
it looks like stipnodes would be a misleading name, while
prune has a connotaion of "strip but with obsolescense", so
nodestoprune seems like a good rename.
Obsolescense-based shelve only needs metadata stored in .hg/shelved
and if feels that this metadata should be stored in a
simplekeyvaluefile format for potential extensibility purposes.
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).
Not included in this series, I have ~30 commits, doubling test-shelve.t
in size and testing almost every tested shelve usecase for obs-shelve.
Here's the series for the curious now: http://pastebin.com/tGJKx0vM
I would like to send it to the mailing list and get accepted as well,
but:
1. it's big, so should I send like 6 patches a time or so?
2. instead of having a commit per test case, it more like
a commit per some amount of copy-pasted code. I tried to keep
it meaningful and named commits somewhat properly, but it is
far from this list standards IMO. Any advice on how to get it
in without turning it into a 100 commits and spending many
days writing descriptions?
3. it makes test-shelve.t run for twice as long (and it is already
a slow test). Newest test-shelve.r runs for ~1 minute.
The purpose of the added class is to serve purposes like save files of shelve
or state files of shelve, rebase and histedit. Keys of these files can be
alphanumeric and start with letters, while values must not contain newlines.
In light of Mercurial's reluctancy to use Python's json module, this tries
to provide a reasonable alternative for a non-nested named data.
Comparing to current approach of storing state in plain text files, where
semantic meaning of lines of text is only determined by their oreder,
simple key-value file allows for reordering lines and thus helps handle
optional values.
Initial use-case I see for this is obs-shelve's shelve files. Later we
can possibly migrate state files to this approach.
The test is in a new file beause I did not figure out where to put it
within existing test suite. If you give me a better idea, I will gladly
follow it.
Thoughout hg code, we see a pattern of attempting to remove a file and then
catching and ignoring any errors due to a missing file in the calling code.
Let's unify this pattern in a single implementation in the vfs layer.
Throughout mercurial cdoe, there is a common pattern of attempting to remove
a file and ignoring ENOENT errors. Let's move this into a common function to
allow for cleaner code.
Previously, there were two slightly different versions of unlinkpath between
windows and posix, but these differences were eliminated in previous patches.
Now we can unify these two code paths inside of the util module.
We have a local reference to os.removedirs in module scope, but we still used
os.removedirs inside functions. This changes util to use the local reference,
which will pave the way for combining duplicated code in future patches.
We have a local reference to os.unlink in module scope, but we still used
os.unlink inside functions. This changes util to use the local reference,
which will pave the way for combining duplicated code in future patches.
At the beginning of March, I promised Yuya that I would follow up a comment I
made on a patch with improved documention for these vfs objects. Also hat tip
to Pierre-Yves for adding the documentation here in the first place.
Long autogenerated blocked tags tend to be because the command has an absolute
path; at Facebook, we've had a few where the tag is thousands of characters
long (in association with the mergedriver).
Change the default to use a suffix of a command as the default tag, limiting us
to 85 characters (for a 100 character tag). This is long enough to overflow a
standard terminal (thus be obviously autogenerated), but short enough to be
readable.
I considered making this I/O be done in terms of bytes, but that would
cause an observable regression for Windows users, as non-binary-mode
open does EOL conversion there. There are probably new encoding
dragons lurking here, so we may want to switch to using binary mode
and doing EOL conversion ourselves.
Previously, `hg bundle zstd` on a non-generaldelta repo would
attempt to use a v1 bundle. This would fail because zstd is not
supported on v1 bundles.
This patch changes the behavior to automatically use a v2 bundle
when the user explicitly requests a bundlespec that is a compression
engine not supported on v1. If the bundlespec is <engine>-v1, it is
still explicitly rejected because that request cannot be fulfilled.
Version 1 bundles only support a fixed set of compression engines.
Before this change, we would accept any compression engine for v1
bundles, even those that may not work on v1. This could lead to
an error.
We define a fixed set of compression engines known to work with v1
bundles and we add checking to ensure a newer engine (like zstd)
won't work with v1 bundles.
I also took the liberty of adding test coverage for unknown compression
names because I noticed we didn't have coverage of it before.
Move "cleanupnode" (unsafe strip) into "safecleanupnode" so it's impossible
to call the unsafe function directly.
This helps reduce future programming errors.
The new method will decide between:
- cleanupnode, which calls the unsafe repair.strip
- create obsmarkers
Ideally, nobody calls "cleanupnode" directly except for "safecleanupnode".
