Re: branching WC folder fails with files marked as deleted

2013-01-11 Thread Roman Kellner
Hello Daniel, hello Stefan Sorry for the empty email. Dont know what happened to the web email. I guess I found the issue and implemented the following feature in our MSSCCI wrapper. If you can confirm that, when I find a "deleted" line in the .svn/entries file to a WC controlled file as shown

Re: branching WC folder fails with files marked as deleted

2013-01-11 Thread Philip Martin
"Roman Kellner" writes: > If you can confirm that, when I find a "deleted" line in the .svn/entries > file to a WC controlled file as shown below, then the file was only deleted > in the WC and is marked for deletion in the repo which will be done with > the next commit. Is this the exact mean

Re: branching WC folder fails with files marked as deleted

2013-01-11 Thread Stefan Sperling
On Fri, Jan 11, 2013 at 09:01:56AM +0100, Roman Kellner wrote: > Hello Daniel, hello Stefan > > Sorry for the empty email. Dont know what happened to the web email. > > I guess I found the issue and implemented the following feature in our > MSSCCI wrapper. > > If you can confirm that, when I f

RE: branching WC folder fails with files marked as deleted

2013-01-11 Thread Bert Huijben
This issue sounds like a combination of issues #2763 and #3569. The ‘svn up --depth empty’ in 1.6 triggers issue #3569: http://subversion.tigris.org/issues/show_bug.cgi?id=3569 ‘svn update --depth allows making a working copy incomplete’ While #2763 handles some similar cases in copies:

Re: Cant open repository folder

2013-01-11 Thread Daniel Shahaf
Stefan Sperling wrote on Thu, Jan 10, 2013 at 17:59:50 +0100: > On Tue, Jan 08, 2013 at 06:34:54PM +0530, noufal av wrote: > > how i solve this problem..plzz help me and i waiting for ur solution > > The repository cannot be read because the 'current' file is apparently > empty. This means

Truncated file issues

2013-01-11 Thread Paul E
Hi, We're having an issue that has occurred three times in the past two weeks with two different repositories hosted with VisualSVN (version 2.5.8). Upon checkout, we get the following message: REPORT of '/svn//!svn/me': Could not read chunk size: Secure connection truncated Apache logs show:

Re: Truncated file issues

2013-01-11 Thread Thorsten Schöning
Guten Tag Paul E, am Donnerstag, 10. Januar 2013 um 21:11 schrieben Sie: > This is a major issue for us as we're actively developing against > these projects and having to recommit over and over again. Currently > resolving the issue by creating a dump to the revision prior to the > truncation an

Re: Truncated file issues

2013-01-11 Thread Stefan Sperling
On Thu, Jan 10, 2013 at 02:11:04PM -0600, Paul E wrote: > Hi, > > We're having an issue that has occurred three times in the past two weeks > with two different repositories hosted with VisualSVN (version 2.5.8). VisualSVN 2.5.8 is pretty recent. Did this start happening after an upgrade/install

--non-interactive seems not to work as expected

2013-01-11 Thread Guido Serra
Hi, I stumbled upon a misbehavior of the svn client. Providing http basic auth over the --non-interactive option, does not work svn checkout --non-interactive --no-auth-cache --username --password > svn: E170001: Unable to connect to a repository at URL 'http://xxx' > svn: E170001: O

Re: Truncated file issues

2013-01-11 Thread Paul E
Apologies, I failed to mention that I had upgraded VisualSVN Server from 2.5.6 to 2.5.8 after the first repository exhibited corruption. I have not tried VisualSVN 2.5.7. I have looked into potential hardware issues, but am fairly confident that's not the issue. This is fully redundant server with