| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
previously due to import errors and a somewhat inconsistent working tree that occurred when switching branches ...
|
|
|
|
| |
them. Incremeneted version to 0.3.0 beta1
|
|
|
|
| |
the rule of trying not to cache possibly heavy data. The data_stream method should be used instead
|
|
|
|
| |
the submodules's naming conventions
|
|
|
|
| |
replaced them by a real test which actually executes code, and puts everything into the tmp directory
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
use 20 byte sha's internally as it is closer to the GitDB implementation
Switched all remaining files back to tabs
Adjusted all remaining docstrings to suit the sphinx doc convention - its likely that there are many of docstring syntax errors though
|
|
|
|
| |
to using git-read-tree to keep the stat information when merging one tree in. After all this is what needed to be implemented in python as well
|
|
|
|
| |
The default is to write the physical index, which is the behaviour you would expect
|
|
|
|
|
|
| |
was actually empty. This is a rare case that can happen during stream testing. Theoretically there shouldn't be any empty streams of course, but practically they do exist sometimes ;); fixed stream.seek implementation, which previously used seek on standard output
Improved GitCmd error handling
|
|
|
|
|
|
| |
not implemented causing incorrect merge results. Added test to cover this issue
Diff: added NULL_BIN_SHA constant for completeness
|
| |
|
|
|
|
| |
including simple test, it may be simple as the methods it uses are throroughly tested
|
| |
|
|
|
|
| |
in progress
|
|
|
|
|
|
|
| |
can do much more than we can ( and faster assumably ), the .new method is used to create new index instances from up to 3 trees.
Implemented multi-tree traversal to facilitate building a stage list more efficiently ( although I am not sure whether it could be faster to use a dictionary together with some intensive lookup ), including test
Added performance to learn how fast certain operations are, and whether one should be preferred over another
|
|
|
|
| |
IO will only be done when required. A possible disadvantage though is that time is spent on compressing the trees, although only the raw data and their shas would theoretically be needed. On the other hand, compressing their data uses less memory. An optimal implementation would just sha the data, check for existance, and compress it to write it to the database right away. This would mean more specialized code though, introducing redundancy. If IStreams would know whether they contain compressed or uncompressed data, and if there was a method to get a sha from data, this would work nicely in the existing framework though
|
| |
|
|
|
|
|
|
|
| |
correctly, a test to explicitly compare the git version with the python implementation is still missing
Tree and Index internally use 20 byte shas, converting them only as needed to reduce memory footprint and processing time
objects: started own 'fun' module containing the most important tree functions, more are likely to be added soon
|
|
|
|
| |
faster as it removes one level of indirection, and makes the main file smaller, improving maintainability
|
| |
|
|
|
|
| |
information to just the stage ( just to be closer to the git-original )
|
|
|
|
| |
python version is about as fast, but could support multithreading using async
|
|
|
|
| |
repo: now has the option to use the pure python git database implementation, which is currently not used though
|
|
|
|
| |
Previously it was located in gitdb, which doesn't have any facilities to use the git command
|
|
|
|
| |
gitdb as well
|
| |
|
|
|
|
|
|
| |
is actually more efficient than the previous implementation
Index now locks its file for reading, and properly uses LockedFD when writing
|
| |
|
| |
|
|
|
|
| |
reduce the file size as much as I would have liked, but certainly is a start for further 'outsourcing'
|
|
|
|
| |
fast, while staying compatible with serialization which requires it to be sorted
|
|
|
|
| |
information - this also speeds up later serialization after changes. its clear though that retrieving actual objects is slower currently as these are not cached anymore. Its worth thinking about moving these encoding, decoding routines to gitdb
|
|
|
|
|
|
|
| |
according to a simple test
( presort still needs implementation )
submodule: added stub to allow the tree to return something, its not implemented though
|
|
|
|
|
|
| |
was added instead
Adjusted all imports to deal with the changed package names
|
| |
|
|
|
|
| |
on starting with just the main thread
|
|
|
|
| |
functionality - previously the callback functionality was bound to channel based readers/writers
|
|
|
|
|
|
| |
anymore, but are abstract.
Added IteratorReader, implementing the reader interface from an iterator. The implementation moved from the TaskIterator to the channel
|
|
|
|
| |
default. It shows that there must be the notion of a producer, which can work if there are no items read
|
| |
|
|
|
|
| |
works on py2.4, 2.5 and 2.6
|
|
|
|
| |
printing thanks to the underlying threading implementation, we can at least make sure that the interpreter doesn't block during shutdown. Now it appears to be running smoothly
|
|
|
|
| |
lock is not actually released or they are not actually notifyied, staying in a beautysleep. This glitch is probably caused by some detail not treated correctly in the thread python module, which is something we cannot fix. It works most of the time as expected though - maybe some cleanup is not done correctly which causes this
|
|
|
|
| |
well as concurrency issues. Now it works okay, but the thread-shutdown is still an issue, as it causes incorrect behaviour making the tests fail. Its good, as it hints at additional issues that need to be solved. There is just a little more left on the feature side, but its nearly there
|
|
|
|
| |
their duty to close the channel if required. Code is a little less maintainable now, but faster, it appears
|
|
|
|
| |
closed only when there is no one else writing to it. This assures that all tasks can continue working, and put their results accordingly. Shutdown is still not working correctly, but that should be solvable as well. Its still not perfect though ...
|