SVN Error
Hi Guys! Tortoise SVN throwing an error on Commit:- "REPORT of '/svn/projectname/!svn/vcc/default':Could not read chunk size:Secure connection truncated(project URL)" My perception is this belongs to Network Traffic or Fluctuation in Network: - Is this TRUE? Pls share your reviews! Thanks Waseem DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail.
Could not read chunk delimiter: Secure connection truncated
Hi One of our remote svn users is getting the following error when he attempts to checkout a repo from our svn server: svn: REPORT of '/subversion//!svn/vcc/default': Could not read chunk delimiter: Secure connection truncated () We know that our repo is in good order because checkouts on the network local to the svn server work ok. Please can anyone provide information about what can cause this error? Could it be due to a low bandwidth internet connection? Best regards David
Re: Could not read chunk delimiter: Secure connection truncated
On Thu, Aug 18, 2011 at 10:19:34AM +, David Aldrich wrote: > Hi > > One of our remote svn users is getting the following error when he attempts > to checkout a repo from our svn server: > > svn: REPORT of '/subversion//!svn/vcc/default': Could not read chunk > delimiter: Secure connection truncated () > > We know that our repo is in good order because checkouts on the network local > to the svn server work ok. > > Please can anyone provide information about what can cause this error? > > Could it be due to a low bandwidth internet connection? At first guess I would suspect a latency problem that results in the server dropping a timed-out connection. Maybe adjusting KeepAliveTimeout in the HTTDP config will fix this (see http://svn.haxx.se/users/archive-2011-08/0378.shtml for some links). Is there a proxy between the svn server and remove svn clients?
Re: SVN Error
On Thu, Aug 18, 2011 at 12:12:34PM +0500, Waseem Bokhari wrote: > Hi Guys! > Tortoise SVN throwing an error on Commit:- > > "REPORT of '/svn/projectname/!svn/vcc/default':Could not read chunk > size:Secure connection truncated(project URL)" > > My perception is this belongs to Network Traffic or Fluctuation in Network: > - Is this TRUE? Yes, check the server-side logs to find out more. This error happens when the connection between client and server is dropped for some reason (server reboot, timeout, packet loss...) In some situations increasing KeepAliveTimeout in the HTTPD config will fix this, see http://svn.haxx.se/users/archive-2011-08/0378.shtml for some links.
RE: Could not read chunk delimiter: Secure connection truncated
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: 18 August 2011 12:12 > To: David Aldrich > Cc: 'users@subversion.apache.org' > Subject: Re: Could not read chunk delimiter: Secure connection truncated > > On Thu, Aug 18, 2011 at 10:19:34AM +, David Aldrich wrote: > > Hi > > > > One of our remote svn users is getting the following error when he > attempts to checkout a repo from our svn server: > > > > svn: REPORT of '/subversion//!svn/vcc/default': Could not read > > chunk delimiter: Secure connection truncated () > > > > We know that our repo is in good order because checkouts on the network > local to the svn server work ok. > > > > Please can anyone provide information about what can cause this error? > > > > Could it be due to a low bandwidth internet connection? > > At first guess I would suspect a latency problem that results in the server > dropping a timed-out connection. > Maybe adjusting KeepAliveTimeout in the HTTDP config will fix this (see > http://svn.haxx.se/users/archive-2011-08/0378.shtml for some links). > > Is there a proxy between the svn server and remove svn clients? > Thanks for your reply. There will be numerous proxies in the path. Best regards David
Tree Conflicts with Subversion 1.7
Hi, Can Subversion 1.7 still have tree conflicts? Or can the new working copy break them down to individual conflicts on files (and directory properties)? Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Tree Conflicts with Subversion 1.7
On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote: > Hi, > > Can Subversion 1.7 still have tree conflicts? Yes. Nothing much has changed on that front for 1.7. Foundations for some bigger changes in tree-conflict behaviour planned for 1.8 and later are already being worked on. > Or can the new working copy break them down to individual conflicts on > files (and directory properties)? Not sure what you mean here. Can you provide an example?
AW: Tree Conflicts with Subversion 1.7
Hi, Von: Stefan Sperling [mailto:s...@elego.de] > On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote: > > Hi, > > > > Can Subversion 1.7 still have tree conflicts? > > Yes. Nothing much has changed on that front for 1.7. > Foundations for some bigger changes in tree-conflict behaviour planned for > 1.8 and later are already being worked on. > > > Or can the new working copy break them down to individual conflicts on > > files (and directory properties)? > > Not sure what you mean here. Can you provide an example? My idea was that directories itsself would never conflict. If there's a directory removed, and a new one created with the same name, it is the same directory, so no tree conflict. If the directories have different properties, then those properties conflict, and if they have conflicting files, then those files conflict individually. But no tree conflict. But maybe my thought is a little bit to short. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Tree Conflicts with Subversion 1.7
On Thu, Aug 18, 2011 at 05:30:59PM +0200, Markus Schaber wrote:
> My idea was that directories itsself would never conflict. If there's a
> directory removed, and a new one created with the same name, it is the
> same directory, so no tree conflict. If the directories have different
> properties, then those properties conflict, and if they have conflicting
> files, then those files conflict individually. But no tree conflict.
>
> But maybe my thought is a little bit to short.
Depending on what the directories represent, this may or may not
be desirable.
Consider this example:
Two Java developers, Harry and Sally, work on different feature
branches A and B. The code base they're working on is a sales
and purchase tracking system.
Harry creates a new package called 'fruit' on branch A, which
contains classes for tracking fruit sales.
Sally creates a new package called 'fruit' on branch B, which
contains classes for tracking fruit purchases.
Both packages do serve entirely different purposes but happen to share
the same name (of course, the example hinges on the fact that there are
no subpackages which devide packages between the 'sales' and 'purchase'
categories -- but things like this do happen in real life).
Feature branch A gets merged into trunk.
Feature branch B gets merged into trunk. Now there is a tree conflict.
If we simply throw both sets of files in the different 'fruit' packages
together into a single 'fruit' directory, Sally will have a lot of fun
sorting the individual files back into different directories.
Note that this is how git, Mercurial, and maybe others behave in this
situation.
Right now, Subversion simply flags a conflict and lets the user resolve
the situation in the working copy. This is a crude user-interface but it
covers all possible resolution strategies, assuming the user knows how
to achieve the desired state in the working copy (this is often more
easily said than done!).
But I don't think subversion should enforce one particular merge outcome.
My opinion is that the user should be given a choice, and be supported
by an interactive conflict resolution prompt that shows all possible
resolution strategies:
- put all files in the same directory ("Markus Schaber's strategy")
- rename the local directory
- rename the incoming directory
- delete the local directory, replace with incoming directory
- discard the incoming directory, keep the local directory
- discard both directories
- etc... (are there any more possibilities?)
This is what I hope Subversion will eventually be able to do.
There's a ton of work left until we get there and it's not an
easy problem to solve.
However, the foundations that 1.7 provides with wc-ng are already
bearing fruit, and make progress a lot easier than it was with 1.6.
We started working on better support for local moves on trunk after
1.7 was branched about a month ago. Right now I have svn status
showing me tree conflicts such as:
$ svn status
R + C xx
> moved from alpha
> local moved here, incoming add upon update
D C alpha
> moved to xx
> local moved away, incoming edit upon update
Summary of conflicts:
Tree conflicts: 2
$
This would have been impossible to implement within a similar time
frame in the Subversion 1.6 code base.
I don't know yet how far we will get for 1.8. We probably won't be
showing the interactive prompt I described above. But there is still
a lot of time left until 1.8.0 and we'll try to make as much progress
as possible.
If you have any more suggestions or ideas, please keep sharing them.
Now is an excellent time for this. Thanks.
Data compression between HTTPs client and server
Hi list I am using Subversion with TortoiseSVN over HTTPs. Now that I access my SVN server in Germany from Thailand and displaying logs and getting diffs is horribly slow, I wonder if I can enable any kind of compression? Regards, André
Re: Data compression between HTTPs client and server
On Aug 18, 2011, at 11:39, André Hänsel wrote: > I am using Subversion with TortoiseSVN over HTTPs. > > Now that I access my SVN server in Germany from Thailand and displaying logs > and getting diffs is horribly slow, I wonder if I can enable any kind of > compression? The topic recently came up on the list just recently. http://svn.haxx.se/users/archive-2011-08/0148.shtml I believe the end result was you can enable compression (consult Apache documentation), and it may help in some circumstances. It might possibly cause problems for some Subversion clients. You'll have to see if it adversely affects the clients you use.
Re: Tree Conflicts with Subversion 1.7
Markus Schaber wrote on Thu, Aug 18, 2011 at 17:30:59 +0200: > Hi, > > > Von: Stefan Sperling [mailto:s...@elego.de] > > On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote: > > > Hi, > > > > > > Can Subversion 1.7 still have tree conflicts? > > > > Yes. Nothing much has changed on that front for 1.7. > > Foundations for some bigger changes in tree-conflict behaviour planned > for > > 1.8 and later are already being worked on. > > > > > Or can the new working copy break them down to individual conflicts > on > > > files (and directory properties)? > > > > Not sure what you mean here. Can you provide an example? > > My idea was that directories itsself would never conflict. If there's a > directory removed, and a new one created with the same name, it is the > same directory, so no tree conflict. If the directories have different > properties, then those properties conflict, and if they have conflicting > files, then those files conflict individually. But no tree conflict. > > But maybe my thought is a little bit to short. What copyfrom would the single directory have, in the case of an add/add conflict? % svn mkdir A; svn ci -m r1 % svn rm A; svn ci -m r2 % svn mkdir A % svn merge -c1 ./
Re: JavaHL bindings - post-commit error messages
Hi, Am Dienstag, den 16.08.2011, 11:14 -0400 schrieb Mark Phippard: > On Tue, Aug 16, 2011 at 11:09 AM, Martin Kutter > wrote: > > is there a way to receive get post-commit error messages on performing a > > commit with the JavaHL bindings? > > Subclipse uses JavaHL and I believe it shows these messages. Have you > registered a call back to receive the Notifications? > > http://subversion.apache.org/docs/javahl/1.6/org/tigris/subversion/javahl/Notify2.html > A quick test (set up a empty local repo with failing post-commit hook with some message on STDERR, add a folder to the wc and commit) reveals that Subclipse (1.6.18) does not show post-commit errors. I'll test-drive the notifications API though. Thanks, Martin
Re: Tree Conflicts with Subversion 1.7
On Thu, 18 Aug 2011 18:13:09 +, Stefan Sperling wrote:
...
> But I don't think subversion should enforce one particular merge outcome.
> My opinion is that the user should be given a choice, and be supported
> by an interactive conflict resolution prompt that shows all possible
> resolution strategies:
> - put all files in the same directory ("Markus Schaber's strategy")
> - rename the local directory
> - rename the incoming directory
> - delete the local directory, replace with incoming directory
> - discard the incoming directory, keep the local directory
> - discard both directories
Actually I think these are better handled by throwing away the merge
results and doing the renames/removes on the respective branches, then
redo the merge. I tend to feel uneasy in these interactive conflict
resolutions.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Tree Conflicts with Subversion 1.7
On 18-Aug-11 19:05, Daniel Shahaf wrote:
What copyfrom would the single directory have, in the case of an add/add
conflict?
The same as if you resolve an add/add file conflict by manually throwing the two
file contents into one file: you may wish a double copyfrom, to trace back to
both origins later. I bet our beloved SVN developers are not eager to support
multiple copyfroms, so at most one of them gets the honor.
To be accurate, the first add/add resolution strategy has three subplots:
- put all files in the same directory ("Markus Schaber's strategy")
- and pretend it's a copy from local
- and pretend it's a copy from incoming
- and pretend it's brand new
In any case, even if there was an automatic add/add resolution for directories,
it's still possible to have an add/add conflict of a directory versus a file,
and I dare Markus to come up with an automatic resolution for that...
--
Stein
Re: Tree Conflicts with Subversion 1.7
On Thu, Aug 18, 2011 at 07:22:28PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 18:13:09 +, Stefan Sperling wrote:
> ...
> > But I don't think subversion should enforce one particular merge outcome.
> > My opinion is that the user should be given a choice, and be supported
> > by an interactive conflict resolution prompt that shows all possible
> > resolution strategies:
> > - put all files in the same directory ("Markus Schaber's strategy")
> > - rename the local directory
> > - rename the incoming directory
> > - delete the local directory, replace with incoming directory
> > - discard the incoming directory, keep the local directory
> > - discard both directories
>
> Actually I think these are better handled by throwing away the merge
> results and doing the renames/removes on the respective branches, then
> redo the merge.
The above is only for "add vs. add" situations.
Scenarios involving renames are different.
> I tend to feel uneasy in these interactive conflict resolutions.
What makes you feel uneasy about it?
Note that, ideally, this menu could be recalled offline, after the
merge/update has completed with all conflicts postponed.
So you'd have all the time in the world to figure out your answer,
if that's what worrying you.
Re: Tree Conflicts with Subversion 1.7
On Thu, Aug 18, 2011 at 08:41:44PM +0200, Stein Somers wrote:
> On 18-Aug-11 19:05, Daniel Shahaf wrote:
> >What copyfrom would the single directory have, in the case of an add/add
> >conflict?
>
> The same as if you resolve an add/add file conflict by manually
> throwing the two file contents into one file: you may wish a double
> copyfrom, to trace back to both origins later. I bet our beloved SVN
> developers are not eager to support multiple copyfroms, so at most
> one of them gets the honor.
Indeed, multiple copyfroms would be nasty.
But I don't see the need. Because, ideally, copyfrom info should always point
to a node in the same branch, even if the copy was merged from another branch.
> To be accurate, the first add/add resolution strategy has three subplots:
> - put all files in the same directory ("Markus Schaber's strategy")
>- and pretend it's a copy from local
>- and pretend it's a copy from incoming
>- and pretend it's brand new
I think a copy source should always be from the local branch, or an add if
no suitable copy source node exists in the local branch. The copy source
will exist, at least it the branch's history, if the branches have common
ancestry and all revisions are merged (i.e. no cherry-picking).
But it won't exist in all cases. Hence the current strategy of having
the copyfrom point to the merge source. It is an easy way out but I
don't like it. It is the most reasonable thing to do if you don't want
to worry about copy sources that don't exist, but it's quite stupid and
non-intuitive at the semantic level.
> In any case, even if there was an automatic add/add resolution for
> directories, it's still possible to have an add/add conflict of a
> directory versus a file, and I dare Markus to come up with an
> automatic resolution for that...
Agreed. The tool should not try to outsmart people in complicated
cases like this. Whenever there is more than one option to resolve
a conflict, all options should be offered.
Re: Tree Conflicts with Subversion 1.7
Stein Somers wrote on Thu, Aug 18, 2011 at 20:41:44 +0200: > On 18-Aug-11 19:05, Daniel Shahaf wrote: > >What copyfrom would the single directory have, in the case of an add/add > >conflict? > > The same as if you resolve an add/add file conflict by manually > throwing the two file contents into one file: you may wish a double > copyfrom, to trace back to both origins later. I bet our beloved SVN > developers are not eager to support multiple copyfroms, so at most > one of them gets the honor. You don't sound like you care to have a technical discussion about the problems that multiple copyfrom would introduce v. would solve.
update in 1.6.17 slower?
Hello, Recently I upgraded from 1.6.9 to 1.6.17. 'svn up' is very noticeably slower than it used to be. I didn't see anything in the CHANGES file about signficant 'update' changes so I was wondering if this was expected? With 1.6.9 I didn't turn off authz (even though I don't use it) but I thought maybe it was the problem with 1.6.17. No luck. (btw, I'm using Apache + https. I turned *off* authz using SVNPathAuthz off). checkout and other operations are very snappy. I am using default options when building subversion so I'm using neon. It's neon 0.25 (comes with Centos 5.4). -- seth /\ sethdaniel.org
Re: sporadic, hanging connections to apache svn (centos 5.4)
On Tue, Aug 16, 2011 at 11:36:29AM -0400, Nico Kadel-Garcia wrote: > On Mon, Aug 15, 2011 at 11:08 PM, Seth Daniel > wrote: > > Hi, > > > > I've done many subversion installs but never have I seen the following > > problem before. > > > > Vanilla Centos 5.4. Subversion 1.6.17 (compiled and packaged by me). > > Nothing fancy with the compilation. I use an 'amalgamated' sqlite > > 3.6.23 when configuring...otherwise no other options to configure. Then > > make; make install. The client being used is from the same 1.6.17 > > package. Apache with prefork MPM (centos 5.4 comes with apache 2.2.3). > > Dude!!! I'm building up an SRPM for RPMforge, backported from the > Fedora Core 16 test release of subversion-1.6.17. Would you care to > share notes,, or perhaps even test mine as scratch monkey > (http://www.catb.org/jargon/html/S/scratch-monkey.html) ? > > I also encourage you to jump to CentOS 5.6: while it took a while to > come out, there are numerous small improvements that pay off at tough > moments, like the profound stability updates to autofs. > > > > The problem: Occasional and (so far) non-deterministic 'hangs'[1] of > > subversion requests. It doesn't seem to matter if it's a commit or a > > status or a log. Eventually, at some point, a request to the server > > will hang. All requests are https. > > That's no good!!! No it's not. It seems the problem (based on strace output) is related to apache connecting/reading to/from the ldap server. Every single hung apache instance was in a 'poll' on the ldap server socket. I still don't know why that is happening. We have other apache's doing the same thing and they don't exhibit this problem. > That.. is not good. I wonder if you do have an "I ran out of > randomness" issue? Can you roll back to the subversion-1.6.11 from > CentOs 5.6, or the subversion-1.6.15 from RPMforge (that I helped > bundle) on another server, and see if you can replicate the behavior? > Is this a wildly *busy* server? This is a wildly unbusy server. We host it on a dual proc Xen host and the load rarely gets above 0.1. -- seth /\ sethdaniel.org
SlikSvn crash dump
svn-crash-log20110818104557.log Description: Binary data
