Ben Collins-Sussman wrote:
> You're not giving us much to work with. We have no idea what OSes
> you're using, what versions of SVN, and you're describing things, rather
> than showing us transcripts. But that said...
True, sorry about that. Am a bit preoccupied with the problem at hand,
having fought it the better part of my day. ;-)
Summarising, I tried several things from different machines and networks:
1. At our Medical Systems division: Windows XP, listing 'version 2002
service pack 1' as version, Subversion version 1.0.4.
2. At Research: Debian GNU/Linux, kernel version 2.6.3, Subversion
1.0.3-1.
3. At home: Debian GNU/Linux, kernel version 2.6.5, Subversion 1.0.5-1.
I'm not sure exactly how the corporate network is organised: although
the Medical and Research divisions are at different sites and have
separate network connections, I don't know exactly how the proxy servers
are organised. It is possible that they actually route HTTP(S) traffic
through the same HTTP proxies -- for me, there's no way of telling.
However, my home machine is obviously on a totally different network
than both office locations. So in total, I tried from three machines,
at least two distinct network connections, two operating systems, and
three versions of Subversion.
> On Fri, 2004-07-16 at 05:44, Auke Jilderda wrote:
>
>> svn: REPORT request failed on '/svn/medical/!svn/vcc/default'
>> svn: REPORT of '/svn/medical/!svn/vcc/default': Could not read response
>> body: Secure connection truncated
>
> So is this the 'svn merge' command that got interrupted? Do you have
> any way of reproducing? Can you show us the output?
Yes, that's the output of the 'svn merge'. By now, I've tried the merge
several times, both from the office at Medical and from home and it
reproducibly bails out at the same point. Guess that is good news. ;-/
There's probably little use in attaching the entire output since it
simply lists a lot of changes but the merge bails out at an xml file
(which I'm not allowed to send to the list for obvious reasons). Don't
see anything wrong with it, can open it, no weird access right, nothing
wrong, AFAICS.
> Sure, you've got only some local mods, but not others.
Yes, that was what I would expect.
> Correct. 'svn revert' removes textual and property edits, and
> 'unschedules' any deletes and adds. The problem is that merely
> unscheduling an add doesn't delete the file: you're left with an
> unversioned file lying around. (We do this, because svn is careful to
> never delete unversioned data.)
>
> So the moral of the story is, after doing an 'svn revert -R' to revert a
> merge, run 'svn status' to see all the unversioned things left behind,
> and hand-remove them before retrying the merge.
Ok good, that explains that behaviour indeed and it makes sense to me,
thanks.
> This is not normal behavior by any means. It looks like you're having
> some sort of network 'hiccup' that's pausing all communication between
> client and server... and that would explain why the 'svn merge' command
> was mysteriously disconnected as well. Are you having any sort of
> network latency or disconnect problems?
Yes, that was my first guess as well so I started trying (over the
course of several weeks), both from Medical, Research, and home: a
checkout shows consistently and reproducibly shows these hiccups -- it
stops at exactly the same points both on Linux and Windows and at all
three sites. Will be quite a challenge to debug this, I guess.
Auke
--
Auke Jilderda, Philips Research, Eindhoven, the Netherlands
e-mail: auke.jilderda@philips.com, phone: +31 40 2764870
http://pww.innersource.philips.com, http://pww.opensource.philips.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 16 18:23:07 2004