I would agree with you 100%; however, in this particular circumstance, I am not changing any governing settings of the working copy. All I am doing is adding additional directives for future commits.
In particular, by way of "post-commit", instead of just updating the WC it should be possible to add the extra non-versioned files into the queue. So, when the next commit occurs (whenever that is) it would already know that file "abc.txt" is to be added (from non-vers'd to vers'd) into the repository.
Those commands do not interfere with the current transaction; they simply prepare for the next.
Because autoversioning+locking/unlocking will be fixed in SVN 1.2, I have opted for a scheduled task that does the same thing. It would have been nicer, however, to simply have the start/pre/post-commit hooks make sure the adding/removing of files happened only on-demand and not on-schedule.
From: Ryan Schmidt [mailto:email@example.com]
Sent: Sat 1/22/2005 11:21 AM
To: Dassi, Nasser
Cc: Subversion List
Subject: Re: Commit hooks malfunctioning... Bug?!
On 21.01.2005, at 02:57, Dassi, Nasser wrote:
> 1. svn status > random.txt (Works)
> 2. cscript blah.vbs (Runs -> creates a file, random1.txt)
> 3. svn add --targets random1.txt (Fails)
> 4. del random.txt (Works)
> 5. del random1.txt (Works)
On 21.01.2005, at 21:42, Dassi, Nasser wrote:
> The "bug?" may just be my misunderstanding; here it is, in the form of
> question for the Subversion Dev Team to give a crack at it:
> Q: Is it possible for a HOOK (start/pre/post-commit) to access WC
> Add/Delete commands (via "svn add" and "svn delete")?
> Bkgnd: From this thread conversation with Simon Martel, it appears that
> a HOOK *cannot* modify the working copy from which it was instantiated.
> Running hook scripts *outside* of a WC "svn commit" command is not a
> problem; but based on the WC's "commit" it seems to not execute
> ADD/DELETE commands. "svn up" works fine from within a hook script,
Yes, that's what I understand from reading The Book:
> Do not attempt to modify the transaction using hook scripts. A common
> example of this would be to automatically set properties such as
> svn:eol-style or svn:mime-type during the commit. While this might
> seem like a good idea, it causes problems. The main problem is that
> the client does not know about the change made by the hook script,
> and there is no way to inform the client that it is out-of-date. This
> inconsistency can lead to surprising and unexpected behavior.
> Instead of attempting to modify the transaction, it is much better to
> check the transaction in the pre-commit hook and reject the commit
> if it does not meet the desired requirements.
Received on Sat Jan 22 18:34:13 2005