{"thread":{"id":"2351","subject":"[PATCH 0/4] git-http-push improvements","startedAt":"2005-11-04T22:22:10Z","lastAt":"2005-11-04T22:22:10Z","messageCount":1,"participants":["Nick Hengeveld"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"11158","messageId":"20051104222210.GC3001@reactrix.com","threadId":"2351","inReplyTo":null,"subject":"[PATCH 0/4] git-http-push improvements","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-04T22:22:10Z","receivedAt":"2005-11-04T22:22:10Z","isPatch":true,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"This series of patches makes HTTP/DAV pushes more stable.  Locks are\nhandled much better and are refreshed if they are about to expire, and\nremote refs with '/' in their names are supported.\n\nItems still on my todo list:\n\n- Process the server's lock refresh timeout response (currently it\n  assumes that the original lock timeout will continue to work.)\n- Verify remote commit object if branches are the same (currently\n  it does no verification if the refs point to the same object.)\n- Clean up temp filenames after failed PUTs (no need to leave them\n  there since you can't resume.)\n- Either send compressed objects directly rather than uncompressing and\n  recompressing them before sending; or since we have an uncompressed\n  copy, also verify the SHA1 before sending since the remote doesn't\n  verify (and/or consider read after write verification.)\n- Use a pack to send under what circumstances?  Perhaps allow\n  min-pack-size and max-pack-size (more objects == less impact on failed\n  transfer, more transfer overhead.)\n- Attempt recovery if the remote ref PUT fails?\n- Test against other DAV servers (I've currently tested it using only\n  Apache.)\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"}]}