"Durfee, Bernard" <Bernard.Durfee@suny.edu> wrote on 06/23/2005 10:07:11
> > Second, while I understand the reasons given, I'm not sure I
> > agree. Is it Subversion's job to prevent anyone from
> > engaging in activities which are forbidden in select
> > industries? Has the Subversion team, at some point, decided
> > that it would be wrong to provide a means to engage in
> > activities which the industry at large does not acknowledge
> > as "best practice"?
> > It seems to me that the Subversion developers have decided to
> > lock a door for reasons which are primarily non-technical,
> > and it seems to me that those whose industries do not
> > prohibit automatic code alteration should be allowed to use
> > that door if they choose to do so.
> Exactly. Although I am starting to see how this could truly be a
> complicated technical proposal, but the discussion(s) on the subject
> always seem to be tainted by philosophical rancor.
> > I am under the impression that a pre-commit hook is not
> > currently permitted to modify the data being committed. This
> > is the locked door to which I am referring, and unlocking
> > this door would solve Bernard's issue. Nobody is forcing
> > anyone else to walk through the unlocked door.
> > So, I now ask of the Subversion developers: are there
> > *technical* reasons which would inhibit permitting a
> > pre-commit hook to modify the data being committed?
> Right, that is the proper question that needs to be explored.
It has been. This message that you are replying to was specifically
responded to yesterday. See:
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 23 16:26:55 2005