- Oct 20, 2015
-
-
Pierre-Yves David authored
This should be set for all bundle2 application, we enforce that at a low level. This is for courtesy with hooks.
-
Pierre-Yves David authored
This is one such place.
-
Pierre-Yves David authored
There is a case where the intent is clear and the transaction is not optional. We want to be able to alter that transaction in a wide and easy way. We cannot get a unified '.apply(repo)' method for bundle1 and bundle2 yet because the api are still a bit too far apart. But this is a good step forward to get the rc out.
-
- Oct 15, 2015
-
-
Siddharth Agarwal authored
This can happen when either 'hg resolve --all' is called or a driver-resolved file is explicitly requested. This is done as part of 'hg resolve --all' so that users still have a chance to test their changes before committing them. The exact semantics here are still to be decided. This does not impact any non-experimental features. Thanks to Pierre-Yves David for some advice about this behavior in particular, and merge drivers in general.
-
Siddharth Agarwal authored
We need to be careful about allowing --mark and --unmark to keep working -- we don't want the user to be stuck in a weird state. The exact behavior here is still to be decided, though.
-
Siddharth Agarwal authored
This will be a chance for the merge driver to finish resolving or generating any driver-resolved files. As before, having a separate error state from 'unresolved' is too big a refactoring for now, so we hack around it by setting unresolved to a positive value when necessary.
-
Siddharth Agarwal authored
We also need to update our internal state to whatever state driverpreprocess leaves it in. Adding an error state separate from the unresolved count is too big a refactoring for now, so we hack around it by setting it to a positive value to indicate an error state.
-
Siddharth Agarwal authored
The exact semantics for what should happen (particularly with respect to error handling) are still a bit hard to pin down, so I think it's better to experiment with it as an extension for now. For now this stub will act as a convenient point for extensions to hook on.
-
Siddharth Agarwal authored
Users will often be in the habit of running 'hg resolve --mark --all' after resolving merge conflicts in source files. We need to make sure this doesn't cause driver-resolved files to be marked. 'hg resolve --all' will resolve driver-resolved files, though. The weird conditional structure is to accommodate an upcoming patch.
-
Siddharth Agarwal authored
This allows for status and other results on the wctx to be cached between iterations.
-
- Oct 19, 2015
-
-
James Mills authored
-
- Oct 16, 2015
-
-
Mads Kiilerich authored
-
- Oct 14, 2015
- Oct 15, 2015
-
-
timeless authored
-
- Oct 16, 2015
- Oct 18, 2015
-
-
Yuya Nishihara authored
Spotted by CC=clang CFLAGS='-Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wshorten-64-to-32': mercurial/parsers.c:1580:24: warning: comparison of integers of different signs: 'Py_ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare] if (self->raw_length > INT_MAX / sizeof(nodetree)) {
-
- Oct 17, 2015
-
-
Yuya Nishihara authored
These fields are defined as int. This eliminates the following warning spotted by CC=clang CFLAGS='-Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wshorten-64-to-32': mercurial/parsers.c:625:29: warning: comparison of integers of different signs: 'uint32_t' (aka 'unsigned int') and 'int' [-Wsign-compare] if (state == 'n' && mtime == now) {
-
- Oct 16, 2015
-
-
Pierre-Yves David authored
This bundle command is meant to generate a bundle1, we enforce that to avoid test's misbehavior when moving to general-delta by default.
-
Pierre-Yves David authored
This bundle command is meant to generate a bundle1, we enforce that to avoid test's misbehavior when moving to general-delta by default.
-
- Oct 17, 2015
-
-
Ryan McElroy authored
Previously, files with spaces would break editmerge.
-
- Oct 15, 2015
-
-
Siddharth Agarwal authored
'hg resolve --all' will be the canonical way to run the 'conclude' step of the merge driver.
-
Siddharth Agarwal authored
This allows mergestate.mdstate() to return 's' if there's nothing to be done on the merge driver end.
-
Siddharth Agarwal authored
Otherwise 'hg update --clean', 'hg rebase --abort' etc wouldn't work.
-
Siddharth Agarwal authored
This case also requires 'hg resolve --all' to be run before continuing.
-
Siddharth Agarwal authored
This will be useful to check what the status of the merge driver is.
-
Siddharth Agarwal authored
It's surprising there was no API at all for this until now. In any case this will be needed from custom merge drivers.
-
Siddharth Agarwal authored
There's no user-visible way to mark files as driver-resolved, so this status won't be visible.
-
- Oct 17, 2015
-
-
Durham Goode authored
Back in June we made histedit use obsolete markers to cleanup when possible. This was rolled back as part of 54f9561088c7 (which should have only rolled back the --abort stuff, but rolled back everything). This caused a nasty bug when used in conjuction with the inhibit+directaccess extensions where histedit would leave old nodes around even after they had been squashed away. The root of the problem is that we first clean up old nodes, and then we clean up temp nodes. In the first pass, when we obsoleted old nodes, some would become unobsolete because they had temp nodes on top of them, thus making them stick around even after the histedit finished. The fix is to A) move the temp node cleanup to be before the old node cleanup (since they are topological on top of the old nodes), and B) use obsolete markers instead of stripping.
-
Gregory Szorc authored
There are a lot of considerations server operators need to know before deploying clone bundles. They should be documented. So I rewrote the extension docs to contain this information.
-
Gregory Szorc authored
Now that we have support for detecting compatible stream clone bundles in bundle specifications, we can safely add support for applying stream clone bundles to the clone bundles feature.
-
Gregory Szorc authored
Stream clone bundles can only be consumed if the consumer supports the exact format requirements that were present on the producer. This patch adds support for encoding and verifying the format requirements on the bundle specification string for a stream clone bundle are supported by the local repository. If they aren't, we raise an UnsupportedBundleSpecification, just like we do when an unknown compression or bundle type is encountered. The impetus for this patch is so the clone bundles manifest can advertise stream clone bundles and so clients can filter out stream clones with unsupported format requirements. e.g. a stream clone produced with the not-yet-invented "revlogv2" format will be ignored by clients that only support "revlogv1."
-
- Oct 15, 2015
-
-
Gregory Szorc authored
Sometimes a basic type string is not sufficient for representing the contents of a bundle. Take bundle2 for example: future bundle2 files may contain parts that today's bundle2 parser can't read. Another example is stream clone data. These require clients to support specific repository formats or they won't be able to read the written files. In both scenarios, we need to describe additional metadata beyond the outer container type. Furthermore, this metadata behaves more like an unordered set, so an order-based declaration format (such as static strings) is not sufficient. We introduce support for "parameters" into the bundle specification string. These are essentially key-value pairs that can be used to encode additional metadata about the bundle. Semicolons are used as the delimiter partially to increase similarity to MIME parameter values (see RFC 2231) and because they are relatively safe from the command line (although values will need quotes to avoid interpretation as multiple shell commands). Alternatives considered were spaces (a bit annoying to encode) and '&' (similar to URL query strings) (which will do bad things in a shell if unquoted). The parsing function now returns a dict of parsed parameters and consumers have been updated accordingly.
-
Gregory Szorc authored
For the same reasons that we don't produce stream clone bundles with `hg bundle`, we don't support consuming stream clone bundles with `hg unbundle`. We introduce a complementary debug command for applying stream clone bundles. This command is mostly to facilitate testing. Although it may be used to manually apply stream clone bundles until a more formal mechanism is (possibly) adopted.
-
- Oct 17, 2015
-
-
Gregory Szorc authored
Now that we have support for recognizing the streaming clone bundle type, add a debug command for creating them. I decided to create a new debug command instead of adding support to `hg bundle` because stream clone bundles are not exactly used the same way as normal bundle files and I don't want to commit to supporting them through the official `hg bundle` command forever. A debug command, however, can be changed without as much concern for backwards compatibility. As part of this, `hg bundle` will explicitly reject requests to produce stream bundles. This command will be required by server operators using stream clone bundles with the clone bundles feature.
-
- Oct 15, 2015
-
-
Gregory Szorc authored
Now that we have a mechanism to produce and consume streaming clone bundles, we need to teach the human-facing bundle specification parser and the internal bundle file header reading code to be aware of this new format. This patch does so. For the human-facing bundle specification, we choose the name "packed" to describe "streaming clone bundles" because the bundle is essentially a "pack" of raw revlog files that are "packed" together. There should probably be a bikeshed over the name, especially since it is human facing.
-
- Oct 17, 2015
-
-
Gregory Szorc authored
Up to this point, stream clones only existed as a dynamically generated data format produced and consumed during streaming clones. In order to support this efficient cloning format with the clone bundles feature, we need a more formal, on disk representation of the streaming clone data. This patch introduces a new "bundle" type for streaming clones. Unlike existing bundles, it does not contain changegroup data. It does, however, share the same concepts like the 4 byte header which identifies the type of data that follows and the 2 byte abbreviation for compression types (of which only "UN" is currently supported). The new bundle format is essentially the existing stream clone version 1 data format with some headers at the beginning. Content negotiation at stream clone request time checked for repository format/requirements compatibility before initiating a stream clone. We can't do active content negotiation when using clone bundles. So, we put this set of requirements inside the payload so consumers have a built-in mechanism for checking compatibility before reading and applying lots of data. Of course, we will also advertise this requirements set in clone bundles. But that's for another patch. We currently don't have a mechanism to produce and consume this new bundle format. This will be implemented in upcoming patches. It's worth noting that if a legacy client attempts to `hg unbundle` a stream clone bundle (with the "HGS1" header), it will abort with: "unknown bundle version S1," which seems appropriate.
-
Matt Mackall authored
-
- Oct 15, 2015
-
-
Katsunori FUJIWARA authored
After this reordering, absence of '.hg/journal' just before starting new transaction means also absence of '.hg/journal.backupfiles'. In this case, all temporary files for preceding transaction should be completely unlinked, and HG_PENDING doesn't cause unintentional reading stalled temporary files in. Otherwise, 'repo.transaction()' raises exception with "run 'hg recover' to clean up transaction" hint.
-