Re: cannot delete directory with deleted zombie-locked file

[Philip Martin]

cpengr  writes:

> 1. How did this happen?

It could be:

  https://issues.apache.org/jira/browse/SVN-2507

> 2. How can I delete this directory tree?

Use

  svn unlock URL

rather than

  svn unlock PATH


> 3. Do I need to take further action to report the issue, so the developers
> can prevent this trouble for others in the future?

No.

-- 
Philip Martin
WANdisco

Re: cannot delete directory with deleted zombie-locked file

[Daniel Shahaf]

cpengr wrote on Tue, Feb 09, 2016 at 18:17:36 -0500:
> Questions:
> 2. How can I delete this directory tree?

Try 'svn unlock --force' and 'svn rm' with URL arguments, e.g., 

svn unlock --force svn://svn/junk
svn rm svn://svn/junk

> 1. How did this happen?
> 3. Do I need to take further action to report the issue, so the developers
> can prevent this trouble for others in the future?

I can't find it right now, but I think we already have an issue filed
for this problem; see:

https://subversion.apache.org/reporting-issues.html#queries

Cheers,

Daniel

Apache 2.4, Worker MPM, SVN 1.7.20, MOD_DAV_SVN and Post-Commit Hooks

[Steffen Moser]

Hi all,

we have an Oracle Solaris 11.3 x86_64-based server with the following 
components:

 - Apache 2.4.12(-0.175.3.0.0.30.0)
 - SVN 1.7.20(-5.12.0.0.0.91.0)

SVN is connected to Apache with "mod_dav_svn" and I have a repository with a 
"post-commit" hook. 

The Apache package is the original package with comes with Solaris 11.3, while 
SVN is compiled on a Solaris build host by ourselves because Oracle missed to 
include 64 bit binaries in Solaris 11.3 and they are needed when one tries to 
include "mod_dav_svn.so" into a 64 bit version of the Apache web server, of 
course. But this shouldn't be the cause on any problem. 

My problem is: The whole configuration is running absolutely fine as long as 
Apache is configured in the "prefork" MPM. As soon as I configure it to the 
"worker" mode (i.e. multi-threaded mode), the Apache process hangs whenever I 
want so commit a file to one of my repositories, but this problem only occurs 
as long as a "post-commit" hook is defined. Maybe other kinds of hooks are 
affected as well, I haven't tried them, yet. 

It seems for my that "mod_dav_svn" itself might be able to work in a 
multi-threaded environment, but the connection to the hooks doesn't. 

I've used the tool "truss" to capture the syscalls which are called by Apache 
in both situations:

a) MPM Prefork

 | 25769:  
stat("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 
0x80F48B165B40) = 0
 | 25769:  open("/dev/null", O_WRONLY|O_CLOEXEC)   = 24
 | 25769:  fcntl(24, F_DUPFD, 0x)  = 25
 | 25769:  fcntl(25, F_GETFD, 0x7FFA9304E144)  = 0
 | 25769:  fcntl(25, F_SETFD, 0x)  = 0
 | 25769:  pipe()  = 26 [27]
 | 25769:  fcntl(26, F_GETFD, 0x99427F850) = 0
 | 25769:  fcntl(26, F_SETFD, 0x0001)  = 0
 | 25769:  forkx(0)= 25782
 | 25769:  lwp_sigmask(SIG_SETMASK, 0x, 0x, 0x, 
0x) = 0xFFBFFEFF [0x]
 | 25769:  close(25)   = 0
 | 25769:  close(27)   = 0
 | 25782:  forkx() (returning as child ...)= 25769
 | 25782:  getpid()= 25782 [25769]
 | 25782:  munmap(0x7FFA91DC, 262144)  = 0
 | 25782:  lwp_self()  = 1
 | 25782:  lwp_sigmask(SIG_SETMASK, 0x, 0x, 0x, 
0x) = 0xFFBFFEFF [0x]
 | 25782:  close(23)   = 0
 | 25782:  close(22)   = 0
 | 25782:  close(21)   = 0
 | 25782:  schedctl()  = 0x7FFA92243000
 | 25782:  munmap(0x7FFA91A8, 288862)  = 0
 | 25782:  munmap(0x7FFA91AD7000, 7936)= 0
 | 25782:  munmap(0x7FFA91A6, 29785)   = 0
 | 25782:  munmap(0x7FFA91A78000, 2792)= 0
 | 25782:  close(5)= 0
 | 25782:  close(3)= 0
 | 25782:  close(6)= 0
 | 25782:  close(4)= 0
 | 25782:  close(14)   = 0
 | 25782:  close(13)   = 0
 | 25782:  close(12)   = 0
 | 25782:  close(11)   = 0
 | 25782:  close(10)   = 0
 | 25782:  close(9)= 0
 | 25782:  close(8)= 0
 | 25782:  close(20)   = 0
 | 25782:  close(26)   = 0
 | 25782:  close(24)   = 0
 | 25782:  fcntl(25, F_DUP2FD, 0x0001) = 1
 | 25782:  close(25)   = 0
 | 25782:  fcntl(27, F_DUP2FD, 0x0002) = 2
 | 25782:  close(27)   = 0
 | 25782:  sigaction(SIGCLD, 0x80F48B165A90, 0x80F48B165B20) = 0
 | 25782:  chdir(".")  = 0
 | 25782:  
execve("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 
0x9942814C8, 0x80F48B165B78)  argc = 4
 | 25782:  sysinfo(SI_MACHINE, "i86pc", 257)   = 6
 | 25782:  mmap(0x, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 
4294967295, 0) = 0x80FFBF76
 | 25782:  memcntl(0x80FFBF792000, 110504, MC_ADVISE, MADV_WILLNEED, 0, 0) 
= 0
 | 25782:  memcntl(0x0040, 172672, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 | 25782:  resolvepath("/usr/bin/amd64/ksh93", "/usr/bin/amd64/ksh93", 1023) = 
20
 | 25782:  resolvepath("/usr/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 
18
 | 25782:

svnversion output changed when redirecting the output. Why?

[Steenveld, Andre]

Hi,

I’m working with svn (via TortoiseSVN) versions 1.7, 1.8 and 1.9 and due to 
external factors I cannot bring it up to the same version.
Also, I’m using svn via the TortoiseSVN package but I believe that my question 
is related to svn and not to TortoseSVN, please correct me it this is not the 
case.

I use the svnversion command to keep track of versions in my sandboxes. For 
this I redirect the output from svnversion to a file and use that file in other 
parts.

For versions 1.7 and 1.8 the command line output from svnversion is identical 
to the redirected output. But for version 1.9 it is not and there is no command 
line option to get it to the `old style’ output.

Here is an example for 1.8
C:\…> svnversion .
22923:22924M

C:\...>svnversion . > output.txt
C:\...>type output.txt
22923:22924M

And here is the same example but now for 1.9
C:\…> svnversion .
22923:22924M

C:\...>svnversion . > output.txt
C:\...>type output.txt
M
22923:22924

Note that if the sandbox is not modified the first line is an empty one.

Question:
Why is the M (sandbox modified) on a separate line?
How do I get ‘1.8’ behavior back for this 1.9 version of svnversion?

Kind regards.

André Steenveld | Software Engineer | Production Onderhoud, Ontwikkeling & 
Support
MARIN | T +31 317 49 34 30 | 
a.h.m.steenv...@marin.nl | 
www.marin.nl

[LinkedIn] [YouTube] 
  [Twitter] 
  [Facebook] 

MARIN news: Viscous free-surface power predictions for self-propulsion using a 
hybrid RANS-BEM coupling 
procedure

Re: svnversion output changed when redirecting the output. Why?

[Ivan Zhakov]

On 10 February 2016 at 18:09, Steenveld, Andre  wrote:
>
> Hi,
>
> I’m working with svn (via TortoiseSVN) versions 1.7, 1.8 and 1.9 and due to 
> external factors I cannot bring it up to the same version.
>
> Also, I’m using svn via the TortoiseSVN package but I believe that my 
> question is related to svn and not to TortoseSVN, please correct me it this 
> is not the case.
>
> I use the svnversion command to keep track of versions in my sandboxes. For 
> this I redirect the output from svnversion to a file and use that file in 
> other parts.
>
> For versions 1.7 and 1.8 the command line output from svnversion is identical 
> to the redirected output. But for version 1.9 it is not and there is no 
> command line option to get it to the `old style’ output.
>
> Here is an example for 1.8
>
> C:\…> svnversion .
> 22923:22924M
>
> C:\...>svnversion . > output.txt
> C:\...>type output.txt
> 22923:22924M
>
> And here is the same example but now for 1.9
>
> C:\…> svnversion .
>
> 22923:22924M
>
> C:\...>svnversion . > output.txt
> C:\...>type output.txt
>
> M
>
> 22923:22924
>
> Note that if the sandbox is not modified the first line is an empty one.
>
> Question:
>
> Why is the M (sandbox modified) on a separate line?
>
> How do I get ‘1.8’ behavior back for this 1.9 version of svnversion?
>
>

What exact version of TortoiseSVN 1.9.x do you use? Output of 'svn
--version --verbose' command would be useful.

If I remember correctly some TortoiseSVN builds was compiled using
static runtime and this caused some problems with stdout flushing.


-- 
Ivan Zhakov