[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Rejecting commits to a 1.5 server from clients < 1.5

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-10-23 22:07:23 CEST

On Tue, 23 Oct 2007, 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.

Blair actually brought this issue up about a year ago, and the
consensus was that while it's certainly a valid issue, we currently
have no reliable way to do this. We simply can't trust the client, so
can't enforce this with 100% reliability. We can, however, put some
"guideline" constraints in place (along the lines of the suggestions
in this thread).

  • application/pgp-signature attachment: stored
Received on Tue Oct 23 22:07:37 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.