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

RE: Re: svn:eol-style and other text transforms on commit

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-10-24 14:45:05 CEST

> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
>
> On 10/23/07, Kenneth Porter <shiva@sewingwitch.com> wrote:

> > How about the client supplying the hook (an arbitrary executable)
> > optionally? The server then runs its pre-commit hook as usual to
> > verify that the client's hook has run. For example, the
> client could
> > run an arbitrary formatting program and then the server checks that
> > the result meets the formatting standards and rejects if it doesn't.
>
> Wouldn't that still have security implications?
>
> Why not just make the developer responsible for doing this
> himself (still reject the commit via hook if it doesn't pass tests)?

I agree with you Andy. However, I want to inject an unfortunate reality
out here in corporateland. People want to be spoon-fed. For example, I
am fairly sure that a commercial product will be favored over Subversion
in large part because that product will keep track of who has files
"checked-out". I can argue 'til I'm blue in the face (and have) that
this is a minor feature, but people "need" to see who else is currently
working on "their" file so they can "go over there" and ask what they're
doing so they can "coordinate" the work.

It doesn't matter that it is very unlikely there will be anybody outside
the project working on a given file in a given branch. It doesn't
matter that the team lead is assigning work, and that it should be
patently clear who's working on what. It doesn't matter that even if
there are two or more people working on it that they only have to
resolve issues if there are conflicts (or build/test failures after the
merge). "We must be able to see who has the file checked-out!".

What is my point? I just want to remind the Subversion developers and
designers to remember human nature when deciding on features. I agree
that this particular request presents security issues. I'm just jumping
on the "make the developer responsible for doing this himself" comment
to suggest that this be (or remain) the choice of last resort when
considering designs. The property validation topic floating around here
is an example of something that adds value but could be handled by
"developer responsibility".

{dismounting from soap box}

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 24 14:45:29 2007

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

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