subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chapman <dcchap...@acm.org>
Subject Re: Help with files changed outside of svn
Date Mon, 28 Feb 2011 16:39:57 GMT
On 2/28/2011 8:13 AM, 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.
>

This is asking for trouble.  You want your Subversion repository to be 
up and running at all times.  Version control systems cannot prevent all 
merge conflicts, so your repository could very well go down whenever a 
conflict occurs.  The repository control directories (such as the hooks 
directory) should be tightly controlled, not open to any and all 
modifications, and certainly not changing on the fly.

As Andy Levy said, Subversion does not care how the files are modified.  
It is a lightweight system, meaning that it doesn't run unless you tell 
it to.  And so it doesn't know that files in a working copy are modified 
until you tell it.


>
> 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...
>

This particular conflict might not have affected execution, but you 
can't guarantee this will always occur.  What if you have a conflict of 
the form: "exit 0" vs. "exit 1"?  How is Subversion supposed to know 
which is correct?  This is why conflict resolution is manual.  Trust me 
- you really, really, want to have conflicts be obvious and cause 
problems; you don't want them hidden.

If you really want to have your repository's hooks directory updated 
through Subversion (which I do not recommend), make the directory 
writable only by the process that is running Subversion so that only the 
post-commit hook script can change it.  Don't *ever* allow users to 
modify files in that directory.

-- 
     David Chapman         dcchapman@acm.org
     Chapman Consulting -- San Jose, CA


Mime
View raw message