D12558: rust-filelog: don't use persistent nodemap (to match Python)

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D12558

AFFECTED FILES
  rust/hg-core/src/revlog/filelog.rs

CHANGE DETAILS

diff --git a/rust/hg-core/src/revlog/filelog.rs 
b/rust/hg-core/src/revlog/filelog.rs
--- a/rust/hg-core/src/revlog/filelog.rs
+++ b/rust/hg-core/src/revlog/filelog.rs
@@ -1,6 +1,5 @@
 use crate::errors::HgError;
 use crate::repo::Repo;
-use crate::requirements;
 use crate::revlog::path_encode::path_encode;
 use crate::revlog::revlog::RevlogEntry;
 use crate::revlog::revlog::{Revlog, RevlogError};
@@ -21,11 +20,7 @@
 pub fn open(repo: , file_path: ) -> Result {
 let index_path = store_path(file_path, b".i");
 let data_path = store_path(file_path, b".d");
-let use_nodemap = repo
-.requirements()
-.contains(requirements::NODEMAP_REQUIREMENT);
-let revlog =
-Revlog::open(repo, index_path, Some(_path), use_nodemap)?;
+let revlog = Revlog::open(repo, index_path, Some(_path), false)?;
 Ok(Self { revlog })
 }
 



To: martinvonz, #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

mercurial@49065: 7 new changesets (2 on stable)

[Mercurial Commits]

7 new changesets (2 on stable) in mercurial:

https://www.mercurial-scm.org/repo/hg/rev/80579e597439
changeset:   49059:80579e597439
branch:  stable
parent:  49050:8653a2a33736
user:Kyle Lippincott 
date:Wed Apr 13 13:15:33 2022 -0700
summary: tests: add test demonstrating issue with ambiguous has prefixes 
during rebase

https://www.mercurial-scm.org/repo/hg/rev/532b649c1deb
changeset:   49060:532b649c1deb
branch:  stable
user:Kyle Lippincott 
date:Wed Apr 13 12:14:17 2022 -0700
summary: rebase: while rewriting desc hashes, ignore ambiguous prefix 
"hashes"

https://www.mercurial-scm.org/repo/hg/rev/81d293eb5264
changeset:   49061:81d293eb5264
parent:  49058:d8a38186a092
user:Martin von Zweigbergk 
date:Thu Mar 31 22:02:46 2022 -0700
summary: rust-requirements: allow loading repos with `bookmarksinstore` 
requirement

https://www.mercurial-scm.org/repo/hg/rev/fb82b5cb8301
changeset:   49062:fb82b5cb8301
user:Martin von Zweigbergk 
date:Thu Mar 31 22:06:26 2022 -0700
summary: rust-changelog: don't skip empty lines when iterating over 
changeset lines

https://www.mercurial-scm.org/repo/hg/rev/cc132255261b
changeset:   49063:cc132255261b
user:Martin von Zweigbergk 
date:Mon Apr 04 23:27:16 2022 -0700
summary: rust-changelog: remove special parsing of empty changelog data for 
null rev

https://www.mercurial-scm.org/repo/hg/rev/95da3e99cbd8
changeset:   49064:95da3e99cbd8
user:Martin von Zweigbergk 
date:Tue Apr 05 08:47:04 2022 -0700
summary: rust-changelog: start parsing changeset data

https://www.mercurial-scm.org/repo/hg/rev/5d205e476057
changeset:   49065:5d205e476057
bookmark:@
tag: tip
user:Martin von Zweigbergk 
date:Tue Apr 05 12:06:32 2022 -0700
summary: rust-revlog: add methods for getting parent revs and entries

-- 
Repository URL: https://www.mercurial-scm.org/repo/hg
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: Moving away from Phabricator

[Raphaël Gomès]

On 4/13/22 22:24, Augie Fackler wrote:



On Apr 13, 2022, at 12:06 PM, Raphaël Gomès 
 wrote:


Hi everyone,

It has now been more than a month and our window to migrate out of 
our VM is closing down.




Thanks for keeping track of this!


Thanks for answering quickly!


I am happy to report that the new versions of Heptapod and the evolve 
extension have brought the expected speedups and the push/pull times 
on Heptapod are now much better. There still remains a lot to be 
desired with regards to exchange, but that is for another discussion.


It's time to make an inventory of the project and make some decisions 
about what stays the same, what changes and what disappears. We also 
need to discuss the contribution and review process.


# Inventory

We still don't have a clear path for VM hosting, but maybe the OSUOSL 
can help us, seeing as a good amount of the foss.heptapod.net 
 CI there. See 
https://osuosl.org/services/hosting/details.


## The mailing lists

They're not going anywhere, of course. Additionally, the ability to 
send patches to the devel mailing list will stay, but will not be the 
preferred way proposed.


They are currently managed by a mailman on the VM, which will need to 
be migrated out. The OSUOSL people have already agreed to manage our 
mailing lists for us. This could be a good solution to further reduce 
sysadmin burden.




If we finish off the lists and phabricator, that reduces our footprint 
a _lot_ FWIW. That removes all (I think?) the reasons we have to send 
mail, so you’re really down to hosting the wiki and the repos.



That would reduce the load significantly, yes. :)



## Phabricator

Phabricator will be turned off and be replaced as a means of 
contribution by Heptapod.


The `phab.mercurial-scm.org ` 
differential URLs will be kept around as a static archive: I have 
already started the relatively painful (basically because of AJAX) 
endeavor of creating the scripts to save the valuable history of our 
review discussions, and hope to have enough free time to have it done 
before the VM dies.


## mercurial-scm.org 

The website will need to be migrated out. I don't expect this to be a 
major hassle.


On a related but technically independent front, I've started some 
very simple patches to improve its contents (like not advertising 
that we use Python 2...).


## Wiki

The wiki needs to be migrated out. I'm not exactly sure what the 
story of MoinMoin is currently, but this should also be a relatively 
simple process.


## Repos

I think the project should still use hgweb to advertise at least its 
main (read-only) repository and any other repo that doesn't have a 
better home. See the part about the contribution process for more 
discussion about the hg-committed repo.




These all sound right.


## Patchwork

What should we do about patchwork? I've only been reminded of its 
existence by looking around the VM. Maybe my `getpatches` alias uses 
it underneath for queuing from the mailing list?




If your getpatches alias is the one I think it is, that probably hits 
https://hgpatches.durin42.com/? Which, as the URL suggests, is 
actually running on a machine I own. It’s been zero-maintenance for 
years, but if y’all care about it long-term we should probably 
transition it eventually. Though it’s not as pressing.


Sure, we'll need to figure out something not too long after. Thanks for 
keeping it running.


## Buildbot

This has been functionally dead for a long while and will not be 
carried over now that we have the Heptapod CI.


## Bugzilla

We will want to - of course - keep our bug tracking. We're using 
Bugzilla with MySQL, but we could use PostgreSQL in the target 
machine if that makes it easier, I don't think this particular aspect 
would be too hard to migrate on its own.


The migration from bugzilla to another tool (like Heptapod/Gitlab 
issues) should probably be another discussion to simplify the transition.




Agreed. Bugzilla has been a pretty minor pain point compared to 
phabricator.


The spam issue has been pretty annoying (same problem as with phab), but 
it's still not as urgent. We only have so many things we can do at once 
single time.


## Other things?

Have I forgotten an important piece of the project?



hgbot runs on mercurial-scm.org . It uses a 
sqlite database and is pretty minimal in terms of overhead, so as long 
as wherever we put the VM can handle the irc connection, seems fine.



Ah, right. This will also probably be fine.



# Review process



I’m inactive enough I’ll defer to the opinions of others here. Others: 
if you have opinions, _please_ speak up! This is your chance to make a 
difference before we EOL phabricator and your choices are (by default) 
heptapod and `hg email`.


[snip review process options]



# Conclusion

The hope of this migration is to remove a lot of the sysadmin burden,