On Fri, 02 Mar 2018 02:13:18 -0500, Vincent Parrett <vinc...@finalbuilder.com> wrote:

On 2/03/2018 4:31 PM, Vincent Parrett wrote:
I'm not a python dev (mostly c# and delphi), so still getting my head around the hg code base, but I'm curious why the atomictemp=true is used in fileit.addfile? I get that it's in the vfs to work around file locking issues, but with the archive command with type files, it's likely that the archive is going to an empty target directory and this seems wasteful.

So I just knocked up an extension (ciarchive) using the code from archival.py (hg-stable repo) - and in class fileit.addfile :


     f = self.opener(name, "w", atomictemp=True)


     f = self.opener(name, "w", atomictemp=False)

hg.exe archive --time --subrepos --no-decode --quiet c:\temp\archive27
time: real 22.224 secs (user 6.203+0.000 sys 12.078+0.000)

hg.exe ciarchive --time --subrepos --no-decode --quiet c:\temp\archive28
time: real 17.316 secs (user 6.609+0.000 sys 7.453+0.000)

The repo has the following files :
             9438 File(s)    531,462,248 bytes
             2039 Dir(s)

That's a substantial performance increase (our customers have very large repos where this will make a large difference in build times). Of course I'd much rather not be maintaining an extension that uses the internal api of hg, any chance this change can be made in the archive command, or at least be made configurable (assuming this change is safe!)?

AFAICT, the code prior to this vfs call didn't do atomic files, and didn't mention why the atomic aspect changed. It looks like archive doesn't check for an empty directory, but it still seems OK, so go for it.


I did some quick profiling archiving the hg repo, and it looks like a lot of time is spent calculating tag info. Do you see a significant improvement when archiving a tagged revision, and/or using '--config ui.archivemeta=False'? (Ironically, 4.2.2 gave me the worst performance, but it seems like it had something to do with evolve not being able to load?)
Mercurial-devel mailing list

Reply via email to