[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help with files changed outside of svn

From: David Chapman <dcchapman_at_acm.org>
Date: Mon, 28 Feb 2011 08:39:57 -0800

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_at_acm.org
     Chapman Consulting -- San Jose, CA
Received on 2011-02-28 17:41:00 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.