On Mon, Aug 1, 2011 at 12:34 AM, Andy Canfield <andy.canfield_at_pimco.mobi> wrote:
>> Cool, but be careful with those. If you have SELinux enabled and the
>> repositories are elsewhere, for example on a separate disk for bulky
>> repositories, you may need to review your SELinux settings to enable
>> httpd access to the separate location.
>>
>> And oh, dear lord, if someone starts putting symlinks in the
>> reponame/conf/ or reponame/hooks/, can you have adventures. (See
>>
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=767435,
>> which was only recently fixed and the fix isn't in most public
>> Subversion releases.)
>>
> SUNNY BEACH!
I just showed this to my wife. She *laughed*. Thanks, this one made my day.
> If it's a hard link, editing the file will break the replication. If it's a
> symbolic link, a hotcopy will drop it. If the symbolic link were copied as a
> symlink, I need to link it to "../../conf/*" instead of "/Subversion/conf/*"
> so that my copied symbolic links point into the backup, not into the
> original.
Yup. This used to be a lot worse: the older versions of the svnadmin
hotcopy command simply silently passed over symlinks. It's due to a
fundamental flaw in a lot of modern C++ programming: people write
"case" statements and neglect to include a default case that say
s"what the hell was that? I don't recognize it, I'd better complain".
Unfortunately,l the filetype handling of svnadmin hotcopy is an
example of this. While it now handles symlinks, it still blithely
ignores block devices and raw devices and pipes. (I verified that last
week with 1.6.15, haven't tried it with the 1.7.0 beta tags.)
> So I have changed my create.php to relative, not abosolute, symlinks, and
> edited my SVNBackup.sh script to 'cp -p -d' the symlinks from the master to
> the backup.
>
> Thanks for the heads-up.
No problem. I got bit hard by this a few years back.
Received on 2011-08-01 07:53:16 CEST