The .hgtags processing uses two different caches. The first cache is
essentially a global version of all .hgtags files and a textual format
without hard size requirements. The second cache stores the file node of
the .hgtags file for those changesets that modify it as fixed size
records. Use a new file name for this record and pad the entries to 32
bytes in preparation for replacing SHA1.
Details
- Reviewers
marmoute - Group Reviewers
hg-reviewers
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
this cache is critical for performance of some large installation. silently dropping v1 update and moving to v2 might have very base consequence in case. Should we keep v1 working and only switch for v2 for repository with 32 bites hashes?
I think it is a one time issue per repository, even when mixing old and new clients they will update incrementally?
Repository accessed by mixed version will get in troubles and even if "this just get updated" this only happens at the first write. In the mean time read only process touching that repository can get to a crawl for a undefined amount of time.
I agree with @marmoute here as building tag cache is expensive for big repositories. We can always write the new version while keeping code to read the older version too.