| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ / / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The previous patch had a flaw; it assumed that darcs was storing the committer's timezone.
Instead, darcs always stores UTC timestamps in an ISO 8601 format.
Tools like "darcs changes" convert this into the user's local time as a convenience.
I couldn't find an authoritative spec, but here are some relevant references.
http://wiki.darcs.net/NamedPatch
http://search.cpan.org/~david/Darcs-Inventory-1.4/lib/Darcs/Inventory/Patch.pm
http://bugs.darcs.net/issue140
To resolve the issue, this patch always reports that the timezone is UTC.
|
|\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously, the export was mangling timezones. There were conversion errors when the darcs TZ
did not match the conversion TZ. Also, the conversion timezone was always reported (this is
bad since two conversions may now differ).
This patch fixes both problems on my system, but it has not been extensively tested.
Can 'local_date' be used reliably? What about my TZ manipulations?
I am no expert in darcs or python. Developed with darcs 2.3.1 and Python 2.6.4.
To check for errors, I compared a darcs repo against a "git darcs fetch" into a new repo.
The following two commands were helpful.
# darcs changes | grep for dates
# git log --pretty=format:%ad REF | cat
Example -- EDT=UTC-4 and EST=UTC-5; I am processing in EDT.
darcs date:
"Fri Mar 31 10:48:00 EST 2006"
Before patch, git reported:
"Fri Mar 31 12:48:00 2006 -0400" (should be 11:48 -0400 or 10:48 -0500)
After patch, git reported:
"Fri Mar 31 10:48:00 2006 -0500"
|
| | | | | | | |
|
| | | | | | | |
|
|/ / / / / / |
|
| | | | | | |
|
|\ \ \ \ \ \ |
|
|/ / / / / / |
|
|\ \ \ \ \ \ |
|
|/ / / / / / |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As it's missing from python2.5.
|
|\ \ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
deleted and restored.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This changes the file_id heads lookups to use a KnownGraph over all revision-ids
which should be a lot better than using a regular Graph instance.
Initial testing w/ xserver doesn't show much, since it seems to be purely
linear for quite a bit of x history.
Oddly enough the heads result seems to give a different number of file texts
which is worrying.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Rather than holding most of the logic ourselves.
|
| |/ / / / / / / |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This still works, but it means that we don't keep the in-memory deserialized bits
from the previous inventory. Instead we start from-scratch each time.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Also, shrink the 'small blob' size a bit to allow data to be reclaimed. Though it did
show up as *lots* of small files in the qt import. Something like 1-2k files in the
first 2 dumps.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
During the qt import, we end up with >2000 large blobs, and a few hundred MB of
small blobs. We don't want to create more small blobs, because their disk space
is not reclaimed, but >2000 is too many open file handles (at least on Windows).
Using filenames works, but we aren't as guaranteed that things will clean up
nicely.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
the stream yet.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It turns out that the add_revision_by_delta code was not properly setting
inv_sha1, but it didn't matter because apparently the other code wasn't really
using it....
Anyway, this gives us a proper new inventory, and seems to generally be working.
The next step is that the 'merge' file text is not present because the
delta stream does not contain it...
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
custom implementation.
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| |/ / / / / / / |
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| |/ / / / / / / |
|
| | | | | | | | |
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \ |
|
|/ / / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
inventory to check for deletions.
Instead, just use 'create_by_apply_delta'.
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
|
|/ / / / / / / |
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Move building a dict to the one callsite which actually wants that.
|
| | | | | | | |
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
with 'trunk',
by tightening logic in BranchMapper._git_to_bzr_name. Also document.
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| | | | | | |
|
|/ / / / / |
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The code should be a lot more readable now and we can avoid function
names like open_() as well.
All testcases still pass.
|