Using hotcopy inn post-commit hook

Hi, I would like to execute instant copy of the commited revisions to another backup svn repository. To achieve this, I want to use 'svnadmin hotcopy', activated by post-commit hook. So, here is my idea: Both servers are in same network and the main server can see the filesystem where the backup repository reside. So when a commit is finished in the main repository, post-commit hook activates 'svnadmin hotcopy path/to/mainrepository path/to/backuprepository --incremental'. I have some questions about that scenario. Is it good idea to use hotcopy? Is it possible to be performed new commit until post-commit hook is finished? What would happen while a hotcopy operation is in progress next commit activates new hotcopy? Should post-commit hook have to make some locks so as the hotcopy opreations would not be preempted? Regards, Ivan

Last updated 2 years ago

My system is windows based (windows 2016) Unfortunately, the script post-commit.bat cannot see destination path. svnadmin hotcopy command is [CODE]svnadmin hotcopy e:\data\repos\thisrepo\svn t:\data\repos\thisrepo\svn --incremental[/CODE] [CODE]t:[/CODE] is in the destination machine. The script while executed as hook fpom SVN does not see the destination path. However when executed from console, it proceeds successfully. As I understood this is a common problem, I did google search, but did not found solution. This why I am asking here, if someone had encountered such problem and found soulution to share that solution. Ivan

One of the strengths and weaknesses of Windows it "hard locking" of files. If you use "svnadmin hotcopy" during normal operations then repository files will end up getting locked and will prevent concurrent modification operations. For instance, 2 commits, 1 right after the other will likely end up with the 2nd commit aborting due to the ongoing "svnadmin hotcopy". You might be able to prevent this by having a pre-commit hook that makes sure that hotcopy is not running, but that's still a race condition unless done in a very complicated manner. In general, this is unlikely to be a good idea, at least for a normal production machine. For non-windows it should work "just fine".

[QUOTE=DougR;n80348]One of the strengths and weaknesses of Windows it "hard locking" of files. If you use "svnadminhotcopy" during normal operations then repository files will end up getting locked and will prevent concurrent modification operations. For instance, 2 commits, 1 right after the other will likely end up with the 2nd commit aborting due to the ongoing "svnadminhotcopy". You might be able to prevent this by having a pre-commit hook that makes sure that hotcopy is not running, but that's still a race condition unless done in a very complicated manner. In general, this is unlikely to be a good idea, at least for a normal production machine. For non-windows it should work "just fine".[/QUOTE] I did some research and saw that this is bad approach, not depending on OS. If some big commit is executed, with many files/megabytes, then the commit will finish when the hotcopy finishes. This would be not acceptable from the end user. He/She will wait after the files were sent to the server for hotcopy without any indication and may be for 5-10-30 seconds or more. This is not acceptable. I decided not to implement that idea.

Note: you can always drop the "svn hotcopy" in the "background" and let the hook complete. In that case you would need to program some serialization (e.g. lock a guard file). And, in general, an incremental, even of a large file, should go quickly assuming that the hotcopy was doing so "locally" (if to another server then, you're right, it's going to take a while). Lot of options available. Still, more trouble on Windows due to hard file locking. Cheers.