Re: PYTHON bindings

2022-11-16 Thread Yasuhito FUTATSUKI
Hello,

On 2022/11/17 6:01, Pavel Lyalyakin via users wrote:
> On Wed, Nov 16, 2022 at 10:36 PM Robert Fetter via users
>  wrote:
>>
>> I am trying to use ViewVC which provides a web inyerface to SVN.  It uses a 
>> shared library with Python which (I think) I've located.
>>
>> To run this, I have my own myviewvc.cgi script:
>>
>> #!/bin/sh
>> export PYTHONPATH=/usr/lib/python2.7/dist-packages/libsvn
>> /usr/lib/cgi-bin/viewvc.cgi
>>
>> But when I run this I get:
>>
>> ImportError: 
>> /usr/lib/python2.7/dist-packages/libsvn/_core.x86_64-linux-gnu.so: undefined 
>> symbol: svn_relpath__internal_style
>>
>> I submitted this to the ViewVC GitHub issue site for ViewVC and got back:
>>
>> This seems like a problem with Subversion's python bindings (which ViewVC 
>> depends on to do its thing for Subversion repositories), and specifically an 
>> issue with the packaging of those bindings on your specific platform. Please 
>> raise the issue with that community at 
>> https://subversion.apache.org/reporting-issues.html.
>>
>> I am running MX Linux which is based on Debian.
>>
>> Thank you for your attention to this matter.
> 
> I want to add the link to the mentioned issue:
> https://github.com/viewvc/viewvc/issues/304. The ticket has some
> additional details, so I feel that it needs to be in this thread for
> future reference.

Thank you for the link.

As I wrote there, I guess it is version miss match between Subversion's
shared libraries and Subversion SWIG Python bindings. That is, 
the /usr/lib/python2.7/dist-packages/libsvn/_core.x86_64-linux-gnu.so
in his environment is not built against installed version of Subversion.

External symbol "svn_relpath__internal_style" was appeared in
Subversion r1133964(in apache repository), between Subversion 1.6.0
and 1.7.0, and removed in r1850611, between Subversion 1.11.0 and 1.12.0.
(Although it seems svn_relpath__internal_style was incorrectly public
API, there is no api-errata about its removal...)

So I guess Robert uses Subversion 1.14.x on MX-21 and installed
python-subversion package for older releases (or copied svn and libsvn
Python modules from older environment).

Note: It seems library dependency of python-subversion deb package
for Debian 10 is incorrect. The version required for libsvn1 should
also "<< 1.12" because of the public API removal mentioned above.
(https://packages.debian.org/buster/python-subversion)

Cheers,
-- 
Yasuhito FUTATSUKI 


Re: PYTHON bindings

2022-11-16 Thread Pavel Lyalyakin via users
On Wed, Nov 16, 2022 at 10:36 PM Robert Fetter via users
 wrote:
>
> I am trying to use ViewVC which provides a web inyerface to SVN.  It uses a 
> shared library with Python which (I think) I've located.
>
> To run this, I have my own myviewvc.cgi script:
>
> #!/bin/sh
> export PYTHONPATH=/usr/lib/python2.7/dist-packages/libsvn
> /usr/lib/cgi-bin/viewvc.cgi
>
> But when I run this I get:
>
> ImportError: 
> /usr/lib/python2.7/dist-packages/libsvn/_core.x86_64-linux-gnu.so: undefined 
> symbol: svn_relpath__internal_style
>
> I submitted this to the ViewVC GitHub issue site for ViewVC and got back:
>
> This seems like a problem with Subversion's python bindings (which ViewVC 
> depends on to do its thing for Subversion repositories), and specifically an 
> issue with the packaging of those bindings on your specific platform. Please 
> raise the issue with that community at 
> https://subversion.apache.org/reporting-issues.html.
>
> I am running MX Linux which is based on Debian.
>
> Thank you for your attention to this matter.

I want to add the link to the mentioned issue:
https://github.com/viewvc/viewvc/issues/304. The ticket has some
additional details, so I feel that it needs to be in this thread for
future reference.

Thank you.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team


PYTHON bindings

2022-11-16 Thread Robert Fetter via users
I am trying to use ViewVC which provides a web inyerface to SVN. It uses 
a shared library with Python which (I think) I've located.


To run this, I have my own myviewvc.cgi script:

#!/bin/sh
export PYTHONPATH=/usr/lib/python2.7/dist-packages/libsvn
/usr/lib/cgi-bin/viewvc.cgi

But when I run this I get:

ImportError: /usr/lib/python2.7/dist-packages/libsvn/_core.x86_64-linux-gnu.so: 
undefined symbol: svn_relpath__internal_style

I submitted this to the ViewVC GitHub issue site for ViewVC and got back:

This seems like a problem with Subversion's python bindings (which 
ViewVC depends on to do its thing for Subversion repositories), and 
specifically an issue with the packaging of those bindings on your 
specific platform. Please raise the issue with that community at 
https://subversion.apache.org/reporting-issues.html 
.


I am running MX Linux which is based on Debian.

Thank you for your attention to this matter.




Re: SVN tool to get the Line of code

2022-11-16 Thread Pavel Lyalyakin via users
On Wed, Nov 16, 2022 at 3:08 PM Daniel Sahlberg
 wrote:
>
> Den tis 15 nov. 2022 kl 20:45 skrev 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
>>
>
> I can't really understand what you are looking for, it seems the question was 
> cut short in the middle.
>
> Kind regards,
> Daniel

I think that the user wants to see Lines of Code (LoC) metrics and
reports for the code stored in the SVN repositories. AFAIK, there are
several tools for this, but I cannot recommend any in particular. I'm
pretty sure that searching the web will give a lot of various options.

I also know that Visual Studio 2019 (16.4 and later) and Visual Studio
2022 support the "Lines of Source code" and "Lines of Executable
code" metrics. I haven't tried this myself, though. Relevant sections
of the Visual Studio documentation:

* Code metrics values:
  
https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-values

* How to: Generate code metrics data:
  
https://learn.microsoft.com/en-us/visualstudio/code-quality/how-to-generate-code-metrics-data

* Use the Code Metrics Results window:
  
https://learn.microsoft.com/en-us/visualstudio/code-quality/working-with-code-metrics-data

(Obviously this will work only for Visual Studio users).

Hope this helps!

--
With best regards,
Pavel Lyalyakin
VisualSVN Team


Re: SVN tool to get the Line of code

2022-11-16 Thread Daniel Sahlberg
Den tis 15 nov. 2022 kl 20:45 skrev 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
>
>
I can't really understand what you are looking for, it seems the question
was cut short in the middle.

Kind regards,
Daniel


RE: [EXTERNAL]: Re: Removing if unversioned files during a tree conflict resolve.

2022-11-16 Thread Marcel Delorme
HI Pavel,

Yes it seems you have a similar sequence. My two cents is that the tree 
resolver function doesn’t take unversioned files into account. As this relates 
to data loss this is a quite serious bug.

Thanks for your speedy response .

Kind regards,​​
[cid:image001.png@01D8F98E.09504F40]

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

From: Pavel Lyalyakin 
Sent: Tuesday, 15 November 2022 17:52
To: Marcel Delorme 
Cc: users@subversion.apache.org; Klaas de Jong 
Subject: [EXTERNAL]: Re: Removing if unversioned files during a tree conflict 
resolve.


CAUTION: This email originated from outside Ventura Systems. Do not click links 
or open attachments unless you recognize the sender and know the content is 
safe.
On Tue, Nov 15, 2022 at 7:36 PM Marcel Delorme 
mailto:m.delo...@venturasystems.com>> 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,
[cid:image001.png@01D8F98E.09504F40]

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


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: