Comment 9 for bug 495000
Revision history for this message
| Gareth White (gwhite-deactivatedaccount) wrote | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Wouldn't the error be PermissionDenied if the file was in use during the rename? I thought what was happening was that the second autopack was attempting to move a file which had already been moved by the first autopack. Maybe I'm looking at the wrong bit of code. In any case, I guess any of these problems could happen if multiple autopacks were going on concurrently.
Is there some way it could detect an autopack was already in progress and then not attempt the second one? It seems like it would be difficult to handle all errors that could come up when two or more are running concurrently.
BTW, I was able to reproduce the problem on a larger repository on revisions other than the first 10, 100, 1000 etc. Even though those autopacks are the slowest by far (8 minutes+) the other multiples of 10 or 100 etc. also take a non-trivial amount of time. I suppose that in practice we would be pretty unlucky to get an overlap of two of these autopacks even if we were doing 100 commits a day, but it could happen.
(It would be great if you do change the autopack algorithm at some point to consider the size of the packs. Our first revision is almost 1 GB so we'd be pretty happy if it was never packed again at all! Alternatively if there was a way to disable autopacking altogether we could just schedule a manual pack overnight. Anyway, I'm getting a bit off topic now...)