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
Received on Thu Oct 25 02:03:05 2007