I can't recall will be hooks executed after pure server-side copies (and too lazy to RTFM or check it by hand), but anyway
In hook you have to use svnlook
command with different subcommands
Because hooks are repository-wide your first check will be "Is it commit to /tags
or to another subtree of repository" svnlook dirs-changed
(try command by hand in order to see output for different revisions, in case of good OS svnlook dirs-changed |grep tags
will answer on question)
In case of commit into /tags you have to get and check name of (created) subdir inside /tags
. Here server-side tagging and tagging from WC give (at least for me) different results
svnlook dirs-changed
Server-side tagging
>svnlook dirs-changed z:\repo
tags/
WC-tagging
>svnlook dirs-changed z:\repo
tags/
tags/App_Main_1.0.0_2/
tags/App_Main_1.0.0_2/1/
tags/App_Main_1.0.0_2/1/2/
svnlook changed
Server-side tagging
>svnlook changed z:\repo
A tags/App_Main_1.0.0_1/
WC-tagging
>svnlook changed z:\repo
A tags/App_Main_1.0.0_2/
U tags/App_Main_1.0.0_2/1/2/c.txt
U tags/App_Main_1.0.0_2/1/b.txt
U tags/App_Main_1.0.0_2/a.txt
and such noticeable differences are observed under identical tree within tags
>svnlook tree z:\repo
...
tags/
App_Main_1.0.0_1/
1/
2/
c.txt
b.txt
a.txt
App_Main_1.0.0_2/
1/
2/
c.txt
b.txt
a.txt
...
I think, instead of adding some logic inside hook (but you may try to use svnlook changed | head -n 1
for both types of tags: catch only first line of output with name of created tag in it), you have to enforce strict tagging-policy "Tag only trunk's HEAD (use server-side copy)".
In this case test will be shorter and reabable, something like svnlook changed | grep -q -E REGEXP
(there building REGEXP for testing convention <application>_<project>_<version>_<iteration>
is your task) plus|minus some details