[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: Blair Zajac <blair_at_orcaware.com>
Date: 2007-10-23 19:32:09 CEST

Jack Repenning wrote:
> On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com
> <mailto:kmradke@rockwellcollins.com> wrote:
>> Micah Elliott <mde@micahelliott.com <mailto:mde@micahelliott.com>>
>> wrote on 10/23/2007 10:59:50 AM:
>> > On 2007-10-23 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.
>> > ...
>> > This will definitely a useful requirement for me (now that you
>> > thought of it :-). I'm also in a corporate setting with 100+
>> > committers. We're waiting to do our CVS conversion until 1.5
>> > since we'd hate to be without merge tracking.
>> I'll do anything I can to stop our 1400+ users from shooting
>> themselves in the foot. (Because they hit my feet too!)
> This is interesting. I'm not raising an objection here, just exploring:
> if you have so strong a need to protect your users, don't you already
> have some other, more general means in place? Standard installations,
> "scorched-earth sysadmin," that sort of thing?

Even with the scorhed-earth systems, there are ways this could happen.

You could also have users who VPN in from home or a laptop that they set up for
themselves with the code and want to do commits.

Even with Eclipse and Subclipse, you don't need any root or admin privileges to
download and start to use it, you just need a system with Java installed on it.
  So somebody could have an older 1.4 release and use commit with it.

I'm aware of corporations where you can have power users/developers who have
sudo or su privileges but aren't Subversion experts and may try a new Subversion
client that could be linked against 1.4.

There's always ways for somebody to grab some older svn client.

> The reason I ask: I've never worked in a shop that had such policies,
> but when I've talked to customers that do, they definitely want to
> control more than just the VC system. When Microsoft comes out with a
> new Word format, for example, they tend both to pre-install with the
> "write out in old format," and go around to existing machines and
> re-install, to lock that in. How does that spin with your situation? Do
> you not do that? Do you do that in general, but like the extra
> protection of server-side verification?

I think 'like' is too weak of a word. I don't count on the desktops being
installed or properly maintained, hence having the server do it is a requirement.

Also, the svn administrator may want a tight policy but the OS administrator's
don't have a scorched-earth policy, so don't properly maintain systems.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 23 19:32:28 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.