delta/libgit2.git/src/pack-objects.h, branch cmn/remove-single-entry github.com: libgit2/libgit2.git packbuilder: report progress during deltification 2015-05-13T13:52:13+00:00 Carlos Martín Nieto cmn@dwim.me 2015-05-06T11:09:00+00:00 3c337a5d3720f524387307bf443e7d7c6380a2e3 This is useful to send to the client while we're performing the work. The reporting function has a force parameter which makes sure that we do send out the message of 100% completed, even if this comes before the next udpate window. 
This is useful to send to the client while we're performing the work.

The reporting function has a force parameter which makes sure that we
do send out the message of 100% completed, even if this comes before the
next udpate window.
pack-objects: fill a packbuilder from a walk 2015-03-11T01:36:11+00:00 Carlos Martín Nieto cmn@dwim.me 2014-10-11T13:48:29+00:00 04a36feff152fef2fd5f45c46b5cf25e84c7099f Most use-cases for the object packer communicate in terms of commits which each side has. We already have an object to specify this relationship between commits, namely git_revwalk. By knowing which commits we want to pack and which the other side already has, we can perform similar optimisations to git, by marking each tree as interesting or uninteresting only once, and not sending those trees which we know the other side has. 
Most use-cases for the object packer communicate in terms of commits
which each side has. We already have an object to specify this
relationship between commits, namely git_revwalk.

By knowing which commits we want to pack and which the other side
already has, we can perform similar optimisations to git, by marking
each tree as interesting or uninteresting only once, and not sending
those trees which we know the other side has.
Packbuilder contains its own zstream 2014-01-14T17:45:14+00:00 Edward Thomson ethomson@microsoft.com 2014-01-07T00:41:12+00:00 52a8a130728e29d8ac9d6e4f9e3a7017afe461fb 






Initial Implementation of progress reports during push
2013-09-30T17:22:28+00:00

Jameson Miller
jamill@microsoft.com

2013-09-19T18:52:57+00:00

b176ededb7d226ac85809b3ec594d185e7e3e866

This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.

The main areas where this is lacking are:

1) packbuilding progress: does not report progress during deltafication,
   as this involves coordinating progress from multiple threads.

2) network progress: reports progress as objects and bytes are going
   to be written to the subtransport (instead of as client gets
   confirmation that they have been received by the server) and leaves
   out some of the bytes that are transfered as part of the push protocol.
   Basically, this reports the pack bytes that are written to the
   subtransport. It does not report the bytes sent on the wire that
   are received by the server. This should be a good estimate of
   progress (and an improvement over no progress).





This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.

The main areas where this is lacking are:

1) packbuilding progress: does not report progress during deltafication,
   as this involves coordinating progress from multiple threads.

2) network progress: reports progress as objects and bytes are going
   to be written to the subtransport (instead of as client gets
   confirmation that they have been received by the server) and leaves
   out some of the bytes that are transfered as part of the push protocol.
   Basically, this reports the pack bytes that are written to the
   subtransport. It does not report the bytes sent on the wire that
   are received by the server. This should be a good estimate of
   progress (and an improvement over no progress).







update copyrights
2013-01-08T23:31:27+00:00

Edward Thomson
ethomson@edwardthomson.com

2013-01-08T23:07:25+00:00

359fc2d241ac407bdf9bf0d28715705f01ca6360












Push! By schu, phkelley, and congyiwu, et al
2012-11-28T16:42:37+00:00

Philip Kelley
phkelley@hotmail.com

2012-11-28T16:42:37+00:00

613d5eb9391d6cc33c91f4dc9cdb5ede1885dc72












Fix MSVC compilation warnings
2012-11-17T13:13:13+00:00

nulltoken
emeric.fermas@gmail.com

2012-11-17T12:50:48+00:00

86b9dbc12f61c24457f2979e9496c85e115a3799












Remove git_hash_ctx_new - callers now _ctx_init()
2012-11-13T16:23:05+00:00

Edward Thomson
ethomson@microsoft.com

2012-11-13T01:22:49+00:00

603bee07918b50051d7bb45722932fc409b38a67












Reorganize transport architecture (squashed 3)
2012-11-01T13:02:33+00:00

Philip Kelley
phkelley@hotmail.com

2012-10-29T17:41:14+00:00

41fb1ca0ec51ad1d2a14b911aab3215e42965d1b












Incremental improvements to pack-objects logic
2012-10-17T16:07:17+00:00

Philip Kelley
phkelley@hotmail.com

2012-10-16T20:18:21+00:00

b4491b9911b4ceaa64b0fa7b94774affa3f41d43

Incorporate feedback for incr. improvements to pack-objects





Incorporate feedback for incr. improvements to pack-objects