| Age | Commit message (Collapse) | Author |
|---|
|
was added instead
Adjusted all imports to deal with the changed package names
|
|
to do with the object db. If that really works the way I want, it will become an own project, called async
|
|
inter-dependent tasks
|
|
Git-Python. I have the feeling it can do much good here :)
|
|
restructured odb tests, they are now in an own module to keep the modules small
|
|
will always be compressed if generated by the system ( even future memory db's will compress it )
loose db: implemented direct stream copy, indicated by a sha set in the IStream, including test. This will be the case once Packs are exploded for instance
|
|
for streams starts to show up, but its not yet there
|
|
but next there will have to be more through testing
|
|
multi-threading implementation of all odb functions
|
|
everything. Next is to implement pack-file reading, then alternates which should allow to resolve everything
|
|
|
|
parsing which truncated newlines although it was ilegitimate. Its up to the reader to truncate therse, nowhere in the git code I could find anyone adding newlines to commits where it is written
Added performance tests for serialization, it does about 5k commits per second if writing to tmpfs
|
|
|
|
missing ) and added performance tests which are extremely promising
|
|
efficiently considering that it copies string buffers all the time
|
|
|
|
appears to be working
|
|
objects will be written using our utilities, and certain object retrieval functionality moves into the GitObjectDatabase which is used by the repo instance
Added performance test for object database access, which shows quite respectable tree parsing performance, and okay blob access. Nonetheless, it will be hard to beat the c performance using a pure python implementation, but it can be a nice practice to write it anyway to allow more direct pack manipulations. Some could benefit from the ability to write packs as these can serve as local cache if alternates are used
|
