|
List Info
Thread: Re: Rejecting commits to a 1.5 server from clients < 1.5
|
|
| Re: Rejecting commits to a 1.5 server
from clients < 1.5 |
|
2007-10-23 12:43:23 |
|
Jack Repenning <jrepenning collab.net> wrote
on 10/23/2007 11:51:46 AM:
> On Oct 23, 2007, at 9:41 PM, kmradkerockwellcollins.com wrote:
>
> Micah Elliott <mdemicahelliott.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
|
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|