On Mon, Feb 23, 2015 at 10:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> >> It's very hard to keep backward compatibility if you want to stop the >> initial ref adverstisement, costly when there are lots of refs. But we >> can let both protocols run in parallel, with the old one advertise the >> presence of the new one. Then the client could switch to new protocol >> gradually. This way new protocol could forget about backward >> compatibility. See >> >> http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 > > Yes, the whole thread is worth a read, but the approach suggested by > that article $gmane/244325 is very good for its simplicity. The server > end programs, upload-pack and receive-pack, need to only learn to > advertise the availability of upload-pack-v2 and receive-pack-v2 > services and the client side programs, fetch-pack and push-pack, > need to only notice the advertisement and record the availability of > v2 counterparts for the current remote *and* continue the exchange > in v1 protocol. That way, there is very little risk for breaking anything. Right, I want to add this "learn about v2 on the fly, continue as always" to the protocol. > > So if we are going to discuss a new protocol, I'd prefer to see the > discussion without worrying too much about how to inter-operate > with the current vintage of Git. It is no longer an interesting problem, > as we know how to solve it with minimum risk. Instead, I'd like to > see us design the new protocol in such a way that it is in-line > upgradable without repeating our past mistakes. > > I am *not* convinced that we want multiple suite of protocols that > must be chosen from to suit the use pattern, as mentioned somewhere > upthread, by the way. I do think it makes sense to have different protocols or different tunings of one protocol, because there are many different situations in which different metrics are the key metric. If you are on mobile, you'd possibly be billed by the bytes on the wire, so you want to have a protocol with as actual transport as possible and would maybe trade off transported bytes to lots of computational overhead. If you are in Australia (sorry downunder ;) or on satellite internet, you may care a lot about latency and roundtrip times. If you are in a corporate environment and just cloning from next door, you may want to have the overall process (compute+network+ local reconstruction) just be fast overall. I can understand, that we maybe want to just provide one generic "version 2" of the protocol which is an allrounder not doing bad in all of these aspects, but I can see usecases of having the desire to replace the wire protocol by your own implementation. To do so we could try to offer an API which makes implementing a new protocol somewhat easy. The current state of affairs is not providing this flexibility. I think it would be not much overhead to have such flexibility when writing the actual code for the "very little risk" v2 update. So instead of advertising a boolean flag meaning "This server/client speaks version2", we would rather send a list "This server speaks v2,v1 and v-custom-optimized-for-high-latency". I started looking for academic literature if there are generic solutions to finding graph differences, but no real luck for adapting to our problem yet. Thanks for your input, Stefan -- 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