Re: Could not un- and re- link ~/.subversion/config
On Mar 6, 2010, at 16:52, Ryan Schmidt wrote: As someone explained earlier in the thread, a Subversion client recreates the ~/.subversion directory when it runs, so something is causing a Subversion client to run. Oops! Apologies to Alexey for not appreciating the import of what he said on Thursday and thanks to Ryan for the patience in re-highlighting it Which was enough to point me towards the documentation I sought: http://svnbook.red-bean.com/en/1.5/svn.advanced.confarea.html -- Alan P.S. FYI - Something is causing the client to run Yes: my prompt changes the colour of the displayed $PWD depending on svn stat
Re: Could not un- and re- link ~/.subversion/config
On Mar 5, 2010, at 09:21, Alan Brogan wrote: There is no subversion server on those machines, they are used as subversion clients only, so No - subversion was not running at the time A Subversion server process would never do anything with ~/.subversion; only a Subversion client would. If subversion has no such special logic how come it happens on three different machines, on 9 different OSes ? And on all of them happens *only* in the directory ~/.subversion ? As someone explained earlier in the thread, a Subversion client recreates the ~/.subversion directory when it runs, so something is causing a Subversion client to run. The only explanation I can think of is that on all three machines, something you've done is causing a Subversion client to run. A Subversion client does not have any kind of persistent process that stays running, so nothing in Subversion is designed to have the behavior you observe.
Re: Could not un- and re- link ~/.subversion/config
This occurred on various distros of Linux Fedora 8 and 3 CentOS 4, 4.4 and 5 Mandrake 10.2 and 2006.0, 2007.0 OSX Most of these are chroot environments on the same server There is no subversion server on those machines, they are used as subversion clients only, so No - subversion was not running at the time If subversion has no such special logic how come it happens on three different machines, on 9 different OSes ? And on all of them happens *only* in the directory ~/.subversion ? -- Alan - Original Message - From: Tyler Roscoe ty...@cryptio.net To: Alan Brogan abro...@altobridge.com Cc: users@subversion.apache.org Sent: Thursday, 4 March, 2010 15:38:24 GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: Could not un- and re- link ~/.subversion/config On Thu, Mar 04, 2010 at 01:13:49PM +, Alan Brogan wrote: I just lost a few hours trying to do this: $ cd ~/.subversion $ rm -f config $ ln -s /path/to/another/config . The link command kept failing, because File exists WTF ? Turns out I cannot remove ~/.subversion/* in one command, as some other process is protecting them from deletion (but not from editing). Eventually I did figure out the workaround, which is simply to join them into one command $ rm -f config ln -s /path/to/another/config . What OS is this? Was svn running at the time? Sounds like an OS issue. AFAIK Subversion has no special logic to protect its config files. tyler
Re: Could not un- and re- link ~/.subversion/config
It is not the file it is the directory
It happens on multiple different OSs (at least Linux and OSX)
On all of them it happens only in ~/.subversion
--
Alan
- Original Message -
From: Alexey Neyman sti...@att.net
To: users@subversion.apache.org
Cc: Alan Brogan abro...@altobridge.com
Sent: Thursday, 4 March, 2010 17:57:05 GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: Could not un- and re- link ~/.subversion/config
File exists error means that the file is re-created after you delete it
but before 'ln'. The fact that you were able to achieve re-linking by
combining two commands into one (rm ... ln ...) suggests that there is
something invoking 'svn' periodically (cron job?).
As far as I know, Subversion does not have any special logic for config
file protection. However, it does re-create this file with default
settings if it does not find one when 'svn' command is invoked.
Regards,
Alexey.
On Thursday 04 March 2010 05:13:49 am Alan Brogan wrote:
Hello the list,
I just lost a few hours trying to do this:
$ cd ~/.subversion
$ rm -f config
$ ln -s /path/to/another/config .
The link command kept failing, because File exists
WTF ?
Turns out I cannot remove ~/.subversion/* in one command, as some other
process is protecting them from deletion (but not from editing).
Eventually I did figure out the workaround, which is simply to join
them into one command $ rm -f config ln -s /path/to/another/config .
But it was a £*({ing annoying few hours between problem arising and
finding solution (and even more annoying that the solution was so
simple)
I can find no documentation of this feature at
http://svnbook.red-bean.com/en/1.5/
http://subversion.apache.org/faq.html
http://mail-archives.apache.org/mod_mbox/subversion-users/
so, I would like to ask:
a) where is it documented ?
b) can it be extended to other user-configurable directories ?
Thank you for reading this far, and any writing you might be able to
do.
RE: Could not un- and re- link ~/.subversion/config
This occurred on various distros of Linux Fedora 8 and 3 CentOS 4, 4.4 and 5 Mandrake 10.2 and 2006.0, 2007.0 OSX Most of these are chroot environments on the same server There is no subversion server on those machines, they are used as subversion clients only, so No - subversion was not running at the time If subversion has no such special logic how come it happens on three different machines, on 9 different OSes ? And on all of them happens *only* in the directory ~/.subversion ? -- Alan There has to be some app or process that is doing it. Is there a tool that you can monitor file access in Linux. With windows I would use something like Process Monitor from sysinternals. BOb
Re: Could not un- and re- link ~/.subversion/config
On Thu, Mar 04, 2010 at 01:13:49PM +, Alan Brogan wrote: I just lost a few hours trying to do this: $ cd ~/.subversion $ rm -f config $ ln -s /path/to/another/config . The link command kept failing, because File exists WTF ? Turns out I cannot remove ~/.subversion/* in one command, as some other process is protecting them from deletion (but not from editing). Eventually I did figure out the workaround, which is simply to join them into one command $ rm -f config ln -s /path/to/another/config . What OS is this? Was svn running at the time? Sounds like an OS issue. AFAIK Subversion has no special logic to protect its config files. tyler
Re: Could not un- and re- link ~/.subversion/config
File exists error means that the file is re-created after you delete it
but before 'ln'. The fact that you were able to achieve re-linking by
combining two commands into one (rm ... ln ...) suggests that there is
something invoking 'svn' periodically (cron job?).
As far as I know, Subversion does not have any special logic for config
file protection. However, it does re-create this file with default
settings if it does not find one when 'svn' command is invoked.
Regards,
Alexey.
On Thursday 04 March 2010 05:13:49 am Alan Brogan wrote:
Hello the list,
I just lost a few hours trying to do this:
$ cd ~/.subversion
$ rm -f config
$ ln -s /path/to/another/config .
The link command kept failing, because File exists
WTF ?
Turns out I cannot remove ~/.subversion/* in one command, as some other
process is protecting them from deletion (but not from editing).
Eventually I did figure out the workaround, which is simply to join
them into one command $ rm -f config ln -s /path/to/another/config .
But it was a £*({ing annoying few hours between problem arising and
finding solution (and even more annoying that the solution was so
simple)
I can find no documentation of this feature at
http://svnbook.red-bean.com/en/1.5/
http://subversion.apache.org/faq.html
http://mail-archives.apache.org/mod_mbox/subversion-users/
so, I would like to ask:
a) where is it documented ?
b) can it be extended to other user-configurable directories ?
Thank you for reading this far, and any writing you might be able to
do.
