SVN tool to get the Line of code

[JITHIN K]

Hello Team,

We are using Subversion for the source code management  ( Software
development ).
Are there any SVN tools available to calculate the line of code

Re: Removing if unversioned files during a tree conflict resolve.

[Pavel Lyalyakin via users]

On Tue, Nov 15, 2022 at 7:36 PM Marcel Delorme 
wrote:

> HI,
>
>
>
> I think we spotted a bug. The following sequence has been followed:
>
>- User 1 renames a svn folder and commits this
>- User 2 has unversioned files and uncommited files in the renamed
>folder
>- User 2 performs an update
>- Subversion encounter a tree conflict
>- All files are still on the disk during this step
>- Subversion solves three conflict.
>- unversioned files are removed from users 2 disk.
>
>
>
> The unversioned files are retained in the old folder with the old name
> when the same sequence is executed with no uncommited files on users 2
> computer.
>
>
>
> This all has been performed using : Svn, version 1.14.2 (r1899510)
>
>compiled Sep 24 2022, 10:21:16 on x86-microsoft-windows
>
>
>
> using Microsoft Windows [Version 10.0.19045.2130].
>
>
>
>
>
> Kind regards,
>
>
>
> *Marcel Delorme*
>
> Head of Software
>
> 
>
> Phone: +31 (0) 515 729433 <+31%20(0)%20515%20729433>
>
> Email: m.delo...@venturasystems.com
>
> Address: De Marne 216, 8701 MH Bolsward, Netherlands
>
> 
>
> 
>
>
>

It seems that this behavior reproduces on my side with svn, version 1.14.2
(r1899510) on Windows. I'm not sure if my reproduction script is correct,
but the behavior looks similar.

The file unversionedfile.txt is missing after the svn client automatically
solves the tree conflict when updating a working copy.

Here is the script (Windows Batch):
[[[
mkdir C:\marcel-bug-report
svnadmin create C:\marcel-bug-report\MyRepo
svn mkdir file:///C:/marcel-bug-report/MyRepo/MyDir -m "Adding a new
directory"

svn checkout file:///C:/marcel-bug-report/MyRepo/
C:\marcel-bug-report\working-copy-one
echo foo > C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
svn add C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
svn commit C:\marcel-bug-report\working-copy-one\ -m "Adding a new file"
echo bar > C:\marcel-bug-report\working-copy-one\MyDir\myfile.txt
echo baz > C:\marcel-bug-report\working-copy-one\MyDir\unversionedfile.txt

svn move file:///C:/marcel-bug-report/MyRepo/MyDir
file:///C:/marcel-bug-report/MyRepo/RenamedDir -m "Renaming a directory"

svn update C:\marcel-bug-report\working-copy-one
]]]

[[[
C:\Users\Lyalyakin>svn update C:\marcel-bug-report\working-copy-one
Updating 'C:\marcel-bug-report\working-copy-one':
   C C:\marcel-bug-report\working-copy-one\MyDir
AC:\marcel-bug-report\working-copy-one\RenamedDir
AC:\marcel-bug-report\working-copy-one\RenamedDir\myfile.txt
Updated to revision 3.
Summary of conflicts:
  Tree conflicts: 1
Searching tree conflict details for
'C:\marcel-bug-report\working-copy-one\MyDir' in repository:
Checking r3... done
Tree conflict on 'C:\marcel-bug-report\working-copy-one\MyDir':
Directory updated from r1 to r3 was moved to '^/RenamedDir' by Lyalyakin in
r3.
A directory containing uncommitted changes was found in the working copy.
Applying recommended resolution 'Move and merge':
   C C:\marcel-bug-report\working-copy-one\RenamedDir\myfile.txt
At revision 3.
Tree conflict at 'C:\marcel-bug-report\working-copy-one\MyDir' marked as
resolved.
Summary of conflicts:
  Tree conflicts: 1 remaining (and 1 already resolved)
]]]
[[[
C:\Users\Lyalyakin>svn status -v C:\marcel-bug-report\working-copy-one
 33 Lyalyakin
 C:\marcel-bug-report\working-copy-one
 33 Lyalyakin
 C:\marcel-bug-report\working-copy-one\RenamedDir
  C  32 Lyalyakin
 C:\marcel-bug-report\working-copy-one\RenamedDir\myfile.txt
  >   local file unversioned, incoming file add upon update
Summary of conflicts:
  Tree conflicts: 1
]]]

-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team

Removing if unversioned files during a tree conflict resolve.

[Marcel Delorme]

HI,

I think we spotted a bug. The following sequence has been followed:

  *   User 1 renames a svn folder and commits this
  *   User 2 has unversioned files and uncommited files in the renamed folder
  *   User 2 performs an update
  *   Subversion encounter a tree conflict
  *   All files are still on the disk during this step
  *   Subversion solves three conflict.
  *   unversioned files are removed from users 2 disk.

The unversioned files are retained in the old folder with the old name when the 
same sequence is executed with no uncommited files on users 2 computer.

This all has been performed using : Svn, version 1.14.2 (r1899510)
   compiled Sep 24 2022, 10:21:16 on x86-microsoft-windows

using Microsoft Windows [Version 10.0.19045.2130].


Kind regards,​​
[cid:image001.png@01D8F908.E9F7DEE0]

Marcel Delorme
Head of Software
[cid:image002.png@01D8F908.E9F7DEE0]
Phone: +31 (0) 515 729433
Email: m.delo...@venturasystems.com
Address: De Marne 216, 8701 MH Bolsward, Netherlands
[cid:image003.png@01D8F908.E9F7DEE0]
[cid:image004.png@01D8F908.E9F7DEE0]

Re: svnsync: E120106: ra_serf: The server sent a truncated HTTP response body.

[Pavel Lyalyakin via users]

On Tue, Nov 15, 2022 at 3:56 PM JITHIN K  wrote:
>
> @pavel.lyalya...@visualsvn.com
>
> This works for me. Thank you.
>
> Regards,
> Jithin K

Sure thing! I'm glad that helped you out.


On Tue, Nov 15, 2022 at 3:56 PM JITHIN K  wrote:
>
> @pavel.lyalya...@visualsvn.com
>
> This works for me. Thank you.
>
> Regards,
> Jithin K
>
> On Tue, Nov 15, 2022 at 2:29 PM JITHIN K  wrote:
>>
>> Thanks for your mail. I will try this option.
>>
>>
>> On Mon, Nov 14, 2022 at 8:59 PM Pavel Lyalyakin 
>>  wrote:
>>>
>>> On Mon, Nov 14, 2022 at 4:31 PM JITHIN K  wrote:
>>> >
>>> > Hello Team,
>>> >
>>> > I use Subversion 1.13 in Ubuntu 20.04.5 LTS and sync a repository size of 
>>> > 300GB to a mirror server ( same version of SVN and OS ).
>>> >
>>> > I get the following warning svnsync: E120106: ra_serf: The server sent a 
>>> > truncated HTTP response body every time ( I had to take a dump of 
>>> > specific revisions and load it in the mirror server ).  Did anyone face 
>>> > this problem while in sync? Is there any solution?
>>> >
>>> > Thank you.
>>> > Jithin K
>>>
>>> svnsync works inefficiently when both URLs (source and destination) in
>>> the command use HTTP(S). The timeout issue can occur when both URLs
>>> use HTTP(S):
>>> 1. The destination repository receives a transaction and has to commit
>>> it. This operation can take some time.
>>> 2. svnsync keeps the connection to both source and destination
>>> repositories over HTTP(S) and waits for a response from the
>>> destination server. The transaction is still being committed.
>>> 3. The source server closes the connection due to a timeout because
>>> svnsync was still waiting for the response from the destination
>>> server.
>>>
>>> To solve this problem, you need to switch the local URL to file://.
>>> See examples below.
>>>
>>> You normally run svnsync sync on one of two servers involved in the
>>> replication (source or target/destination). And the URL to a local
>>> repository has to use the file:// direct local access protocol. Local
>>> URL means the file:// URL to a repository on the server's disk.
>>>
>>> When one of the URLs is local, svnsync does not need to contact both
>>> servers remotely via HTTP(S) and one of the repositories is always
>>> accessed directly on disk. This rules out potential timeout issues
>>> such as the one described in your email.
>>>
>>> Here is a syntax example from SVNBook:
>>> [[[
>>> svnsync synchronize DEST_URL [SOURCE_URL]
>>> ]]]
>>>
>>> The target or source repository URL has to be local:
>>>
>>> If you run this command on there source server, then the SOURCE_URL
>>> has to be local:
>>> [[[
>>> svnsync sync "https://svn1.example.com/svn/MyRepo";
>>> "file:///C:/Repositories/MyRepo"
>>> ]]]
>>>
>>> If you run this command on the target server then the DEST_URL has to be 
>>> local:
>>> [[[
>>> svnsync sync "file:///C:/Repositories/MyRepo"
>>> "https://svn1.example.com/svn/MyRepo";
>>> ]]]
>>>
>>> Based on my answer at https://stackoverflow.com/a/70059081.
>>>
>>>
>>> --
>>> With best regards,
>>> Pavel Lyalyakin
>>> VisualSVN Team
>>
>>


-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: svnsync: E120106: ra_serf: The server sent a truncated HTTP response body.

[JITHIN K]

@pavel.lyalya...@visualsvn.com

This works for me. Thank you.

Regards,
Jithin K

On Tue, Nov 15, 2022 at 2:29 PM JITHIN K  wrote:

> Thanks for your mail. I will try this option.
>
>
> On Mon, Nov 14, 2022 at 8:59 PM Pavel Lyalyakin <
> pavel.lyalya...@visualsvn.com> wrote:
>
>> On Mon, Nov 14, 2022 at 4:31 PM JITHIN K  wrote:
>> >
>> > Hello Team,
>> >
>> > I use Subversion 1.13 in Ubuntu 20.04.5 LTS and sync a repository size
>> of 300GB to a mirror server ( same version of SVN and OS ).
>> >
>> > I get the following warning svnsync: E120106: ra_serf: The server sent
>> a truncated HTTP response body every time ( I had to take a dump of
>> specific revisions and load it in the mirror server ).  Did anyone face
>> this problem while in sync? Is there any solution?
>> >
>> > Thank you.
>> > Jithin K
>>
>> svnsync works inefficiently when both URLs (source and destination) in
>> the command use HTTP(S). The timeout issue can occur when both URLs
>> use HTTP(S):
>> 1. The destination repository receives a transaction and has to commit
>> it. This operation can take some time.
>> 2. svnsync keeps the connection to both source and destination
>> repositories over HTTP(S) and waits for a response from the
>> destination server. The transaction is still being committed.
>> 3. The source server closes the connection due to a timeout because
>> svnsync was still waiting for the response from the destination
>> server.
>>
>> To solve this problem, you need to switch the local URL to file://.
>> See examples below.
>>
>> You normally run svnsync sync on one of two servers involved in the
>> replication (source or target/destination). And the URL to a local
>> repository has to use the file:// direct local access protocol. Local
>> URL means the file:// URL to a repository on the server's disk.
>>
>> When one of the URLs is local, svnsync does not need to contact both
>> servers remotely via HTTP(S) and one of the repositories is always
>> accessed directly on disk. This rules out potential timeout issues
>> such as the one described in your email.
>>
>> Here is a syntax example from SVNBook:
>> [[[
>> svnsync synchronize DEST_URL [SOURCE_URL]
>> ]]]
>>
>> The target or source repository URL has to be local:
>>
>> If you run this command on there source server, then the SOURCE_URL
>> has to be local:
>> [[[
>> svnsync sync "https://svn1.example.com/svn/MyRepo";
>> "file:///C:/Repositories/MyRepo"
>> ]]]
>>
>> If you run this command on the target server then the DEST_URL has to be
>> local:
>> [[[
>> svnsync sync "file:///C:/Repositories/MyRepo"
>> "https://svn1.example.com/svn/MyRepo";
>> ]]]
>>
>> Based on my answer at https://stackoverflow.com/a/70059081.
>>
>>
>> --
>> With best regards,
>> Pavel Lyalyakin
>> VisualSVN Team
>>
>
>

Questions about setting up Subversion Server

[Felix Natter]

hello SVN Users,

I have set up a basic SVN Server with svn+ssh:// auth (System users with 
LDAP)

by wrapping svnserve [1]

I have a few questions for which I could not find answers in the manual:

- In my svnserve wrapper I call this:

exec /usr/bin/svnserve "$@" -r /repos

-> Does the (Linux-) system automatically call this with "-t"?

- If I use ssh auth (svn+ssh://), do I have to change the options in 
/svnserve.conf,
 like anon-access=none? (I just want access based on file system 
permissions, and no

 anon access)

- I am migrating from a 3rd party server which used a different 
directory structure,

  and system users (no LDAP), but also svn+ssh://.
  Can I keep all the history, even if some old users in the 3rd party 
server are not
  available in the new LDAP auth? (but of course the user names of 
existing users are kept)
  In other words: does a SVN Server store the user information 
(history) as strings or

  something else that is linked to accounts?

- I am using strict permissions for two (LDAP-)groups in the base 
directories for the repos
 (/repos/students, /repos/employees). The Howto I used [1] is using 
"umask 002" in the

 wrapper. I think for my case (groups) "007" is sufficient, right?

[1] https://www.startupcto.com/server-tech/subversion/setting-up-svn

Please CC: me, as I am not subscribed.

Many Thanks and Best Regards!

Felix

--

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone    :   +49 228 5348 0430
Direct   :   +49 228 4097 7118
Email    : felix.nat...@sidact.com
Web  : http://www.sidact.com/



OpenPGP_signature
Description: OpenPGP digital signature

Re: svnsync: E120106: ra_serf: The server sent a truncated HTTP response body.

[JITHIN K]

Thanks for your mail. I will try this option.


On Mon, Nov 14, 2022 at 8:59 PM Pavel Lyalyakin <
pavel.lyalya...@visualsvn.com> wrote:

> On Mon, Nov 14, 2022 at 4:31 PM JITHIN K  wrote:
> >
> > Hello Team,
> >
> > I use Subversion 1.13 in Ubuntu 20.04.5 LTS and sync a repository size
> of 300GB to a mirror server ( same version of SVN and OS ).
> >
> > I get the following warning svnsync: E120106: ra_serf: The server sent a
> truncated HTTP response body every time ( I had to take a dump of specific
> revisions and load it in the mirror server ).  Did anyone face this problem
> while in sync? Is there any solution?
> >
> > Thank you.
> > Jithin K
>
> svnsync works inefficiently when both URLs (source and destination) in
> the command use HTTP(S). The timeout issue can occur when both URLs
> use HTTP(S):
> 1. The destination repository receives a transaction and has to commit
> it. This operation can take some time.
> 2. svnsync keeps the connection to both source and destination
> repositories over HTTP(S) and waits for a response from the
> destination server. The transaction is still being committed.
> 3. The source server closes the connection due to a timeout because
> svnsync was still waiting for the response from the destination
> server.
>
> To solve this problem, you need to switch the local URL to file://.
> See examples below.
>
> You normally run svnsync sync on one of two servers involved in the
> replication (source or target/destination). And the URL to a local
> repository has to use the file:// direct local access protocol. Local
> URL means the file:// URL to a repository on the server's disk.
>
> When one of the URLs is local, svnsync does not need to contact both
> servers remotely via HTTP(S) and one of the repositories is always
> accessed directly on disk. This rules out potential timeout issues
> such as the one described in your email.
>
> Here is a syntax example from SVNBook:
> [[[
> svnsync synchronize DEST_URL [SOURCE_URL]
> ]]]
>
> The target or source repository URL has to be local:
>
> If you run this command on there source server, then the SOURCE_URL
> has to be local:
> [[[
> svnsync sync "https://svn1.example.com/svn/MyRepo";
> "file:///C:/Repositories/MyRepo"
> ]]]
>
> If you run this command on the target server then the DEST_URL has to be
> local:
> [[[
> svnsync sync "file:///C:/Repositories/MyRepo"
> "https://svn1.example.com/svn/MyRepo";
> ]]]
>
> Based on my answer at https://stackoverflow.com/a/70059081.
>
>
> --
> With best regards,
> Pavel Lyalyakin
> VisualSVN Team
>

Re: svnsync: E120106: ra_serf: The server sent a truncated HTTP response body.

[JITHIN K]

Thanks for your response. I have checked the revision size which is around
2.5GB.  I don't think its a revision size problem.

On Mon, Nov 14, 2022 at 7:29 PM Daniel Sahlberg 
wrote:

> Den mån 14 nov. 2022 kl 13:31 skrev JITHIN K :
>
>> Hello Team,
>>
>> I use Subversion 1.13 in Ubuntu 20.04.5 LTS and sync a repository size of
>> 300GB to a mirror server ( same version of SVN and OS ).
>>
>> I get the following warning svnsync: E120106: ra_serf: The server sent a
>> truncated HTTP response body every time ( I had to take a dump of
>> specific revisions and load it in the mirror server ).  Did anyone face
>> this problem while in sync? Is there any solution?
>>
>
> Do you see any common pattern with the revisions causing trouble? Possibly
> if they are very large or contain a lot of files.
>
> This was mentioned once before on the list [1]. I don't see if the user
> found a way around it, but he mentions that the troublesome revisions were
> large imports.
>
> Kind regards,
> Daniel
>
> [1] https://lists.apache.org/thread/cmc872c221o0r5mvhk16lcjfnd4xwtl1
>
>
>>