> > I saw a big warning at http://svnbook.red-bean.com/en/1.1/ch05s02.html (subversion 1.1) about
> > modifying a transaction using hook scripts. The 1.1 version of the book specifically mentions
> > svn:eol-style and svn:mime-type. This is understandable.
> > Version 1.4 is more explicit and talks about the client-side cache which might become stale. Is
> > this a problem for *all* transaction modifications? Does it apply to svn-keywords?
> Yes, it's a problem for all transaction modifications: all file and
> directory properties are cached on the client. The only server side
> commit-time modification which is relatively safe (for now) is to
> change revision properties. (But those don't have any relation with
> > Is there any other way to automatically set properties on the server-side that I'm not aware of?
> Yes, in a followup commit following the commit that didn't set the
> correct keywords.
It would be nice if this could be assured to be the very next commit
and that the change could be seen as a commit correction by committer
immediately (an automatic update of those paths only). Essentially
have a committing hook (potentially a new hook that occurs during
commit after pre-commit has approved the commit attempt) that may or
may not append a commit alterations revision and attach this in the
I'm aware this would violate the policy of a single command only
sending changes one direction but it seems to me that, being a
centralised VCS, it doesn't violate the clients understanding of
current state of those files/folders as long as the hook is only
allowed to change paths that were changed in the original commit.
Doing it this way ensures there can be no intervening commit and
therefore never a conflict case for this hook generated commit.
NB: The corrective commit would not be allowed to make tree
modifications (un-deleting, adding, copying or moving files/folders)
as there's no assurance that the clients working copy has the relevent
paths up to date and this could produce side-effects outside the scope
of the original commit.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-31 21:29:45 CET