[issue2491] uncompressed bundle files are leaked in many commands

Patrick Mézard <bugs@mercurial.selenic.com> at mercurial.selenic.com Patrick Mézard <bugs@mercurial.selenic.com> at mercurial.selenic.com
Thu Nov 11 17:04:40 UTC 2010


New submission from Patrick Mézard <pmezard at gmail.com>:

When handling a compressed bundle, bundlerepo first uncompress it in a
temporary file then overlay it on top of existing revlogs. The temporary
file is eventually removed when calling .close() or if the __del__() is run.
The problem is it never happens in most cases.

bundlerepos are usually created through hg.repository(). The problem is
repository class was never meant to be closed once used, so bundlerepo
specific close() is almost never called. And __del__ is not guaranteed to be
run upon program termination.

My suggestion is we change that and add an explicit .close() method to the
repository class and use it. Besides fixing the bundlerepo case, I believe
having a reliable finalizer on localrepo may be helpful. Consider adding
something like "incoming()" to revsets. This finalizer would help us getting
rid of the remote bundle once done with it.

Here is a test reproducing the issue in the -R case:

  $ hg init repo
  $ cd repo
  $ echo a > a
  $ hg ci -Am t
  adding a
  $ echo b > b
  $ hg ci -Am t
  adding b
  $ hg bundle --base 0 ../test.hg
  1 changesets found
  $ cd ..
  $ hg clone -r 0 repo repo2
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd repo2

Before importing the bundle

  $ ls .hg | grep bundle
  [1]
  $ hg -R ../test.hg heads
  changeset:   1:2c197ebeca99
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     t
  

After importing the bundle

  $ ls .hg | grep bundle
  hg-bundle-gn6Twm.hg10un

----------
messages: 14377
nosy: pmezard
priority: bug
status: unread
title: uncompressed bundle files are leaked in many commands

____________________________________________________
Mercurial issue tracker <bugs at mercurial.selenic.com>
<http://mercurial.selenic.com/bts/issue2491>
____________________________________________________


More information about the Mercurial-devel mailing list