Failed pipeline for branch/stable | mercurial-devel | 20f7a2de
Pipeline #18514 has failed! Project: mercurial-devel ( https://foss.heptapod.net/octobus/mercurial-devel ) Branch: branch/stable ( https://foss.heptapod.net/octobus/mercurial-devel/-/commits/branch/stable ) Commit: 20f7a2de ( https://foss.heptapod.net/octobus/mercurial-devel/-/commit/20f7a2de3e62801f9de1fb47307e51661c4a6726 ) Commit Message: log: fix handling of root (or empty) path provi... Commit Author: Yuya Nishihara ( https://foss.heptapod.net/yuja ) Pipeline #18514 ( https://foss.heptapod.net/octobus/mercurial-devel/-/pipelines/18514 ) triggered by Administrator ( https://foss.heptapod.net/root ) had 2 failed builds. Job #171095 ( https://foss.heptapod.net/octobus/mercurial-devel/-/jobs/171095/raw ) Stage: tests Name: checks-py3 Job #171094 ( https://foss.heptapod.net/octobus/mercurial-devel/-/jobs/171094/raw ) Stage: tests Name: checks-py2 -- You're receiving this email because of your account on foss.heptapod.net. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [RFC] Interaction between strip and caches
> On Dec 14, 2020, at 5:03 PM, Joerg Sonnenberger wrote: > > Hello all, > while looking at the revbranchcache, I noticed that it is doing quite an > expensive probalistic invalidation dance. It is essentially looking up > the revision in the changelog again and compares the first 32bit to see > if they (still) match. Other caches are doing cheaper checks like > remembering the head revision and node and checking it again to match. > The goal is in all cases to detect one of two cases: > > (1) Repository additions by a hg instance without support for the cache. > (2) Repository removals by strip without update support specific to the > cache in use. > > The first part is generally handled reasonable well and cheap. Keep > track of the number of revisions and process to all missing changesets > is something code has to support anyway. The real difficult problem is > the second part. I would like us to adopt a more explicit way of dealing > with this and opt-in support via a repository requirement. Given that > the strip command has finally become part of core, it looks like a good > time to do this now. > > The first option is to require strip to nuke all caches that it can't > update. This is easy to implement and works reliable by nature with all > existing caches. It is also the more blunt option. Won’t the caches invalidate themselves an this defect happens today? > The second option is to keep a journal of strips. This can be a single > monotonically increasing counter and every cache just reads the counter > and rebuilds itself. Alternatively it could be a full journal that lists > the revisions and associated nodes removed. This requires changes to > existing caches but has the advantage that strip can be replayed by the > cache logic to avoid a full rebuild. Potentially complicated, but could be worthwhile in a large repo with strips. Is that something you expect to encounter? For the most part we’ve historically considered strip an anti-pattern of sorts and not worried super hard about optimizing it. > > Joerg > ___ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: SHA1 replacement steps
> On Feb 15, 2021, at 9:18 AM, Joerg Sonnenberger wrote: > > Hello all, > to help the review process along, here are the rough steps I see in > preparation for supporting 256bit hashes: > > (1) Move the current 160bit constants from mercurial.node into a > subclass. Instead of a global constant, derive the correct constant from > the repo/revlog/... instance and pass it down as necessary. The API > change itself is in D9750. The expectation for this step is that a > repository has one hash size and one set of magic values, but it doesn't > change anything regarding the hash function itself. A follow-up change > is necessary to replace the global constants (approximately D9465 minus > D9750). I was somewhat assuming we’d alter various codepaths to always emit 256-bit hashes, even if they end in all NUL. Your way sounds a little more complicated but is also fine, I don’t feel strongly. > > (2) Adjust various on-disk formats to switch between the current 160bit > and 256bit encoding based on the node constants in use. This would be a > non-functional change for existing repositories. Are any on-disk formats not already using 256-bit storage? I know revlogs are, so I _think_ this is only going to matter for caches. > > (3) Introduce the tagged 256(*) hash function. My plan here is to use > Blake2b configured for 248bit output and a suffix of b'\x01'. It is a > bit wasteful to reserve 8bit for the tag, but simplifies code. Biggest > downside is that the full Blake2b support is not available in Python 2. Honestly I think new hash functions is exactly the kind of thing we should gate on Python 3. If someone is _really_ enthusiastic they can write a backport extension or something, for the users that are (bafflingly) caring about modern hashes but stuck on an ancient Python. > > The tag would allow different hash functions to co-exist and embed > existing SHA1 hashes by zero padding. > > (4) Adjust hash verification logic to derive the hash function from the > tag of a node, not just hard-coding it. > > At the end of step 4, most repositories can be converted in a mostly > transparent way. Notably, you can allow people to only upgrade new hashes if they’re so inclined, which lets you preserve gpg signatures etc. > Some additional changes might be necessary for allowing > "short" node ids for things like .hgtags, but overall, existing hashes > should just continue to work as before. Overall +1. We can arm-wrestle later about if allowing a “new commits are blake2b” mode (vs convert-the-repo mode) is reasonable, I don’t think it’ll take a ton of code either way. One request: I think we should reserve a couple of suffixes (0xff and 0xfe, perhaps?) for “private use” - this would be useful for large installations that do strange things with hashing out of necessity. Sorry for taking so long to respond to this - this is well thought out and I was just too busy with other work stuff for a couple weeks straight. > > Joerg > ___ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D10080: rhg: Use clap’s support for global CLI arguments
SimonSapin created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.
REVISION SUMMARY
By default, clap only accepts app-level arguments (as opposed to sub-command
level) to be specified before a sub-command: `rhg -R ./foo log`. Specifying
them after would be rejected: `rhg log -R ./foo`.
Previously we worked around that by registering global arguments both
at the app level and on each sub-command, but that required looking
for their value in two places. It turns out that Clap has built-in support
for what we want to do, so let’s use it.
REPOSITORY
rHG Mercurial
BRANCH
default
REVISION DETAIL
https://phab.mercurial-scm.org/D10080
AFFECTED FILES
rust/rhg/src/main.rs
CHANGE DETAILS
diff --git a/rust/rhg/src/main.rs b/rust/rhg/src/main.rs
--- a/rust/rhg/src/main.rs
+++ b/rust/rhg/src/main.rs
@@ -15,28 +15,6 @@
mod ui;
use error::CommandError;
-fn add_global_args<'a, 'b>(app: App<'a, 'b>) -> App<'a, 'b> {
-app.arg(
-Arg::with_name("repository")
-.help("repository root directory")
-.short("-R")
-.long("--repository")
-.value_name("REPO")
-.takes_value(true),
-)
-.arg(
-Arg::with_name("config")
-.help("set/override config option (use 'section.name=value')")
-.long("--config")
-.value_name("CONFIG")
-.takes_value(true)
-// Ok: `--config section.key1=val --config section.key2=val2`
-.multiple(true)
-// Not ok: `--config section.key1=val section.key2=val2`
-.number_of_values(1),
-)
-}
-
fn main_with_result(
ui: ::Ui,
process_start_time: ::ProcessStartTime,
@@ -46,8 +24,29 @@
.setting(AppSettings::AllowInvalidUtf8)
.setting(AppSettings::SubcommandRequired)
.setting(AppSettings::VersionlessSubcommands)
+.arg(
+Arg::with_name("repository")
+.help("repository root directory")
+.short("-R")
+.long("--repository")
+.value_name("REPO")
+.takes_value(true)
+// Both ok: `hg -R ./foo log` or `hg log -R ./foo`
+.global(true),
+)
+.arg(
+Arg::with_name("config")
+.help("set/override config option (use 'section.name=value')")
+.long("--config")
+.value_name("CONFIG")
+.takes_value(true)
+.global(true)
+// Ok: `--config section.key1=val --config section.key2=val2`
+.multiple(true)
+// Not ok: `--config section.key1=val section.key2=val2`
+.number_of_values(1),
+)
.version("0.0.1");
-let app = add_global_args(app);
let app = add_subcommand_args(app);
let matches = app.clone().get_matches_safe()?;
@@ -58,26 +57,15 @@
let subcommand_args = subcommand_matches
.expect("no subcommand arguments from clap despite
AppSettings::SubcommandRequired");
-// Global arguments can be in either based on e.g. `hg -R ./foo log` v.s.
-// `hg log -R ./foo`
-let value_of_global_arg = |name| {
-subcommand_args
-.value_of_os(name)
-.or_else(|| matches.value_of_os(name))
-};
-// For arguments where multiple occurences are allowed, return a
-// possibly-iterator of all values.
-let values_of_global_arg = |name: | {
-let a = matches.values_of_os(name).into_iter().flatten();
-let b = subcommand_args.values_of_os(name).into_iter().flatten();
-a.chain(b)
-};
-
-let config_args = values_of_global_arg("config")
+let config_args = matches
+.values_of_os("config")
+// Turn `Option::None` into an empty iterator:
+.into_iter()
+.flatten()
.map(hg::utils::files::get_bytes_from_os_str);
let non_repo_config = ::config::Config::load(config_args)?;
-let repo_path = value_of_global_arg("repository").map(Path::new);
+let repo_path = matches.value_of_os("repository").map(Path::new);
let repo = match Repo::find(non_repo_config, repo_path) {
Ok(repo) => Ok(repo),
Err(RepoError::NotFound { at }) if repo_path.is_none() => {
@@ -141,7 +129,7 @@
fn add_subcommand_args<'a, 'b>(app: App<'a, 'b>) -> App<'a, 'b> {
app
$(
-.subcommand(add_global_args(commands::$command::args()))
+.subcommand(commands::$command::args())
)+
}
To: SimonSapin, #hg-reviewers
Cc: mercurial-patches, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
D10079: patch: fix a formatting issue
khanchi97 created this revision. Herald added a reviewer: hg-reviewers. Herald added a subscriber: mercurial-patches. REPOSITORY rHG Mercurial BRANCH stable REVISION DETAIL https://phab.mercurial-scm.org/D10079 AFFECTED FILES mercurial/patch.py CHANGE DETAILS diff --git a/mercurial/patch.py b/mercurial/patch.py --- a/mercurial/patch.py +++ b/mercurial/patch.py @@ -3105,9 +3105,7 @@ if binary and opts.git and not opts.nobinary: text = mdiff.b85diff(content1, content2) if text: -header.append( -b'index %s..%s' % (index1, index2) -) +header.append(b'index %s..%s' % (index1, index2)) hunks = ((None, [text]),) else: if opts.git and opts.index > 0: To: khanchi97, #hg-reviewers Cc: mercurial-patches, mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
