On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Tue, Feb 24, 2015 at 10:12 AM, Stefan Beller <sbel...@google.com> wrote: >> One of the biggest problems of a new protocol would be deployment >> as the users probably would not care too deeply. It should just >> work in the sense that the user should not even sense that the >> protocol changed. > > Agreed. > >> To do so we need to make sure the protocol >> is backwards compatible and works if an old client talks to >> a new server as well as the other way round. > > 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.
That's what I actually meant, to have different versions out there, but maybe having the version as of now as the least common denominator such that it always works (albeit inefficient for many refs). > 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 > -- > Duy > I would add that upload-pack also advertises about the availability of > upload-pack2 and the client may set the remote.*.useUploadPack2 to > either yes or auto so next time upload-pack2 will be used. I had a similar thought, though I would not just restrict it to v2 this time, but I'd aim to make it possible to plug whatever protocol you want to. (Comparable to the SSL or ssh, it will always work, but as a proficient user you can spend lot's of time tweaking what you actually want, looking at tradeoffs of efficiency, security, convenience). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
