Jack Repenning <jrepenning@collab.net> wrote on 10/23/2007 11:51:46 AM:
> On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com wrote:
>
> Micah Elliott <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?
We are getting more and more "non-technical" users of Subversion here.
Things really need to work "out of the box", with little tweaking on
their part. A standard install can only go as far as the tools allow
them to be configured. For example, I would love repository side
auto-props. That way I can control settings based upon the 300+
repositories instead of the 1400+ separate client installs.
We have lots of cases where the same user may want different
settings for different projects. Forcing them to manually
reconfigure their client is both time consuming and error prone.
If the client could pull that info from the server, setting up
a new user is trivial.
The real need is to protect me from having 1400 users call me and
say "what did I do wrong?".
I can enforce separate policies by preventing actions in hook
scripts, but that usually just confuses the user.
> 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'm primarily supporting CM systems here. We have a whole separate
department that does the rest of the (non-engineering) IT work.
Due to certification requirements, we do lock down environments, and
typically they are unchanging after a certain amount of time. The
problems occur when an individual needs to work on multiple projects
with (potentially) incompatible tools. (Probably have to solve
this with something like VM images...)
Anyway, back to the original reason of this thread, if older clients can
mess
up newer repos, we need a way to protect the repo from this happening.
While I can try and control what clients are used, I'm not able to
control all users at all times in all places. (Nor do I really want to.)
A "minimum supported client version" property per repo would easily
solve this specific problem, but something more general would probably
serve us better in the future.
Kevin Radke
Received on Tue Oct 23 19:43:36 2007