WysG,
I am going to building something similar for a repo that usesautoversioning, which will have a *very* high frequency of commits,and a requirement that the WC the web is being served off of reflectthe change *very* quickly. Some thoughts on performance and otherissues:
1) Instead of "svn up"ing the *entire* WC, intelligently use svnlookto determine the common parent directory of the changes and run "svnup" on that specific directory in the WC. In my case, each commitwill only be one file/dir change at a time, so I can also use the--non-recursive option.
2) As Branko suggests, definitley make it asynchronous -- fire off thesvn up process and leave, not waiting for it to finish.
3) You might also want to use a named mutex to prevent multipleupdates from running at the same time. I'm taking a stab that SVNwouldn't like two svn up processes updating the same tree at the sametime (think two commits that occur closer together than it takes svnup to run). if it was to two different places in the WC it wouldprobably be OK, but is it really worth figuring that out? -- hmmm ...maybe derive the mutex name from the parent directory ... intriguing
4) For autoversioning, some ops that generate several commits (likecopying a new folder with several files into the tree), I think thiswould be bad to run an svn up each time. My thought is to have my new(unnamed) little utility actually wait 1-2 seconds once it gets themutex before running the update. A record would be kept in a txt file(sep. from the WC) of the last time an update was kicked off for adirectory. If I'm kicking off most post-commit for commit 25 ofadding a dir, I can see if the last update for the dir was *after* thetime of commit 25. So for 25 rapid commits, I may only do 1-2updates.
-Kyle
> Date: Sun, 24 Apr 2005 00:14:42 +0200>From: Branko Čibej <brane@xbc.nu>> Content-Type: text/plain; charset=UTF-8; format=flowed> Subject: Windows Hook Script - Automatic web publishing> > > WysG wrote:> > >One of the reason why we chose Subversion was that it's blazing fast and> >light. I already thought of this way but :> >1. When you do a commit, the hook have to update the complete working> >copy on the server, wich I think will slow things down.> > > >> You must definitely do these updates asynhchronously, that is, not make > the svn server wait for the updates to complete.> > >3. I want to have trunk and tags for each apps.> > > >> Nothing's stopping you from doing that.> > -- Brane
Received on Sun Apr 24 15:01:10 2005