Thanks a lot : Problem does not occure in other environment AW: File checkin hook work; http checkin hooks don't work : AW: SELInux disabled !AW: Problem with subversion hooks scripts under Linux Apac
Hello Philip Martin and Nico Kadel-Gracia, thanks a lot for your support. It seems that it was really a problem. I tried the hooks (unchanged as I have saved them inbetween in subversion) today at a different machine (with more memory) and there all hook scripts work perfect. The Apache WebDav configuration is on both machines identical. One last point, which I still not understand. In the link you sent, I saw that you got "Cannot allocate memory" in the apache log. I saw at our machine (where the problem occurred) no error messages in the apache log. In the /etc/apache2/apache2.conf I configured a specific log file for my tests (ErrorLog /var/log/sbox_log/error.log) and Log level "debug" (LogLevel debug) . Log info was written to this Log fIle but no information, why the execution of the hook scrip failed. Strange. Again thanks a lot for your support. Best regards, Michael -Ursprüngliche Nachricht- Von: Philip Martin [mailto:philip.mar...@wandisco.com] Gesendet: Freitag, 27. Juni 2014 16:43 An: Korte, Michael Johannes Cc: Nico Kadel-Garcia; users@subversion.apache.org; Kocsis, Zoltan; Seelaender, Robin; von Schoenebeck, Florian Betreff: Re: File checkin hook work; http checkin hooks don't work : AW: SELInux disabled !AW: Problem with subversion hooks scripts under Linux Apache Dav "Korte, Michael Johannes" writes: > Warnung: Failed to start > '/var/subversion/repos17/sbox/hooks/post-commit' hook > > It seems that the hook script can not be executed, when it is started > via apache server, if it has execute permission and owner www-data. > > Is there any possibility to specify that apache can execute a script? I believe the "Failed to start" message means that Apache is failing to fork a child process and is not getting as far as attempting to run the hook script. One possibility is this memory problem: http://mail-archives.apache.org/mod_mbox/subversion-dev/201211.mbox/%3c87bof1nqcn@ntlworld.com%3E in which case the solution is to allocate some swap or reduce the cache size. Run "strace -f -p " on the apache process and look for the clone() and execve() calls. That will confirm whether or not apache is forking and attempting to run the hook. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Looking at the network trace packet wireshark PoV, looks like that the server tried to send data to the client (javahl), but saw that client's data buffer window is full (like ZeroWindow packet) and client is sending a zero window to the server. And finally, the client is sending a series of RESET packets to server. And these RST packets appears when javaHL crashed Any thoughts? Regards On Thu, Jun 26, 2014 at 2:59 PM, Darly Senecal Baptiste wrote: > Reviewing some information about JavaHL, isn't it because of the serf http > library? > > Regards > > > On Thu, Jun 26, 2014 at 12:22 PM, Darly Senecal Baptiste < > dsenec...@gmail.com> wrote: > >> Hi Community: >> >> I updated subclipse plugin to the latest version (1.10.5) with JavaHL as >> its default subversion client adapter. >> >> I checked out code from a small repository (completely) and everything >> went well. However, while I was trying to check out part of code from a >> large repository, eclipse crashes unexpectedly. I don't know why >> >> I changed the client adapter from JavaHL to SVNKit(JavaSVN) and all >> checkouts went well without crashing eclipse. >> >> I was trying to look the reasons of the crash but the eclipse log doesn't >> provide the reasons of crashing. >> >> Is there a way to look for reasons of eclipse being crashed? Please let >> me know. >> >> In addition I looked at the server logs the following error at the moment >> of the incident >> >> [Thu Jun 26 10:55:26.087485 2014] [dav:error] [pid 25691] [client >> 10.20.71.52:53404] Unable to deliver content. [500, #0] >> [Thu Jun 26 10:55:26.087525 2014] [dav:error] [pid 25691] [client >> 10.20.71.52:53404] Could not write data to filter. [500, #175002] >> [Thu Jun 26 10:55:26.087532 2014] [dav:error] [pid 25028] [client >> 10.20.71.52:53405] Unable to deliver content. [500, #0] >> [Thu Jun 26 10:55:26.087559 2014] [dav:error] [pid 25028] [client >> 10.20.71.52:53405] Could not write data to filter. [500, #175002] >> [Thu Jun 26 10:55:26.087842 2014] [dav:error] [pid 25693] [client >> 10.20.71.52:53399] Provider encountered an error while streaming a >> REPORT response. [500, #0] >> [Thu Jun 26 10:55:26.087876 2014] [dav:error] [pid 25693] [client >> 10.20.71.52:53399] A failure occurred while driving the update report >> editor [500, #104] >> >> >> >> Regards >> > >
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste wrote: > Looking at the network trace packet wireshark PoV, looks like that the > server tried to send data to the client (javahl), but saw that client's > data buffer window is full (like ZeroWindow packet) and client is sending a > zero window to the server. And finally, the client is sending a series of > RESET packets to server. And these RST packets appears when javaHL crashed > > If JVM is crashing it should be producing a dump. Find it and send it. Also, as I mentioned earlier, you should see if you can recreate the crash using the command line. This might be produce a cleaner crash dump to look at. Since it is happening during checkout, you ought to be able to just execute the same checkout command. You could also try recreating it with TortoiseSVN. They have an automated system to produce and collect the crash dumps built-in. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
To be clear and to double confirm Recreated the same svn checkout command through command line and TortoiseSVN, checkouts went through without any issue. Also, you can see the jvm dump at this link https://db.tt/LBOXhJyi . Regards On Mon, Jun 30, 2014 at 2:26 PM, Mark Phippard wrote: > On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste < > dsenec...@gmail.com> wrote: > >> Looking at the network trace packet wireshark PoV, looks like that the >> server tried to send data to the client (javahl), but saw that client's >> data buffer window is full (like ZeroWindow packet) and client is sending a >> zero window to the server. And finally, the client is sending a series of >> RESET packets to server. And these RST packets appears when javaHL crashed >> >> > If JVM is crashing it should be producing a dump. Find it and send it. > > Also, as I mentioned earlier, you should see if you can recreate the crash > using the command line. This might be produce a cleaner crash dump to look > at. Since it is happening during checkout, you ought to be able to just > execute the same checkout command. You could also try recreating it with > TortoiseSVN. They have an automated system to produce and collect the > crash dumps built-in. > > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
On Mon, Jun 30, 2014 at 3:09 PM, Darly Senecal Baptiste wrote: > To be clear and to double confirm > > Recreated the same svn checkout command through command line and > TortoiseSVN, checkouts went through without any issue. > Are you using same SVN versions? What are you using for command line binaries? Ideally, try the ones from CollabNet since that is what Subclipse is using. Could be related to a specific version of SVN or dependency. > Also, you can see the jvm dump at this link https://db.tt/LBOXhJyi . > > Just for the archives, pasting the relevent bits. Nothing jumps out at me here to point in any direction though: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6508a7cf, pid=6324, tid=6692 # # JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14) # Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing windows-x86 ) # Problematic frame: # C [libsvn_wc-1.dll+0x4a7cf] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows Stack: [0x0588,0x0598], sp=0x0597eaac, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libsvn_wc-1.dll+0x4a7cf] C [libsvn_ra-1.dll+0x496b7] C [libsvn_ra-1.dll+0x4470b] C [libsvn_ra-1.dll+0x44abe] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0 j org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(Lorg/tigris/subversion/svnclientadapter/SVNUrl;Ljava/io/File;Lorg/tigris/subversion/svnclientadapter/SVNRevision;IZZ)V+147 j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.checkoutProject(Lorg/eclipse/core/runtime/IProgressMonitor;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/tigris/subversion/svnclientadapter/ISVNClientAdapter;Ljava/io/File;)V+79 j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(Lorg/eclipse/core/resources/IProject;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/eclipse/core/runtime/IProgressMonitor;)V+273 j org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+13 j org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+10 j org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;ILorg/eclipse/core/runtime/IProgressMonitor;)V+80 j org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(Lorg/tigris/subversion/subclipse/core/ISVNRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V+20 j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+41 j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute([Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;[Lorg/eclipse/core/resources/IProject;Lorg/eclipse/core/runtime/IProgressMonitor;)Z+81 j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(Lorg/eclipse/core/runtime/IProgressMonitor;)V+94 j org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+35 j org.eclipse.team.internal.ui.actions.JobRunnableContext.run(Lorg/eclipse/jface/operation/IRunnableWithProgress;Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+2 j org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+9 j org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+37 j org.eclipse.core.internal.jobs.Worker.run()V+23 v ~StubRoutines::call_stub -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Using the following version Are you using same SVN versions? What are you using for command line > binaries? Ideally, try the ones from CollabNet since that is what > Subclipse is using. Could be related to a specific version of SVN or > dependency. SVN Linux command line : version 1.8.5 taken from Collabnet TortoiseSVN: version 1.8.6 with svn 1.8.8 JavaHL : version 1.8.9 On Mon, Jun 30, 2014 at 3:28 PM, Mark Phippard wrote: > On Mon, Jun 30, 2014 at 3:09 PM, Darly Senecal Baptiste < > dsenec...@gmail.com> wrote: > >> To be clear and to double confirm >> >> Recreated the same svn checkout command through command line and >> TortoiseSVN, checkouts went through without any issue. >> > > Are you using same SVN versions? What are you using for command line > binaries? Ideally, try the ones from CollabNet since that is what > Subclipse is using. Could be related to a specific version of SVN or > dependency. > > > >> Also, you can see the jvm dump at this link https://db.tt/LBOXhJyi . >> >> > Just for the archives, pasting the relevent bits. Nothing jumps out at me > here to point in any direction though: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6508a7cf, pid=6324, > tid=6692 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build > 1.7.0_55-b14) > # Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [libsvn_wc-1.dll+0x4a7cf] > # > # Failed to write core dump. Minidumps are not enabled by default on client > versions of Windows > > > Stack: [0x0588,0x0598], sp=0x0597eaac, free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libsvn_wc-1.dll+0x4a7cf] > C [libsvn_ra-1.dll+0x496b7] > C [libsvn_ra-1.dll+0x4470b] > C [libsvn_ra-1.dll+0x44abe] > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j > org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0 > j > org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(Lorg/tigris/subversion/svnclientadapter/SVNUrl;Ljava/io/File;Lorg/tigris/subversion/svnclientadapter/SVNRevision;IZZ)V+147 > j > org.tigris.subversion.subclipse.core.commands.CheckoutCommand.checkoutProject(Lorg/eclipse/core/runtime/IProgressMonitor;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/tigris/subversion/svnclientadapter/ISVNClientAdapter;Ljava/io/File;)V+79 > j > org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(Lorg/eclipse/core/resources/IProject;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/eclipse/core/runtime/IProgressMonitor;)V+273 > j > org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+13 > j > org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+10 > j > org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;ILorg/eclipse/core/runtime/IProgressMonitor;)V+80 > j > org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(Lorg/tigris/subversion/subclipse/core/ISVNRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V+20 > j > org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+41 > j > org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute([Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;[Lorg/eclipse/core/resources/IProject;Lorg/eclipse/core/runtime/IProgressMonitor;)Z+81 > j > org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(Lorg/eclipse/core/runtime/IProgressMonitor;)V+94 > j > org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+35 > j > org.eclipse.team.internal.ui.actions.JobRunnableContext.run(Lorg/eclipse/jface/operation/IRunnableWithProgress;Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+2 > j > org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+9 > j > org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+37 > j org.eclipse.core.internal.jobs.Worker.run()V+23 > v ~StubRoutines::call_stub > > > > > > > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
On 30.06.2014 20:26, Mark Phippard wrote: > On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste > mailto:dsenec...@gmail.com>> wrote: > > Looking at the network trace packet wireshark PoV, looks like that > the server tried to send data to the client (javahl), but saw that > client's data buffer window is full (like ZeroWindow packet) and > client is sending a zero window to the server. And finally, the > client is sending a series of RESET packets to server. And these > RST packets appears when javaHL crashed > > > If JVM is crashing it should be producing a dump. Find it and send it. > > Also, as I mentioned earlier, you should see if you can recreate the > crash using the command line. Not necessarily. I fixed a bug in JavaHL just today that was specific to the JavaHL native code and was not triggered by a similar code path used by the command-line client. That bug wasn't in any way related to this problem, though; it was in trunk JavaHL and not in any released version; but that doesn't mean there aren't any such bugs in released versions of JavaHL, too. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
On 30.06.2014 22:01, Darly Senecal Baptiste wrote: > > > > Also, you can see the jvm dump at this link > https://db.tt/LBOXhJyi . > > > Just for the archives, pasting the relevent bits. Nothing jumps > out at me here to point in any direction though: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6508a7cf, pid=6324, > tid=6692 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build > 1.7.0_55-b14) > # Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [libsvn_wc-1.dll+0x4a7cf] > # > # Failed to write core dump. Minidumps are not enabled by default on > client versions of Windows > > > Stack: [0x0588,0x0598], sp=0x0597eaac, free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libsvn_wc-1.dll+0x4a7cf] > C [libsvn_ra-1.dll+0x496b7] > C [libsvn_ra-1.dll+0x4470b] > C [libsvn_ra-1.dll+0x44abe] > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j > org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0 > This is a bit of a problem ... there's no debug information available for the native libraries, which makes it rather hard to tell what the problem might be. Is the repository by any chance public, so that I could try to do a checkout using JavaHL within a debugger? -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
> > This is a bit of a problem ... there's no debug information available for > the native libraries, which makes it rather hard to tell what the problem > might be. > > > Is the repository by any chance public, so that I could try to do a > checkout using JavaHL within a debugger? > > I don't think ... However, is there a way that I can debug it from Eclipse?
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
I do not know how you can debug, but I can point you to PDB's for the binaries you are using. http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip Brane might know better how you can use these to get better info. On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste wrote: > > >> This is a bit of a problem ... there's no debug information available for >> the native libraries, which makes it rather hard to tell what the problem >> might be. >> >> >> Is the repository by any chance public, so that I could try to do a >> checkout using JavaHL within a debugger? >> >> > I don't think ... However, is there a way that I can debug it from > Eclipse? > -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
On 30.06.2014 22:41, Mark Phippard wrote: > I do not know how you can debug, but I can point you to PDB's for the > binaries you are using. > > http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip > > Brane might know better how you can use these to get better info. Well, I've never done any debugging with JavaHL on Windows. But if you somehow manage to make those .pdb's available to the JVM -- I guess it should be enough to put them in the same directory as the relevant .dll's -- then at least the JVM crash report stack trace should give better info about what caused the crash. It would also be possible to attach a debugger to the Eclipse process then; but it'll have to be a native, not Java debugger, since the crash happens in native code. -- Brane > On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste > mailto:dsenec...@gmail.com>> wrote: > > > > This is a bit of a problem ... there's no debug information > available for the native libraries, which makes it rather hard > to tell what the problem might be. > > > Is the repository by any chance public, so that I could try to > do a checkout using JavaHL within a debugger? > > > I don't think ... However, is there a way that I can debug it > from Eclipse? > -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
I just realized those are not the right debug files anyway. I'll try to dig them up. Sent from my iPad > On Jun 30, 2014, at 5:50 PM, Branko Čibej wrote: > >> On 30.06.2014 22:41, Mark Phippard wrote: >> I do not know how you can debug, but I can point you to PDB's for the >> binaries you are using. >> >> http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip >> >> Brane might know better how you can use these to get better info. > > Well, I've never done any debugging with JavaHL on Windows. But if you > somehow manage to make those .pdb's available to the JVM -- I guess it should > be enough to put them in the same directory as the relevant .dll's -- then at > least the JVM crash report stack trace should give better info about what > caused the crash. > > It would also be possible to attach a debugger to the Eclipse process then; > but it'll have to be a native, not Java debugger, since the crash happens in > native code. > > -- Brane > >>> On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste >>> wrote: >>> This is a bit of a problem ... there's no debug information available for the native libraries, which makes it rather hard to tell what the problem might be. Is the repository by any chance public, so that I could try to do a checkout using JavaHL within a debugger? >>> >>> I don't think ... However, is there a way that I can debug it from Eclipse? > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. br...@wandisco.com
