Hmm, not sure I agree with Nick re tag being similar to a branch. A tag is just a marker
Trunk would be the main body of development, originating from the start of the project until the present.
Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
Tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.
In open source projects, major branches that are not accepted into the trunk by the project stakeholders can become the bases for forks -- e.g., totally separate projects that share a common origin with other source code.
The branch and tag subtrees are distinguished from the trunk in the following ways:
Subversion allows sysadmins to create hook scripts which are triggered for execution when certain events occur; for instance, committing a change to the repository. It is very common for a typical Subversion repository implementation to treat any path containing "/tag/" to be write-protected after creation; the net result is that tags, once created, are immutable (at least to "ordinary" users). This is done via the hook scripts, which enforce the immutability by preventing further changes if tag is a parent node of the changed object.
Subversion also has added features, since version 1.5, relating to "branch merge tracking" so that changes committed to a branch can be merged back into the trunk with support for incremental, "smart" merging.
You might want to check this answer to see if it helps you solve your problem:
If that doesn't help, you should try logging to a file. Since it works fine when you use SVN, but fails for Trac, it's probably some config error. Once you can actually view the error message, it will be easier to fix. For starters try changing to:
Python "%~dp0\trac-post-commit-hook" -p "%TRAC_ENV%" -r "%REV%" 2>&1 1>>c:\temp\trachook.log
in your cmd file. This should send both stdout and stderr messages to the \temp\trachook.log file.
EDIT: Sorry, missed the error message you posted already. Looks like it's not getting the right options.project
and it might be set to None when it should be set from TRAC_ENV
from the -p
option.
Are you sure you're running it with that option after you rename it to .py and run it? If so, try changing that file and logging the value of options.project
after the arguments have been parsed. Try to track down why it's not being set.
EDIT: By the way, the error line:
File "trac-post-commit-hook.py", line 104, in <module>
os.environ{'PYTHON_EGG_CACHE'] = os.path.join(options.project, '.egg-cache')
I don't see a reference to this in the link to the post-commit-hook. Did you add this? Or is the link wrong? Also, there's a syntax error in that line: the curly brace '{' should be a square brace '['. But I think the error actually happens before that, in the os.path.join (options.project is None). Try putting a line before that one:
print 'options.project is set to: ', options.project
and see what the output is.
Best Answer
First of all, all hooks are executed on the SERVER and not on the various client machines. Is that
C:\mypath\myworkingcopy
on the server? If not, it's not going to get updated.Second of all, it's bad form to do anything in a hook that might take too much time. If your hook needs something more than
svnlook
, chances are you're doing it wrong. For example, how long could it take to update that working copy? 10 seconds? 30 seconds? a minute? That's the added time a developer has to sit and wait for their Subversion commit to complete.It is much, much better to use something that can respond to commit events and have that do things like working copy updates or deployments to web servers outside of a post-commit hook. I highly recommend Jenkins for this job. Jenkins has several nice features:
Now back to your question:
First make sure the hook is running. Add to the bottom of the batch script this one line:
That will make Subversion think the post-commit hook has failed and you should get an error message on commit. If not, your post-commit script isn't running. Make sure the script is executable by the account that's running the Subversion server.
If you do get an error message, the script is running. However, the svn command may not be returning an error that's getting picked up by the post-commit process. I normally don't recommend writing hooks in Windows batch programming language because of its limitations. Use Python or Perl or PowerShell. These are better at detecting error conditions and you can exit out of your script when detected.
Then again, things are working perfectly, but you're looking at the wrong working copy (the one on your machine and not the one on the server). When you run hooks outside of the subversion server for testing, run them on the server as the Subversion user running the server process.
Try these things and see if that corrects your problem.
Additional Comments
I created a repository with
svnadmin create
and ran it usingsvnserve
. I updatedsvnserve.conf
to allow me to checkout and commit code.I went into the
hooks
directory, renamedpre-commit.tmpl
topre-commit.bat
and set it as:When I attempted to commit my changes, I got:
The hook is supposed to remove the environment (including the PATH), but I guess that's only on Unix and not Windows. You can see
PATHEXT
defined.I then renamed
pre-commit.bat
topre-commit.tmpl
and created a post-commit.bat` that looks like this:During a commit, I got the following:
It looks like everything is working as planned. I'm not using VisualSVN, and I'm not running as a service. I wonder if there might be an issue with your
PATHEXT
environment variable.Maybe take a look how it is set on your account that's running the Subversion server and see if
.BAT
is in there.I can't think of anything else right off hand.