- Oct 13, 2015
-
-
Katsunori FUJIWARA authored
'localrepository.rollback()' explicilty restores dirstate, only if at least one of current parents of the working directory is removed at rollbacking (a.k.a "parent-gone"). After DirstateTransactionPlan, 'dirstate.write()' will cause marking '.hg/dirstate' as a file to be restored at rollbacking. https://mercurial.selenic.com/wiki/DirstateTransactionPlan Then, 'transaction.rollback()' restores '.hg/dirstate' regardless of parents of the working directory at that time, and this causes unexpected dirstate changes if not "parent-gone" (e.g. "hg update" to another branch after "hg commit" or so, then "hg rollback"). To avoid such situation, this patch restores dirstate to one before rollbacking if not "parent-gone". before: b1. restore dirstate explicitly, if "parent-gone" after: a1. save dirstate before actual rollbacking via dirstateguard a2. restore dirstate via 'transaction.rollback()' a3. if "parent-gone" - discard backup (a1) - restore dirstate from 'undo.dirstate' a4. otherwise, restore dirstate from backup (a1) Even though restoring dirstate at (a3) after (a2) seems redundant, this patch keeps this existing code path, because: - it isn't ensured that 'dirstate.write()' was invoked at least once while transaction running If not, '.hg/dirstate' isn't restored at (a2). In addition to it, rude 3rd party extension invoking 'dirstate.write()' without 'repo' while transaction running (see subsequent patches for detail) may break consistency of a file backup-ed by transaction. - this patch mainly focuses on changes for DirstateTransactionPlan Restoring dirstate at (a3) itself should be cheaper enough than rollbacking itself. Redundancy will be removed in next step. Newly added test is almost meaningless at this point. It will be used to detect regression while implementing delayed dirstate write out.
-
Katsunori FUJIWARA authored
On recent OS, 'stat.st_mtime' has a double precision floating point value to represent nano seconds, but it is not wide enough for actual file timestamp: nowadays, only 52 - 32 = 20 bit width is available for decimal places in sec. Therefore, casting it to 'int' may cause unexpected result. See also changeset 13272104bb07 fixing issue4836 for detail. For example, changed file A may be treated as "clean" unexpectedly in steps below. "rounded now" is the value gotten by rounding via 'int(st.st_mtime)' or so. ---------------------+--------------------+------------------------ "now" | | timestamp of A (time_t) float rounded time_t| action | FS dirstate ------ ------- ------+--------------------+-------- --------------- N+.nnn N N | | --- --- | update file A | N | dirstate.normal(A) | N N+.999 N+1 N | | | dirstate.write() | N (*1) | : | | change file A | N | : | N+1.00 N+1 N+1 | | | "hg status" (*2) | N N ------ ------- ------+--------------------+-------- --------------- Timestamp N of A in dirstate isn't dropped at (*1), because "rounded now" is N+1 at that time, even if 'st_mtime' in 'time_t' is still N. Then, file A is unexpectedly treated as "clean" at (*2) in this case. For consistent handling of 'stat.st_mtime', this patch makes 'pack_dirstate()' take 'now' argument not in floating point but in integer. This patch makes 'PyArg_ParseTuple()' in 'pack_dirstate()' use format 'i' (= checking type mismatch or overflow), even though it is ensured that 'now' is in the range of 32bit signed integer by masking with '_rangemask' (= 0x7fffffff) on caller side. It should be cheaper enough than packing itself, and useful to detect that legacy code invokes 'pack_dirstate()' with 'now' in floating point value.
-
- Sep 29, 2015
-
-
Pierre-Yves David authored
After moving logic from 'merge.update' into 'destutil.destupdate', we are now moving logic from 'command.update' in 'destutil.destupdate'. This will make the function actually useful in predicting (and altering) the update behavior.
-
- Oct 05, 2015
-
-
Pierre-Yves David authored
We want this function to exactly predict the behavior for update. Moreover, we would like to remove all high level behavior logic out of the merge module so this is a step forward. Now that the 'destupdate' function both compute and validate the destination, we can directly use it at the command level, ensuring that the 'hg update' command never call 'merge.update' without a defined destination. This is a first (but significant) step toward having 'merge.update' always feed with a properly validated destination and free of high level logic.
-
- Oct 12, 2015
-
-
Mads Kiilerich authored
Before, when merging revisions with missing largefiles, the missing largefiles would be fetched as a part of the merge. If that failed (for example because the main repository temporarily was unavailable), the largefile would be left missing. However, the next commit would abort and (seemed to) fail when markcommitted tried to mark the standin file as normal and thus had to hash the largefile that didn't exist. (Actually, the commit would succeed but the largefile update that follows right after the commit transaction would abort - quite confusing.) To fix that, make sure that synclfdirstate only marks files as normal if they actually exist.
-
Pierre-Yves David authored
Advertising that the patch are available to be pulled requires that to be true. So we check revision availability on the remote before sending any email.
-
Mads Kiilerich authored
On windows, hgrc.d/*.rc would not be read if mercurial.ini was found. That was far from obvious from the documentation and different from the behavior on posix systems. As a consequence of this, TortoiseHg cacert configuration placed in hgrc.d would not be read if an old global mercurial.ini still existed. "hg config -g" could also crash when no global configuration files could be found. Instead, make windows behave like posix and read all global configuration files. The documentation was in a way right that individual config settings in the global Mercurial.ini would override settings from for example .hgrc.d\*.rc, but only because the .d files not would be read at all if a Mercurial.ini was found. The ordering in the documentation is thus changed to match the code.
-
- Oct 09, 2015
-
-
Ryan McElroy authored
This will allow reusing it in evolve and overriding it in other extensions.
-
Gregory Szorc authored
Cloning can be an expensive operation for servers because the server generates a bundle from existing repository data at request time. For a large repository like mozilla-central, this consumes 4+ minutes of CPU time on the server. It also results in significant network utilization. Multiplied by hundreds or even thousands of clients and the ensuing load can result in difficulties scaling the Mercurial server. Despite generation of bundles being deterministic until the next changeset is added, the generation of bundles to service a clone request is not cached. Each clone thus performs redundant work. This is wasteful. This patch introduces the "clonebundles" extension and related client-side functionality to help alleviate this deficiency. The client-side feature is behind an experimental flag and is not enabled by default. It works as follows: 1) Server operator generates a bundle and makes it available on a server (likely HTTP). 2) Server operator defines the URL of a bundle file in a .hg/clonebundles.manifest file. 3) Client `hg clone`ing sees the server is advertising bundle URLs. 4) Client fetches and applies the advertised bundle. 5) Client performs equivalent of `hg pull` to fetch changes made since the bundle was created. Essentially, the server performs the expensive work of generating a bundle once and all subsequent clones fetch a static file from somewhere. Scaling static file serving is a much more manageable problem than scaling a Python application like Mercurial. Assuming your repository grows less than 1% per day, the end result is 99+% of CPU and network load from clones is eliminated, allowing Mercurial servers to scale more easily. Serving static files also means data can be transferred to clients as fast as they can consume it, rather than as fast as servers can generate it. This makes clones faster. Mozilla has implemented similar functionality of this patch on hg.mozilla.org using a custom extension. We are hosting bundle files in Amazon S3 and CloudFront (a CDN) and have successfully offloaded >1 TB/day in data transfer from hg.mozilla.org, freeing up significant bandwidth and CPU resources. The positive impact has been stellar and I believe it has proved its value to be included in Mercurial core. I feel it is important for the client-side support to be enabled in core by default because it means that clients will get faster, more reliable clones and will enable server operators to reduce load without requiring any client-side configuration changes (assuming clients are up to date, of course). The scope of this feature is narrowly and specifically tailored to cloning, despite "serve pulls from pre-generated bundles" being a valid and useful feature. I would eventually like for Mercurial servers to support transferring *all* repository data via statically hosted files. You could imagine a server that siphons all pushed data to bundle files and instructs clients to apply a stream of bundles to reconstruct all repository data. This feature, while useful and powerful, is significantly more work to implement because it requires the server component have awareness of discovery and a mapping of which changesets are in which files. Full, clone bundles, by contrast, are much simpler. The wire protocol command is named "clonebundles" instead of something more generic like "staticbundles" to leave the door open for a new, more powerful and more generic server-side component with minimal backwards compatibility implications. The name "bundleclone" is used by Mozilla's extension and would cause problems since there are subtle differences in Mozilla's extension. Mozilla's experience with this idea has taught us that some form of "content negotiation" is required. Not all clients will support all bundle formats or even URLs (advanced TLS requirements, etc). To ensure the highest uptake possible, a server needs to advertise multiple versions of bundles and clients need to be able to choose the most appropriate from that list one. The "attributes" in each server-advertised entry facilitate this filtering and sorting. Their use will become apparent in subsequent patches. Initial inspiration and credit for the idea of cloning from static files belongs to Augie Fackler and his "lookaside clone" extension proof of concept.
-
- Sep 29, 2015
-
-
Gregory Szorc authored
This will be used so clone bundles can advertise whether URLs require SNI. This will be explained more in a subsequent patch.
-
- Oct 12, 2015
-
-
Siddharth Agarwal authored
Just like the BC to merge before it, this allows for a maximally consistent state before providing any prompts to the user.
-
Siddharth Agarwal authored
An upcoming patch will touch some code around this area, and I couldn't find any tests related to this.
-
Siddharth Agarwal authored
This basically shows the behavior of resolve with multiple files. An upcoming behavior change will cause this output to also change.
-
Siddharth Agarwal authored
We perform all that we can non-interactively before prompting the user for input via their merge tool. This allows for a maximally consistent state when the user is first prompted. The test output changes indicate the actual behavior change happening.
-
Siddharth Agarwal authored
The section of code that writes out the version of the file cached in the merge state should only be run at preresolve time. This is so that if the premerge keeps around conflict markers, those don't get overwritten before the main merge.
-
Siddharth Agarwal authored
We'll need this for a new 'preresolve' function we're adding.
-
Siddharth Agarwal authored
The resolve function will be broken up into separate pre-resolve and resolve steps.
-
- Oct 09, 2015
-
-
Siddharth Agarwal authored
The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
-
- Oct 11, 2015
-
-
Siddharth Agarwal authored
We now exit early if we do a premerge, so extra checks are no longer necessary.
-
- Oct 12, 2015
-
-
Augie Fackler authored
-
Siddharth Agarwal authored
This means that in ms.resolve we must call merge after calling premerge. This doesn't yet mean that all premerges happen before any merges -- however, this does get us closer to our goal. The output differences are because we recompute the merge tool. The only user-visible difference caused by this patch is that if the tool is missing we'll print the warning twice. Not a huge deal, though.
-
Siddharth Agarwal authored
The premerge might leave the original file in an unclean state. Therefore it's important to only copy the file in the beginning.
-
Siddharth Agarwal authored
We're soon going to call this function twice, once for premerge and once for merge. This makes sure the "merging" output only gets printed during the premerge step.
-
- Oct 08, 2015
-
-
Siddharth Agarwal authored
It is no longer necessary to indent these parts.
-
- Oct 12, 2015
-
-
Siddharth Agarwal authored
This flag will let us get to our overall goal of performing all premerges before any merges.
-
- Oct 11, 2015
-
-
Siddharth Agarwal authored
In future patches, we'll pause merges after the premerge step. After the premerge step we'll return complete = False.
-
Siddharth Agarwal authored
We'll introduce a separate premerge function that calls the same code.
-
- Oct 08, 2015
-
-
Mads Kiilerich authored
d3908c911d5e introduced nice hexified display of missing nodes. It did however also make missing 20 character revision specifications be shown as hex - very confusing. Users are often wrong and somehow specify revisions that don't exist. Nodes will however rarely be missing ... and they will only look like a user provided revision specification and be all ascii in 1 of 4*10**9. With this change, missing revisions will only be hexified if they really look like binary nodes. This change will thus improve the error reporting UI in the common case and only very rarely make it confusing in the opposite direction of how it was before.
-
- Oct 12, 2015
-
-
Pierre-Yves David authored
Having the simple and tiny branch of the conditional first help readability. The "else" that appears after a screen of code is harder to relate to a conditional.
-
- Oct 09, 2015
-
-
Pierre-Yves David authored
That function is actually not returning public ancestors at all. This is pointed by the second line of the docstring... The bundling behavior was made correct in a5141977198d but with confusion remaining regarding what each function was doing. This close issue4737, because this highlight that shelve is actually -not- bundling too much data (this was actually properly tested).
-
Nathan Goldbaum authored
-
Nathan Goldbaum authored
This should allow easier experimentation with using setuptools in mercurial's build automation, without breaking anything that currently depends on distutils behavior
-
- Oct 12, 2015
-
-
Gijs Kruitbosch authored
-
Anton Shestakov authored
For reference, this was added to paper/coal in bb00a159e594 and to gitweb in b3b57ecbda50.
-
- Oct 09, 2015
-
-
Pierre-Yves David authored
We extend the comment about this code flaw with more code flaw.
-
Pierre-Yves David authored
The idea here is that the code is imperfect, not that it is impossible to get something behaving properly.
-
Pierre-Yves David authored
The current setup requires to pass both a packer and, optionally, the version of the unpacker. This is confusing and error prone as the two value cannot mismatch. Instead, we simply grab the version from the packer. This fixes a bug where requesting a cg2 from 'hg bundle' were reported as changegroup 1. I should have caught that in the initial changeset but I missed it somehow.
-
- Oct 12, 2015
-
-
Emanuele Giaquinta authored
This change makes the test pass on gcc112.fsffrance.org.
-
- Oct 07, 2015
-
-
Emanuele Giaquinta authored
cvsps computes the parent revisions of log entries by walking the cvs log sorted by (rcs, revision) and by iteratively maintaining a 'versions' dictionary which maps a (rcs, branch) pair onto the last revision seen for that pair. When log caching is on and a log cache exists, cvsps fails to set the parent revisions of new log entries because it does not iterate over the log cache in the parents computation. A complication is that a file rcs can change (move to/from the attic), with respect to its value in the log cache, if the file is removed/added back. This patch adds an iteration over the log cache to update the rcs of cached log entries, if changed, and to properly populate the 'versions' dictionary.
-
- Oct 06, 2015
-
-
Matt Mackall authored
This makes it more interruptible.
-