On 10/23/07, Blair Zajac <email@example.com> wrote:
> C. Michael Pilato wrote:
> > Blair Zajac wrote:
> >> As somebody who runs an svn server for open source code and one for
> >> internal corporate use, I want to ensure that all svn clients that
> >> commit send merge info to the server and I don't want to loose this
> >> information. So I want to require that all clients that commit are at
> >> least Subversion 1.5 or later. I can imagine that lots of corporate
> >> shops will want this requirement to prevent somebody from using some
> >> random svn client that does not supply merge info and makes life harder
> >> for a release manager.
> >> Are we planning on offering such a capability? If so, how are we doing
> >> this? If not, this seems like a good use for the start-commit script to
> >> supply an additional parameter, say an $OPTIONS, that can be parsed for
> >> the support the client offers.
> > This was brought up to me personally at SubConf last week as a fairly
> > serious issue in corporate environments. It was the first I could recall of
> > hearing such a concern, but here you are echoing it. So, while I don't yet
> > have a strong position on the matter technically, I do believe we need to
> > have this discussion, and now's as good a time as any to do so.
> I would guess that WebDAV going to be easy to do, just add another HTTP header,
> say X-Svn-Client-Support or something, that mod_dav_svn will parse and propogate
> to the hook scripts? We could have a semicolon separated list of strings, much
> like the HTTP Accept header.
> How are we going to do this for ra_svn?
That's even easier; ra_svn already supports both clients and servers
The part requiring design to me is where we put this preference (is it
per-repo? per-server? etc etc)
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 23 20:14:23 2007