On 8/6/07, Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > "Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > > > Git tries to be smart in at least 2 ways that don't work with dump > > protocols: it works locklessly (yet it performs atomic updates) and it > > sends only the objects needed over the wire (saving a lot of > > bandwidth). > > > > Using dumb protocols it's impossible to do either. > > That's not exactly true. You can't be as efficient with dumb protocols You are right -- I should have said: it's pretty hard, and we haven't put the effort ;-) there's been discussion recently of having info in the pack index that would support http range requests. > (its ancestor, > GNU Arch, also had a way to be network-efficient on dumb protocols). Do I remember your name from gnuarch-users? -- that Arch/tla was never particularly efficient, and fetches of large updates were slow and painful. Surely it was efficient on paper though :-p > Regarding atomic and lock-less updates, I believe this is > implementable too as soon as you have an atomit "rename" in the > protocol. But here, bzr isn't a proof of existance, it does locking. And I should have said - minimal locking rather than no locking To update it safely, you need to open with a lock, read to ensure the sha1 is what you think it is, write the new sha1, close. A rename is still subject to race conditions. IMVHO it would be good to have a way to push over sftp even it it is slow, unsafe and full of big blinking warnings. git itself is sane enough that the client side won't get corrupted or lose data if there is a race condition on the server side. Given a brief delay, the client can probably check - post push - that the operation wasn't clobbered by a race condition. Of course, this *is* sticks-and-bubblegum approach on the server side. But a solid client repo makes almost any server-side disaster recoverable. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
