You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kenneth Porter <sh...@sewingwitch.com> on 2007/10/23 11:50:41 UTC
svn:eol-style and other text transforms on commit
Where is the eol conversion done for svn:eol-style? Client or server? What
is the reasoning behind not providing hooks for other text transformations
in this path?
For example, I can see value in reindentation of XML and C/C++ on commit,
where adding and removing white space does not change the syntax.
Are there wrappers for Subversion that provide this kind of transformation?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn:eol-style and other text transforms on commit
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
>
> 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.
Merely an example of an unfortunate situation.
>
> 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.
Not exactly - in it is pointy-haired developers who want the feature in
my example, which was presented to illustrate the weirdness out here.
> 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).
I should not have stated my tangential request for feature
open-mindedness in this thread, because it is clearly being confused
with the original question. I agree with you. I was simply concerned
with this statement:
>Why not just make the developer responsible for doing this himself
>(still reject the commit via hook if it doesn't pass tests)?
Because I see it frequently as a resolution to feature requests. I just
want that to be the response of last resort, not first. The
server-maintained valid property list question is an example of such a
useful feature.
--
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
Re: svn:eol-style and other text transforms on commit
Posted by Wayne Cannon <wc...@sonic.net>.
Ryan,
I am very comfortable with the Subversion approach, and feel that it can
handle the issues raised here as easily as any other, albeit possibly
not in exactly the manner suggested. However, as a long-time user of
ClearCase (and of several other packages), I think the issues raised
here are very valid and not relegated to just paranoid, "pointy-haired",
bosses.
On large, geographically dispersed teams, and over a significant period
of time almost every project experiences cases of designers who are less
than optimally experienced making modifications, it is reality that you
cannot simply trust even the most well-meaning developer to be
"responsible for doing this himself" because he may not have the
experience with the file or system to do so. I would hate to see
someone drop an excellent product like Subversion for [enter your
favorite administratively-heavy alternative here] for such real-world
situations.
I would suggest a property containing "interested" parties, and possibly
a "mentor" property containing appropriate usernames or e-mail
addresses, combined with hooks, as you suggest. The "mentor" [I don't
like the term "owner" because of the days of "ego-less programming"]
serves as a reference to the person who is responsible to be aware of
what is happening with the file, its history, its sensitivities, and
thoughts about its future. The "interested" parties can be notified
whenever there are certain types of activity on the file. This is all
supported by Subversion, its hooks, and its properties today. For the
really paranoid [I don't want to go back], "locking" can be required for
anyone to commit a modified file, and the "mentor" can be notified
whenever a file is locked (this is somewhat akin to a ClearCase
notification whenever a file is "checked out").
--Wayne Cannon
Ryan Schmidt wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:eol-style and other text transforms on commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
RE: Re: svn:eol-style and other text transforms on commit
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
>
> On 10/23/07, Kenneth Porter <sh...@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
Re: svn:eol-style and other text transforms on commit
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Tuesday, October 23, 2007 1:49 PM -0400 Andy Levy <an...@gmail.com>
wrote:
> 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 don't think we disagree. I was proposing that the "developer do it
himself" part be a client-side hook, but it could also be a wrapper script
that runs the hook and then invokes "svn commit". The client chooses to run
the program, not the server. No hook is downloaded as part of the commit or
checkout process.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:eol-style and other text transforms on commit
Posted by Andy Levy <an...@gmail.com>.
On 10/23/07, Kenneth Porter <sh...@sewingwitch.com> wrote:
> On Tuesday, October 23, 2007 2:16 PM +0200 Erik Huelsmann
> <eh...@gmail.com> wrote:
>
> > (Server regulated) hooks on the client, built into subversion, would
> > (a) open gaping security holes and (b) significantly raise the
> > dependencies requirements (which scripting environment? Python? On
> > Windows it's not 'the default'...)
>
> 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)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:eol-style and other text transforms on commit
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Tuesday, October 23, 2007 2:16 PM +0200 Erik Huelsmann
<eh...@gmail.com> wrote:
> (Server regulated) hooks on the client, built into subversion, would
> (a) open gaping security holes and (b) significantly raise the
> dependencies requirements (which scripting environment? Python? On
> Windows it's not 'the default'...)
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.
>> Are there wrappers for Subversion that provide this kind of
>> transformation?
>
> No, but you can easily write your own...
I was just wondering if one of the existing "wrappers" (like Tortoise or
Ankh) had this feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:eol-style and other text transforms on commit
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/23/07, Kenneth Porter <sh...@sewingwitch.com> wrote:
> Where is the eol conversion done for svn:eol-style? Client or server?
Client.
> What
> is the reasoning behind not providing hooks for other text transformations
> in this path?
(Server regulated) hooks on the client, built into subversion, would
(a) open gaping security holes and (b) significantly raise the
dependencies requirements (which scripting environment? Python? On
Windows it's not 'the default'...)
> For example, I can see value in reindentation of XML and C/C++ on commit,
> where adding and removing white space does not change the syntax.
>
> Are there wrappers for Subversion that provide this kind of transformation?
No, but you can easily write your own...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org