| commit | 4c375d819ca0b6683cd399baed5e1953e0a1ade0 | |
| author | Shawn O. Pearce <spearce@spearce.org> | |
| Sun, 10 Aug 2008 08:46:24 +0000 (10 01:46 -0700) | ||
| committer | Robin Rosenberg <robin.rosenberg@dewire.com> | |
| Wed, 13 Aug 2008 19:55:56 +0000 (13 21:55 +0200) | ||
| tree | 1b48d1b02c296af40a6af0d5bf7695a32377a301 | treesnapshot (tar.gz zip) |
| parent | 022e67f05fa65cb02fd5d085734b99a8e3488837 | commitdiff |
Expose idBuffer,idOffset in AbstractTreeIterator to applications
Application code needs to be able to efficiently copy an id from
an iterator's current position to some buffer, such as in the
index file or a tree object, or any other data structure. Doing
a conversion to ObjectId and then back again to the raw byte form
is less efficient than just copying the bytes between two arrays.
So these methods must be public for performance reasons, even if
it makes the object API slightly more obtuse. Besides we still
have getEntryObjectId should applications prefer that approach
and they don't need the performance.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Application code needs to be able to efficiently copy an id from
an iterator's current position to some buffer, such as in the
index file or a tree object, or any other data structure. Doing
a conversion to ObjectId and then back again to the raw byte form
is less efficient than just copying the bytes between two arrays.
So these methods must be public for performance reasons, even if
it makes the object API slightly more obtuse. Besides we still
have getEntryObjectId should applications prefer that approach
and they don't need the performance.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>