Upcoming patches will kill hghave (the script - not hghave.py) and
will move to a model where requirements checking is performed as
a function call.
Start diminishing the utility of hghave by moving some code to
hghave.py.
Before this patch, there is no way to add customized features to
`hghave` without changing `hghave` and `hghave.py` themselves.
This decreases reusability of `run-tests.py` framework for third party
tools, because they may want to examine custom features at runtime
(e.g. existence of some external tools).
To allow adding customized features at runtime, this patch makes
`hghave` import `hghaveaddon` module, only when `hghaveaddon.py` file
can be found in directories below:
- `TESTDIR` for invocation via `run-tests.py`
- `.` for invocation via command line
The path to the directory where `hghaveaddon.py` should be placed is
added to `sys.path` only while importing `hghaveaddon`, because:
- `.` may not be added to `PYTHONPATH`
- adding additional path to `sys.path` may change behavior of
subsequent `import` for other features
`hghave` is terminated with exit code '2' at failure of `import
hghaveaddon`, because exit code '2' terminates `run-tests.py`
immediately.
This is a one of preparations for issue4677.
This class contains a stat result, and possibly other file info to reliably
determine between two points in time whether a file has changed.
Uniquely identifying a file gives us that reliability because we either
atomic rename or append. So one of two will happen: the file 'id' will change,
or the size of the file will change.
posix implements it simply by calling os.stat() and checking if the result
has st_ino.
For now on Windows we always assume the path is uncacheable. This can be
improved on NTFS due to file IDs: http://msdn.microsoft.com/en-us/library/aa363788(v=vs.85).aspx
So we need to find out if a file path is on an NTFS drive, for that we have:
- GetVolumeInformation, which unfortunately only works with a root path (but is available on XP)
- GetVolumeInformationByHandleW, works on a full file path but requires Vista or higher
This happens more often than expected. Say you have an svn subrepository with
python code. Python would have generated unknown .pyc files. Now, you rebase
this setup on a revision where a directory containing python code does not
exist. Subversion is first asked to remove this directory when updating, but
will not because it contains untracked items. Then it will have to bring back
the directory after the merge but will fail because it now collides with an
untracked directory.
Using --force is not very elegant and only works with svn >= 1.5 but the only
alternative I can think of is to write our own purge command for subversion.
pyOpenSSL apparently doesn't work for Python 2.7 and isn't very actively
maintained.
The built-in ssl module seems like a long-term winner, so we now use that with
Python 2.6 and higher.
The https mode failed in super because BaseRequestHandler is an old-style
class.
This introduces the first test of https client/server functionality - and
"hghave ssl". The test is currently only run on Python 2.6.