Dirk Schenkewitz <schenkewitz@docomolab-euro.com> wrote on 06/23/2005
11:10:13 AM:
> > The reason's for this are *entirely* technical. If you alter the
content
> > of the file before it is committed, the WC of the user that committed
the
> > file will not contain the same changes, but the WC will think it is up
to
> > date. An svn up would not bring down any changes, and subsequent
commits
> > to the file would likely fail because the delta's would not line up (I
am
> > only speculating on this part).
>
> IMHO that's the killer argument against doing any change to committed
stuff
> without doing another commit. If a post-commit hook would create another
> commit (as already described), I guess it wouldn't be much worse than
> rejecting the commit and tell the user to fix up the formatting first.
>
> :-) Hmm, I'm getting ideas :-)
>
> If a user-commit would always be followed by an automatic commit that
does
> nothing but changing the formatting, then both "versions of a commit"
are
> always available - that means, if a user doesn't like the auto-formatted
> style, he/she could checkout or update to HEAD-1 to get the "original
> version" and work on that.
And if the user submits the code with the correct format, then the second
commit wouldn't even happen.
> > To allow the hook to alter the transaction would require significantly
> > redesigning the commit process so that the changes could be sent back
down
> > from the server to the client.
>
> That would be like forcing a sort of update on the user, isn't it?
> I wouldn't like that, at least not without being asked.
Not only would it be an update, but the client would have to be
restructured to wait for that update before it told the WC it was at that
revision. What does that do to atomic commits? Does the commit call the
hook, re-examine the transaction for changes and then send the updates
back to the client, wait for the client to acknowledge, and then actually
perform the commit? When it sends the updates back, does it have to send
full texts, or is it a new delta? Can the hook add/delete/copy/move files
or just update? What about properties?
There are a lot of icky possibilities here. From a "having to design
this" perspective.
> > It would be a hefty amount of work for a
> > feature that is dubious at best, and can be implemented in much saner
> > ways.
>
> I Agree. But I believe that it's good to discuss it anyway (without the
> personal parts of course), to have the pro's and con's thrown in one's
> face :-)
Of course. The whole point in this particular instance was the way the
request was presented.
> Btw, if this comes up over and over, wouldn't that qualify it for a FAQ?
> Perhaps a special ML-FAQ, having on top:
>
> "Before you bring up a topic on the ML, please search here for hints
about
> it - maybe your question is already answered."
>
> and then
>
> "Q328641287: Subversion cannot do Post Commit Code Formatting, why?"
> followd by "This Question is a duplicate or similar to Q16538, see
there"
I doubt many people read the FAQ's, but nonetheless, absolutely. If for
no other reason then when you are tempted to give a frustrated answer to
the same question, you can instead just send a URL and bite your tongue.
Subversion is currently looking for a person (not product) to fill the
role of an FAQ manager.
http://subversion.tigris.org/project_tasks.html
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 17:34:09 2005