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.
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
Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
>
>
>Hey, nice idea, so this solution would make an _additional_ commit when
>someone commits. Thatīs two commits per commit =o)
>
>Combining this idea of yours to the previous idea of checking if the files
>are already processed we can make this second commit optional.
>
>Iīm starting to like this!
>
>Rodrigo
>
>
>
>
>
>
>>-----Original Message-----
>>From: Durfee, Bernard [mailto:Bernard.Durfee@suny.edu]
>>Sent: 22. juni 2005 20:15
>>To: users@subversion.tigris.org
>>Subject: RE: Post Commit Code Formatting
>>
>>Again, it seems like it would very simple for CVS/Subversion to supply a
>>'hook' for people to run scripts to modify incoming files and transmit
>>those modifications back to the client, just as both of those systems
>>already do with keyword expansion.
>>
>>Bernie
>>
>>
>
>You don't need a special hook for this.
>
>1. In a post-commit hook, put a job in some queue.
>2. Have a service process the jobs in the queue. Checkout the branch that
>was changed, format the changed files, and commit.
>
>You have to lock the changed files and verify in a pre-commit hook that a
>locked file is not committed to (to avoid merge conflicts).
>
>Casper
>
>
>
>---------------------------------------------------------------------
>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 Wed Jun 22 21:50:45 2005