Frank,
Frank Gruman wrote:
> Rodrigo,
>
> I believe in my last response to your thread I had mentioned something
> like that. Take the current post-commit hook and call an external
> program from there. If you want to, set STDOUT to report back to the
> user that the formatter has run, and they will have to update their
> working copy to get the latest file change.
AFAIK, that does not work - anything that a hook program/script writes
to STDOUT is shown by the client to the user *only* if the hook *also
reports failure*, i.e. returns non-zero. That's something you don't want
because you want to *accept* the commit instead of rejecting it.
Worse, since the post-commit hook *cannot* report failure (I mean, it
is ignored if the hook does), a post-commit hook is unable to transport
any information to the subversion user - except by sending a mail to
him/her.
> In the external process, fetch the files into their own separate working
> copy and update them approptiately. Then do a new commit from there.
> Have this separate process (and commits) run as a separate user so you
> know that the code format process has done work to your files.
>
> And to everyone else - I agree with Karl on a couple of items in his post.
> 1. It is not the job of the open source developers to bow to every
> whim requested by a small segment of the user community. As such, the
> current development core already has to decide what types of features to
> put into the code that will affect a _MUCH_ larger group of people than
> something like this.
> 2. The term 'simple' is a very subjective one. When I sit here and
> type out a rough scope of work in 4 sentences does not mean that
> actually writing the code, testing it, fixing it, and then wanting to be
> able to support that code for the masses on systems outside of my own is
> going to be simple.
>
> So whether it seems that he was a little short on temper with some of
> you, the fact of the matter is that the core developers of the current
> code base are not willing to push other things aside to consider how to
> implement this pet project. What Karl was saying was that if there are
> other developers who would like this functionality and were willing to
> spend some time writing a patch, they might be willing to accept
> something. Either way - that developer could then support their own
> little modified subversion system. The beauty of open source...
>
> just my 2 cents.
>
> Regards,
> Frank
After having read that, I still would like to make a feature request:
Let the svn client show the user everything that a hook wrote to STDOUT,
independently of whether the commit is or will be accepted or rejected.
Could that break anything?
Would it be difficult?
(Serious questions!)
I considered to ask for contributor status, but I have rather little
spare time available and my impression is that reading the coding
rules would take me longer that to create a patch to get this feature,
after finding the right places to patch, that is... :-)
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 16:22:51 2005