On Feb 28, 2011, at 10:13, Christopher D Haakinson wrote: > I mean that I have a working copy of my project under: > /svn/hooks > > This folder gets automatically updated with svn update on every commit with a > post-commit hook > This folder also is "live", meaning that the files here are in use at all > times, so nobody will be using this "working copy" as their development copy, > it's just there to receive all the newest changes. > > The scenario I want to test and know how to handle is when a file in > /svn/hooks gets changed outside of svn and these changes never get commited > into svn. > > I understand what svn is and is not, but the files I will have inside svn > will also be available and writable on a network, so I need to know how to > handle files that get changed inside my live working folder outside of svn.
If that's how you have Subversion set up (a directory containing the hooks, and it is a working copy of a repository, and it is automatically updated in a post-commit hook), then the post-commit hook really must be the only thing modifying it. Nobody should have the ability to make changes there manually. All changes to this directory should occur by making the change in a working copy the user has checked out, then committing the change. > Also is there a way to change what gets written to a file when this occurs? > All my scripts get corrupted because of the >>>>>>> and I'd like to at least > put a # in front so that it's a commented line and doesn't affect the > execution... It is up to the user to resolve the merge conflict (i.e. remove those lines and retain the correct merged version of the code) before committing the changes, before the server can "svn update" its private working copy and try to run the scripts there.
