RE: EXTERNAL: error 'Network connection closed unexpectedly' while svn update

[Marlow, Andrew]

Hello everyone and thank you Detlef for reporting this situation. I want to add 
that I also see this from time to time and would like to see a fix.

It is very easy for me to see network errors from subversion because I am in an 
environment where the network is extremely unreliable. This fact has revealed 
several software products that, IMHO, do not take transient network errors into 
account. I think it is a common failing, especially as networks have generally 
become more reliable over the years (so it’s easy to take it for granted when 
writing socket code).

From: Detlef Braungardt 
Sent: 05 December 2019 15:58
To: users@subversion.apache.org
Subject: EXTERNAL: error 'Network connection closed unexpectedly' while svn 
update

Hi everyone,


we use TortoiseSVN for our development.

But in a special situation we get an error 'Network connection closed 
unexpectedly' during a svn update. The steps to reproduce the situation is 
writed down in the Google Groups thread.
I posted this error as a bug on the Tortoise list.
https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/tortoisesvn/MSaacoX73DU
After a short communication we found out that the bug is probably contained in 
the libsvn.
C:\Program Files\TortoiseSVN\bin>svn update "D:\Develop\FIRMA\trunk\Tests" -r 
15749
Updating 'D:\Develop\FIRMA\trunk\Tests':

svn: E235000: In file 
'/build/subversion-Lv3Qkk/subversion-1.9.7/subversion/libsvn_fs_base/trail.c' 
line 97: assertion failed (! bfd->in_txn_trail)
svn: E210002: Network connection closed unexpectedly
Can you help us to fix this bug?
Thanks in advance.


Best regards

Detlef


--

*

*  Computerservice Braungardt   *

*

*  Dipl.-Wirtsch.-Inf.  Detlef Braungardt   *

*

* email:deve...@coseb.de   
 *

* www:  
www.CoseB.de
*

*

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. FIS is a trading name of the following 
companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay 
Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex 
(International) Limited (No: 260) | FIS Apex (UK) Limited (No. 3573008) | 
FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility 
Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 
1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global 
Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 
1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems 
Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | 
FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 
2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis 
Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | 
Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink 
Information Services Limited (No: 3827424) all registered in England & Wales 
with their registered office at 25 Canada Square, London E14 5LQ | FIS Global 
Execution Services Limited is authorised and regulated by the Financial Conduct 
Authority | Certegy Card Services Limited (No: 3517639) | Certegy France 
Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity 
Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 
4215488) | Metavante Technologies Limited (No: 2659326) all registered in 
England & Wales with their registered office at 1st Floor Tricorn House, 51-53 
Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | 
FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct 

File encoding is UTF-16LE

[沙飞漠里]

Dear Mr./Ms.

  Does SVN support file with the encoding UTF-16LE as the text file?
  I have a text file("test.txt") and the file's encoding is UTF-16LE. I
want SVN to treate this file("test.txt") as a text file, so I change its
property svn:mime-type: application/octet-stream to
svn:mime-type:text/plain.
  SVN will insert the utf-8 string ("<<< .mine" , " .r2",
" .r3") in the conflicting area of "test.txt"  When
"test.txt" conflict occurs. Because the file's encoding is UTF-16LE,the
content of the "test.txt" is garbled.

  What should I do to make SVN  insert  the UTF-16LE string ("<<<
.mine" , " .r2", " .r3") in the conflicting area of
"test.txt"? Thank you!


  The steps of my operation:
  1. Add “test.txt” with the encoding UTF-16LE to the working copy.
  2. Change its property to  svn:mime-type:text/plain , and commit it.
  3. Check out it to working copy 1 and working copy 2.
  4. Insert new line with content "111" at the end of "test.txt" at the
working copy 1, and commit it.
  5. Insert new line with content "222" at the end of "test.txt" at the
working copy 2.
  6. Update working copy 2. "test.txt" conflict occurs.


Best wishes.

Re: error 'Network connection closed unexpectedly' while svn update

[Nathan Hartman]

On Thu, Dec 5, 2019 at 1:30 PM Detlef Braungardt  wrote:
> we use TortoiseSVN for our development.
>
> But in a special situation we get an error 'Network connection closed 
> unexpectedly' during a svn update. The steps to reproduce the situation is 
> writed down in the Google Groups thread.
> I posted this error as a bug on the Tortoise list.
>
> https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/tortoisesvn/MSaacoX73DU
>
> After a short communication we found out that the bug is probably contained 
> in the libsvn.
>
> C:\Program Files\TortoiseSVN\bin>svn update "D:\Develop\FIRMA\trunk\Tests" -r 
> 15749
> Updating 'D:\Develop\FIRMA\trunk\Tests':
>
> svn: E235000: In file 
> '/build/subversion-Lv3Qkk/subversion-1.9.7/subversion/libsvn_fs_base/trail.c' 
> line 97: assertion failed (! bfd->in_txn_trail)
> svn: E210002: Network connection closed unexpectedly
>
> Can you help us to fix this bug?
> Thanks in advance.

Hello Detlef,

Thank you for your report.

I'll try the reproduction procedure you described in the Tortoise forum...

Thank you,
Nathan

error 'Network connection closed unexpectedly' while svn update

[Detlef Braungardt]

Hi everyone,


we use TortoiseSVN for our development.

But in a special situation we get an error 'Network connection closed unexpectedly' during a svn update. The 
steps to reproduce the situation is writed down in the Google Groups thread.

I posted this error as a bug on the Tortoise list.

   
https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/tortoisesvn/MSaacoX73DU

After a short communication we found out that the bug is probably contained in 
the libsvn.

   C:\Program Files\TortoiseSVN\bin>svn update "D:\Develop\FIRMA\trunk\Tests" 
-r 15749
   Updating 'D:\Develop\FIRMA\trunk\Tests':

   svn: E235000: In file 
'/build/subversion-Lv3Qkk/subversion-1.9.7/subversion/libsvn_fs_base/trail.c' 
line
   97: assertion failed (! bfd->in_txn_trail)
   svn: E210002: Network connection closed unexpectedly

Can you help us to fix this bug?
Thanks in advance.


Best regards

Detlef

--
*
*  Computerservice Braungardt   *
*
*  Dipl.-Wirtsch.-Inf.  Detlef Braungardt   *
*
* email:deve...@coseb.de*
* www:  www.CoseB.de*
*

Re: Remove revision range from repository

[Nico Kadel-Garcia]

On Thu, Dec 5, 2019 at 5:00 AM Josef Wolf  wrote:
>
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).

I'd urge you to to lock the old repository, build a new subversion
repository using "svnadmin dump", "svndumpfilter", and "svnadmin
load". Then switch your users to the new repository. Thatwill make
clear to your clients that are, in fact, using a different repository
with a different history and avoid confusion. Subversion is *very
picky* about deleting history, and there are philosophical and
security reasons to hinder the alteration of history as you are
looking for.

It sounds like you really want the "obliterate" feature to delete
accidentally committed sensitive files, which has never been
successfully done.

> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > 
> /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.

Why are you using "--incremental" ?

> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?
>
> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>  don'w want existing working copies to get into trouble?

The way you fix this is to *not use any* existing working copies. Make
people check out a new copy with the new uuid. You have zero control
over whether a working copy has those deleted revisisions.

I went through this with a bad commit in a source tree for a stock
exchange, and the cleanup when I failed to switch repos wasn't pretty.

Re: Remove revision range from repository

[Branko Čibej]

On 05.12.2019 13:01, Josef Wolf wrote:
> Thanks for your answer, Branko!
>
> On Thu, Dec 05, 2019 at 12:11:38PM +0100, Branko Čibej wrote:
>> On 05.12.2019 10:56, Josef Wolf wrote:
>>> I need to permanently remove a range of revisions from a repository, which 
>>> are
>>> not the latest.
>> Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
>> in the output.
> Unfortunately, svndumpfilter can do only path based filtering. Thus, I'd need
> another way to "inject" such empty revisions.

Yes, indeed, you have to do multiple dumps the way you've already
suggested, and for one range of revisions you'd just tell svndumpfilter
to filter all paths. It's not really elegant, but should work.

-- Brane

Re: Remove revision range from repository

[Josef Wolf]

Thanks for your answer, Branko!

On Thu, Dec 05, 2019 at 12:11:38PM +0100, Branko Čibej wrote:
> On 05.12.2019 10:56, Josef Wolf wrote:

> > I need to permanently remove a range of revisions from a repository, which 
> > are
> > not the latest.
> Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
> in the output.

Unfortunately, svndumpfilter can do only path based filtering. Thus, I'd need
another way to "inject" such empty revisions.

> > BTW: I guess, I'd need to set the uuid to the uuid of the old repository if 
> > I
> >  don'w want existing working copies to get into trouble?
> 
> Any existing working copies may be in trouble in any case. A working
> copy that contains an item from a revision that you'll exclude from the
> repository will no longer be able to commit or update.

I can make sure that no WC has such revisions.

> Other working copies will be fine (if you update the UUID).

OK. Sounds good.

-- 
Josef Wolf
j...@raven.inka.de

Re: Remove revision range from repository

[Branko Čibej]

On 05.12.2019 10:56, Josef Wolf wrote:
> Hello,
>
> I need to permanently remove a range of revisions from a repository, which are
> not the latest.
>
> None of the working copies have such a revision checked out (I guess, that
> might be a show-stopper).
>
>
> I know, I can do:
>
> # svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
> # svnadmin dump /original/repo -r2345:HEAD --incremental > 
> /path/to/dumpfile_2.dmp
> # svnadmin create /new/repo
> # svnadmin load /new/repo <  /path/to/dumpfile_1.dmp 
> # svnadmin load /new/repo <  /path/to/dumpfile_2.dmp
>
> But that would renumber the revisions of the second load command.
>
> Is there any way to insert empty revisions, so that the revision numbers would
> be stable?


Take a look at the 'svndumpfilter' tool. It can preserve empty revisions
in the output.


> BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
>  don'w want existing working copies to get into trouble?

Any existing working copies may be in trouble in any case. A working
copy that contains an item from a revision that you'll exclude from the
repository will no longer be able to commit or update. Other working
copies will be fine (if you update the UUID).

-- Brane

Remove revision range from repository

[Josef Wolf]

Hello,

I need to permanently remove a range of revisions from a repository, which are
not the latest.

None of the working copies have such a revision checked out (I guess, that
might be a show-stopper).


I know, I can do:

# svnadmin dump /original/repo -r0:1234  > /path/to/dumpfile_1.dmp
# svnadmin dump /original/repo -r2345:HEAD --incremental > 
/path/to/dumpfile_2.dmp
# svnadmin create /new/repo
# svnadmin load /new/repo <  /path/to/dumpfile_1.dmp 
# svnadmin load /new/repo <  /path/to/dumpfile_2.dmp

But that would renumber the revisions of the second load command.

Is there any way to insert empty revisions, so that the revision numbers would
be stable?

BTW: I guess, I'd need to set the uuid to the uuid of the old repository if I
 don'w want existing working copies to get into trouble?

-- 
Josef Wolf
j...@raven.inka.de