On Oct 24, 2007, at 07:45, Bicking, David (HHoldings, IT) wrote:
> Andy Levy wrote:
>
>> On 10/23/07, 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!".
I don't see how Subversion's disinclination to tell you who has
checked out a file is relevant to the question of performing text
transforms on commit.
If you want to see who performs the "svn checkout" (or "svn export"
or "svn update") operation, you can serve the repository using Apache
and use my log watching script to simulate such hooks:
http://www.ryandesign.com/svnhookdispatcher/
> 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}
I haven't exactly understood what you're advocating here. But it
sounds like you're saying "Subversion should do X because corporate
pointy-haired bosses refuse to accept perfectly reasonable existing
alternatives." If so, then I don't think that's going to happen at
all. Subversion is great for many people, but if it's not great for
you, or for your pointy-haired boss, then there are other tools
available.
Subversion does not modify files server-side during commit. It
commits what the client sent. This is considered a Good Thing. If you
want something different committed, make those changes on the client
before committing. A server-side pre-commit hook can enforce your
rules, and in the event of noncompliance with those rules, can print
an error message educating the user how to do the required task on
the client before committing (directing the user to a web page, or a
utility to run, or whatever).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 25 01:02:03 2007