Page MenuHomePhabricator

tests: add test extension implementing custom filelog storage

Authored by indygreg on Apr 2 2018, 11:53 PM.



In order to better support partial clones, we'll need alternate
repository storage mechanisms that aren't based on revlogs.

Today, the interface for repository storage isn't very well defined.
And there are various layering violations and assumptions made
throughout the code that storage is backed by revlogs.

In order to support alternate storage mechanisms, we'll need to
formally declare and adhere to interfaces for storage. This will
be a long, arduous process.

This commit creates an extension that implements non-revlog storage
for files. It defines a custom type that quacks like the existing
revlog/filelog API but isn't backed by a revlog. The backing storage
is - for simplicity reasons - a CBOR index and per-node files
representing fulltext data.

The localrepository class is modified so file(f) returns instances of
this class instead of filelog instances.

The purpose of this extension is to tease out what the actual filelog
interface is - based on running the test harness - so we can formalize
that interface and then implement a *real* alternate storage backend.

Using --extra-config-opt to run the test harness
with this extension enabled yields 83 failures out of 634 ran

The most common test failures are due to:

  • Issues with hg verify
  • LFS and largefiles (probably flags processing related)
  • Narrow.
  • Any test touching or inspecting individual filelog paths.
  • help and error output that is confused by the presence of an extension.
  • hg debug* commands doing low-level, revlog-y things.

An 88% pass rate is pretty good for an initial implementation if you
ask me!

There is a bit of duplicate code in the new extension. That's by
design: a point of this code is to tease out dependencies on revlog.
That being said, there is opportunity to consolidate code by moving
things out of the revlog API. For example, DAG traversal operations
don't necessarily need to be implemented at the storage level. (Although
for performance reasons they probably do.) Once we have a more
well-defined interface, we could probably define the default
implementations in terms of the base interface, pull those in via
class inheritance, and have implementations override with faster
versions if they so choose. (Or something like that.) But for now,
the duplicate code should be acceptable.

Diff Detail

rHG Mercurial
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Apr 2 2018, 11:53 PM
indygreg edited the summary of this revision. (Show Details)Apr 3 2018, 1:53 PM
indygreg updated this revision to Diff 7563.
durin42 requested changes to this revision.Apr 4 2018, 2:03 PM
durin42 added a subscriber: durin42.

One thing that I'm 99% sure is a bug. The "ew" comment is not actionable, it just feels bad.




should one of these be baserev?

This revision now requires changes to proceed.Apr 4 2018, 2:03 PM
indygreg added inline comments.Apr 4 2018, 2:15 PM


The point of these functions is to help validate the interface. There are surprisingly few failures in core due to this type checking.

Manifests and changelog, however, failure in several places. But our use of revisions and nodes in filelogs is surprisingly consistent.

indygreg updated this revision to Diff 7634.Apr 4 2018, 2:37 PM
durin42 added inline comments.Apr 4 2018, 2:57 PM

I just wish this could be done with a typechecker instead of these functions.

durin42 accepted this revision.Apr 4 2018, 2:57 PM
This revision is now accepted and ready to land.Apr 4 2018, 2:57 PM
This revision was automatically updated to reflect the committed changes.