You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

ObjectReuseAsIs.java 8.5KB

PackWriter: Support reuse of entire packs The most expensive part of packing a repository for transport to another system is enumerating all of the objects in the repository. Once this gets to the size of the linux-2.6 repository (1.8 million objects), enumeration can take several CPU minutes and costs a lot of temporary working set memory. Teach PackWriter to efficiently reuse an existing "cached pack" by answering a clone request with a thin pack followed by a larger cached pack appended to the end. This requires the repository owner to first construct the cached pack by hand, and record the tip commits inside of $GIT_DIR/objects/info/cached-packs: cd $GIT_DIR root=$(git rev-parse master) tmp=objects/.tmp-$$ names=$(echo $root | git pack-objects --keep-true-parents --revs $tmp) for n in $names; do chmod a-w $tmp-$n.pack $tmp-$n.idx touch objects/pack/pack-$n.keep mv $tmp-$n.pack objects/pack/pack-$n.pack mv $tmp-$n.idx objects/pack/pack-$n.idx done (echo "+ $root"; for n in $names; do echo "P $n"; done; echo) >>objects/info/cached-packs git repack -a -d When a clone request needs to include $root, the corresponding cached pack will be copied as-is, rather than enumerating all of the objects that are reachable from $root. For a linux-2.6 kernel repository that should be about 376 MiB, the above process creates two packs of 368 MiB and 38 MiB[1]. This is a local disk usage increase of ~26 MiB, due to reduced delta compression between the large cached pack and the smaller recent activity pack. The overhead is similar to 1 full copy of the compressed project sources. With this cached pack in hand, JGit daemon completes a clone request in 1m17s less time, but a slightly larger data transfer (+2.39 MiB): Before: remote: Counting objects: 1861830, done remote: Finding sources: 100% (1861830/1861830) remote: Getting sizes: 100% (88243/88243) remote: Compressing objects: 100% (88184/88184) Receiving objects: 100% (1861830/1861830), 376.01 MiB | 19.01 MiB/s, done. remote: Total 1861830 (delta 4706), reused 1851053 (delta 1553844) Resolving deltas: 100% (1564621/1564621), done. real 3m19.005s After: remote: Counting objects: 1601, done remote: Counting objects: 1828460, done remote: Finding sources: 100% (50475/50475) remote: Getting sizes: 100% (18843/18843) remote: Compressing objects: 100% (7585/7585) remote: Total 1861830 (delta 2407), reused 1856197 (delta 37510) Receiving objects: 100% (1861830/1861830), 378.40 MiB | 31.31 MiB/s, done. Resolving deltas: 100% (1559477/1559477), done. real 2m2.938s Repository owners can periodically refresh their cached packs by repacking their repository, folding all newer objects into a larger cached pack. Since repacking is already considered to be a normal Git maintenance activity, this isn't a very big burden. [1] In this test $root was set back about two weeks. Change-Id: Ib87131d5c4b5e8c5cacb0f4fe16ff4ece554734b Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
13 yıl önce
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 yıl önce
PackWriter: Support reuse of entire packs The most expensive part of packing a repository for transport to another system is enumerating all of the objects in the repository. Once this gets to the size of the linux-2.6 repository (1.8 million objects), enumeration can take several CPU minutes and costs a lot of temporary working set memory. Teach PackWriter to efficiently reuse an existing "cached pack" by answering a clone request with a thin pack followed by a larger cached pack appended to the end. This requires the repository owner to first construct the cached pack by hand, and record the tip commits inside of $GIT_DIR/objects/info/cached-packs: cd $GIT_DIR root=$(git rev-parse master) tmp=objects/.tmp-$$ names=$(echo $root | git pack-objects --keep-true-parents --revs $tmp) for n in $names; do chmod a-w $tmp-$n.pack $tmp-$n.idx touch objects/pack/pack-$n.keep mv $tmp-$n.pack objects/pack/pack-$n.pack mv $tmp-$n.idx objects/pack/pack-$n.idx done (echo "+ $root"; for n in $names; do echo "P $n"; done; echo) >>objects/info/cached-packs git repack -a -d When a clone request needs to include $root, the corresponding cached pack will be copied as-is, rather than enumerating all of the objects that are reachable from $root. For a linux-2.6 kernel repository that should be about 376 MiB, the above process creates two packs of 368 MiB and 38 MiB[1]. This is a local disk usage increase of ~26 MiB, due to reduced delta compression between the large cached pack and the smaller recent activity pack. The overhead is similar to 1 full copy of the compressed project sources. With this cached pack in hand, JGit daemon completes a clone request in 1m17s less time, but a slightly larger data transfer (+2.39 MiB): Before: remote: Counting objects: 1861830, done remote: Finding sources: 100% (1861830/1861830) remote: Getting sizes: 100% (88243/88243) remote: Compressing objects: 100% (88184/88184) Receiving objects: 100% (1861830/1861830), 376.01 MiB | 19.01 MiB/s, done. remote: Total 1861830 (delta 4706), reused 1851053 (delta 1553844) Resolving deltas: 100% (1564621/1564621), done. real 3m19.005s After: remote: Counting objects: 1601, done remote: Counting objects: 1828460, done remote: Finding sources: 100% (50475/50475) remote: Getting sizes: 100% (18843/18843) remote: Compressing objects: 100% (7585/7585) remote: Total 1861830 (delta 2407), reused 1856197 (delta 37510) Receiving objects: 100% (1861830/1861830), 378.40 MiB | 31.31 MiB/s, done. Resolving deltas: 100% (1559477/1559477), done. real 2m2.938s Repository owners can periodically refresh their cached packs by repacking their repository, folding all newer objects into a larger cached pack. Since repacking is already considered to be a normal Git maintenance activity, this isn't a very big burden. [1] In this test $root was set back about two weeks. Change-Id: Ib87131d5c4b5e8c5cacb0f4fe16ff4ece554734b Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
13 yıl önce
PackWriter: Support reuse of entire packs The most expensive part of packing a repository for transport to another system is enumerating all of the objects in the repository. Once this gets to the size of the linux-2.6 repository (1.8 million objects), enumeration can take several CPU minutes and costs a lot of temporary working set memory. Teach PackWriter to efficiently reuse an existing "cached pack" by answering a clone request with a thin pack followed by a larger cached pack appended to the end. This requires the repository owner to first construct the cached pack by hand, and record the tip commits inside of $GIT_DIR/objects/info/cached-packs: cd $GIT_DIR root=$(git rev-parse master) tmp=objects/.tmp-$$ names=$(echo $root | git pack-objects --keep-true-parents --revs $tmp) for n in $names; do chmod a-w $tmp-$n.pack $tmp-$n.idx touch objects/pack/pack-$n.keep mv $tmp-$n.pack objects/pack/pack-$n.pack mv $tmp-$n.idx objects/pack/pack-$n.idx done (echo "+ $root"; for n in $names; do echo "P $n"; done; echo) >>objects/info/cached-packs git repack -a -d When a clone request needs to include $root, the corresponding cached pack will be copied as-is, rather than enumerating all of the objects that are reachable from $root. For a linux-2.6 kernel repository that should be about 376 MiB, the above process creates two packs of 368 MiB and 38 MiB[1]. This is a local disk usage increase of ~26 MiB, due to reduced delta compression between the large cached pack and the smaller recent activity pack. The overhead is similar to 1 full copy of the compressed project sources. With this cached pack in hand, JGit daemon completes a clone request in 1m17s less time, but a slightly larger data transfer (+2.39 MiB): Before: remote: Counting objects: 1861830, done remote: Finding sources: 100% (1861830/1861830) remote: Getting sizes: 100% (88243/88243) remote: Compressing objects: 100% (88184/88184) Receiving objects: 100% (1861830/1861830), 376.01 MiB | 19.01 MiB/s, done. remote: Total 1861830 (delta 4706), reused 1851053 (delta 1553844) Resolving deltas: 100% (1564621/1564621), done. real 3m19.005s After: remote: Counting objects: 1601, done remote: Counting objects: 1828460, done remote: Finding sources: 100% (50475/50475) remote: Getting sizes: 100% (18843/18843) remote: Compressing objects: 100% (7585/7585) remote: Total 1861830 (delta 2407), reused 1856197 (delta 37510) Receiving objects: 100% (1861830/1861830), 378.40 MiB | 31.31 MiB/s, done. Resolving deltas: 100% (1559477/1559477), done. real 2m2.938s Repository owners can periodically refresh their cached packs by repacking their repository, folding all newer objects into a larger cached pack. Since repacking is already considered to be a normal Git maintenance activity, this isn't a very big burden. [1] In this test $root was set back about two weeks. Change-Id: Ib87131d5c4b5e8c5cacb0f4fe16ff4ece554734b Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
13 yıl önce
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 yıl önce
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 yıl önce
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 yıl önce
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207
  1. /*
  2. * Copyright (C) 2010, Google Inc. and others
  3. *
  4. * This program and the accompanying materials are made available under the
  5. * terms of the Eclipse Distribution License v. 1.0 which is available at
  6. * https://www.eclipse.org/org/documents/edl-v10.php.
  7. *
  8. * SPDX-License-Identifier: BSD-3-Clause
  9. */
  10. package org.eclipse.jgit.internal.storage.pack;
  11. import java.io.IOException;
  12. import java.util.Collection;
  13. import java.util.List;
  14. import org.eclipse.jgit.errors.MissingObjectException;
  15. import org.eclipse.jgit.errors.StoredObjectRepresentationNotAvailableException;
  16. import org.eclipse.jgit.errors.StoredPackRepresentationNotAvailableException;
  17. import org.eclipse.jgit.lib.AnyObjectId;
  18. import org.eclipse.jgit.lib.BitmapIndex.BitmapBuilder;
  19. import org.eclipse.jgit.lib.ProgressMonitor;
  20. /**
  21. * Extension of {@link org.eclipse.jgit.lib.ObjectReader} that supports reusing
  22. * objects in packs.
  23. * <p>
  24. * {@code ObjectReader} implementations may also optionally implement this
  25. * interface to support
  26. * {@link org.eclipse.jgit.internal.storage.pack.PackWriter} with a means of
  27. * copying an object that is already in pack encoding format directly into the
  28. * output stream, without incurring decompression and recompression overheads.
  29. */
  30. public interface ObjectReuseAsIs {
  31. /**
  32. * Allocate a new {@code PackWriter} state structure for an object.
  33. * <p>
  34. * {@link org.eclipse.jgit.internal.storage.pack.PackWriter} allocates these
  35. * objects to keep track of the per-object state, and how to load the
  36. * objects efficiently into the generated stream. Implementers may subclass
  37. * this type with additional object state, such as to remember what file and
  38. * offset contains the object's pack encoded data.
  39. *
  40. * @param objectId
  41. * the id of the object that will be packed.
  42. * @param type
  43. * the Git type of the object that will be packed.
  44. * @return a new instance for this object.
  45. */
  46. ObjectToPack newObjectToPack(AnyObjectId objectId, int type);
  47. /**
  48. * Select the best object representation for a packer.
  49. * <p>
  50. * Implementations should iterate through all available representations of
  51. * an object, and pass them in turn to the PackWriter though
  52. * {@link org.eclipse.jgit.internal.storage.pack.PackWriter#select(ObjectToPack, StoredObjectRepresentation)}
  53. * so the writer can select the most suitable representation to reuse into
  54. * the output stream.
  55. * <p>
  56. * If the implementation returns CachedPack from
  57. * {@link #getCachedPacksAndUpdate(BitmapBuilder)} it must consider the
  58. * representation of any object that is stored in any of the offered
  59. * CachedPacks. PackWriter relies on this behavior to prune duplicate
  60. * objects out of the pack stream when it selects a CachedPack and the
  61. * object was also reached through the thin-pack enumeration.
  62. * <p>
  63. * The implementation may choose to consider multiple objects at once on
  64. * concurrent threads, but must evaluate all representations of an object
  65. * within the same thread.
  66. *
  67. * @param packer
  68. * the packer that will write the object in the near future.
  69. * @param monitor
  70. * progress monitor, implementation should update the monitor
  71. * once for each item in the iteration when selection is done.
  72. * @param objects
  73. * the objects that are being packed.
  74. * @throws org.eclipse.jgit.errors.MissingObjectException
  75. * there is no representation available for the object, as it is
  76. * no longer in the repository. Packing will abort.
  77. * @throws java.io.IOException
  78. * the repository cannot be accessed. Packing will abort.
  79. */
  80. void selectObjectRepresentation(PackWriter packer,
  81. ProgressMonitor monitor, Iterable<ObjectToPack> objects)
  82. throws IOException, MissingObjectException;
  83. /**
  84. * Write objects to the pack stream in roughly the order given.
  85. *
  86. * {@code PackWriter} invokes this method to write out one or more objects,
  87. * in approximately the order specified by the iteration over the list. A
  88. * simple implementation of this method would just iterate the list and
  89. * output each object:
  90. *
  91. * <pre>
  92. * for (ObjectToPack obj : list)
  93. * out.writeObject(obj)
  94. * </pre>
  95. *
  96. * However more sophisticated implementors may try to perform some (small)
  97. * reordering to access objects that are stored close to each other at
  98. * roughly the same time. Implementations may choose to write objects out of
  99. * order, but this may increase pack file size due to using a larger header
  100. * format to reach a delta base that is later in the stream. It may also
  101. * reduce data locality for the reader, slowing down data access.
  102. *
  103. * Invoking
  104. * {@link org.eclipse.jgit.internal.storage.pack.PackOutputStream#writeObject(ObjectToPack)}
  105. * will cause
  106. * {@link #copyObjectAsIs(PackOutputStream, ObjectToPack, boolean)} to be
  107. * invoked recursively on {@code this} if the current object is scheduled
  108. * for reuse.
  109. *
  110. * @param out
  111. * the stream to write each object to.
  112. * @param list
  113. * the list of objects to write. Objects should be written in
  114. * approximately this order. Implementors may resort the list
  115. * elements in-place during writing if desired.
  116. * @throws java.io.IOException
  117. * the stream cannot be written to, or one or more required
  118. * objects cannot be accessed from the object database.
  119. */
  120. void writeObjects(PackOutputStream out, List<ObjectToPack> list)
  121. throws IOException;
  122. /**
  123. * Output a previously selected representation.
  124. * <p>
  125. * {@code PackWriter} invokes this method only if a representation
  126. * previously given to it by {@code selectObjectRepresentation} was chosen
  127. * for reuse into the output stream. The {@code otp} argument is an instance
  128. * created by this reader's own {@code newObjectToPack}, and the
  129. * representation data saved within it also originated from this reader.
  130. * <p>
  131. * Implementors must write the object header before copying the raw data to
  132. * the output stream. The typical implementation is like:
  133. *
  134. * <pre>
  135. * MyToPack mtp = (MyToPack) otp;
  136. * byte[] raw;
  137. * if (validate)
  138. * raw = validate(mtp); // throw SORNAE here, if at all
  139. * else
  140. * raw = readFast(mtp);
  141. * out.writeHeader(mtp, mtp.inflatedSize);
  142. * out.write(raw);
  143. * </pre>
  144. *
  145. * @param out
  146. * stream the object should be written to.
  147. * @param otp
  148. * the object's saved representation information.
  149. * @param validate
  150. * if true the representation must be validated and not be
  151. * corrupt before being reused. If false, validation may be
  152. * skipped as it will be performed elsewhere in the processing
  153. * pipeline.
  154. * @throws org.eclipse.jgit.errors.StoredObjectRepresentationNotAvailableException
  155. * the previously selected representation is no longer
  156. * available. If thrown before {@code out.writeHeader} the pack
  157. * writer will try to find another representation, and write
  158. * that one instead. If throw after {@code out.writeHeader},
  159. * packing will abort.
  160. * @throws java.io.IOException
  161. * the stream's write method threw an exception. Packing will
  162. * abort.
  163. */
  164. void copyObjectAsIs(PackOutputStream out, ObjectToPack otp,
  165. boolean validate) throws IOException,
  166. StoredObjectRepresentationNotAvailableException;
  167. /**
  168. * Append an entire pack's contents onto the output stream.
  169. * <p>
  170. * The entire pack, excluding its header and trailing footer is sent.
  171. *
  172. * @param out
  173. * stream to append the pack onto.
  174. * @param pack
  175. * the cached pack to send.
  176. * @throws java.io.IOException
  177. * the pack cannot be read, or stream did not accept a write.
  178. */
  179. void copyPackAsIs(PackOutputStream out, CachedPack pack)
  180. throws IOException, StoredPackRepresentationNotAvailableException;
  181. /**
  182. * Obtain the available cached packs that match the bitmap and update
  183. * the bitmap by removing the items that are in the CachedPack.
  184. * <p>
  185. * A cached pack has known starting points and may be sent entirely as-is,
  186. * with almost no effort on the sender's part.
  187. *
  188. * @param needBitmap
  189. * the bitmap that contains all of the objects the client wants.
  190. * @return the available cached packs.
  191. * @throws java.io.IOException
  192. * the cached packs cannot be listed from the repository.
  193. * Callers may choose to ignore this and continue as-if there
  194. * were no cached packs.
  195. */
  196. Collection<CachedPack> getCachedPacksAndUpdate(
  197. BitmapBuilder needBitmap) throws IOException;
  198. }