SteveKing <steveking@gmx.ch> writes:
> kfogel@collab.net wrote:
> > Does this really solve anything?
> > If the substitution does not happen while the log message is being
> > written, then the user never sees the final version of their log
> > message (and it's highly unlikely, I would think, that an unadorned
> > list of files is what anyone wants in a log message, since that
> > duplicates information already stored by the repository).
> > In other words, if the user can't use the list of files at the time
> > they're writing the log message (with or without template), then what
> > good is the substitution variable?
>
> You're right. That's why I suggested to not use a runtime param for
> the hook script but a setting in the working copy (e.g. property,
> server side configuration, inherited property, ...) which only states
> if the hook script
> - has to be called (if not, then the template is static and should
> also be stored in the wc)
> - has to be called with the complete file list (i.e. TSVN would have
> to prevent the user from entering a log message until all files which
> get committed are known)
> - has to be called, but without a file list
Sorry, I'm still not seeing what exactly this property would do, or
rather, how it would help.
Again, if TSVN must discover state (e.g., a property) in the working
copy before it knows what to do for the log message interface, then it
cannot present the log message editing window early the way it does
now.
This is because TSVN has to *find* that property first, and (in the
extreme case) a full wc crawl may be necessary to do that. Remember
that it may find multiple properties, and have to make some sort of
resolution decision. So even if it finds one property, it has to keep
crawling, unless there's a highest-always-wins algorithm.
But I think this is all way, waaaay to much complexity for what should
be a simple feature. Of course, TSVN can implement all of the above
itself, requiring no special support from Subversion. I think it
would not be good if TSVN did that, but I can't stop it from happening
:-). All I can do is point out that there's no compelling argument
for special support in SVN itself for any of this.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 18:30:09 2005