Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

Daniel Shahaf  писал(а) в своём письме Wed, 14 Jun  
2017 20:47:16 +0300:



The first column of `status` output reports not only the in-wc.db status
(e.g., 'A' / 'D' / 'R'), but also the on-disk status, e.g., '?' and '!'.
For example, compare how after 'svn add iota && /bin/rm iota', iota is
reported with status '!' rather than 'A'.  So I think it would make
sense to have a file that is scheduled to be deleted, but exists on
disk, to be reported as, say, a lowercase 'd'.

In mine case it's `svn remove iota && type nul > iota`
But i think this is almost the same case.

RE: FW: Error running make for subversion

[Joseph, Anselm]

Thanks Daniel.
Ran the tests manually as suggested:
<-- ~:/opt/eai/ci/subversion/subversion/tests/cmdline -->
$  ./basic_tests.py --bin=/usr/local/bin
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512
Traceback (most recent call last):
  File "./basic_tests.py", line 3148, in 
svntest.main.run_tests(test_list)
  File "/opt/eai/ci/subversion/subversion/tests/cmdline/svntest/main.py", line 
2062, in run_tests
sys.exit(execute_tests(test_list, serial_only))
  File "/opt/eai/ci/subversion/subversion/tests/cmdline/svntest/main.py", line 
2175, in execute_tests
raise Exception('Logging occurred before configuration. Some code'
Exception: Logging occurred before configuration. Some code path needs to be 
fixed. Examine the log output to find what/where logged something.

$ APACHE_MPM=▒^▒▒ ./davautocheck.sh
davautocheck.sh: Using '/opt/eai/ci/httpd-2.4.25/apache/bin/apxs'...
Use of uninitialized value in concatenation (.) or string at 
/opt/eai/ci/httpd-2.4.25/apache/bin/apxs line 222.
Use of uninitialized value in concatenation (.) or string at 
/opt/eai/ci/httpd-2.4.25/apache/bin/apxs line 222.
Use of uninitialized value in concatenation (.) or string at 
/opt/eai/ci/httpd-2.4.25/apache/bin/apxs line 222.
davautocheck.sh: HTTPD '/opt/eai/ci/httpd-2.4.25/apache/bin/httpd' doesn't 
start properly
HTTPD stopped.

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Wednesday, June 14, 2017 3:34 PM
To: Joseph, Anselm
Cc: users@subversion.apache.org; Philip Martin
Subject: Re: FW: Error running make for subversion

CAUTION - EXTERNAL EMAIL



Joseph, Anselm wrote on Wed, 14 Jun 2017 18:54 +:
> Thanks for the reply, Daniel.
> Update:
> I pointed the install to the older gcc 4.2.0 with same results:
> /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0
> $ ls
> include  install-tools  libgcc.a  libgcc_eh.a  libgcc_s.a  libgcov.a  
> libsupc++.a  ppc64  pthread
>
> Below, I ran 'make check' to test the results of make (since I could not find 
> a significant error in make output) and got the following:
> $ make > make.log 2>&1
> <-- ~:/opt/eai/ci/subversion -->
> $ make check
> ERROR:root:code for hash md5 was not found.
> [053/109] 
> x509-test.
> ..FAILURE
> [054/109] authz_tests.pymake: 1254-004 The error code from the last command 
> is 1.
>
>
> Stop.
>
> Any incidence on the result I see with 'make install'?
> Thanks,
> Anselm

This error means that «python -c 'from hashlib import md5'» fails on your 
system.  It is does not shed light on the mod_dav_svn problems.¹

You can try running the tests manually with 'cd subversion/tests/cmdline && 
./basic_tests.py', possibly passing 

Re: FW: Error running make for subversion

[Daniel Shahaf]

Joseph, Anselm wrote on Wed, 14 Jun 2017 18:54 +:
> Thanks for the reply, Daniel.
> Update: 
> I pointed the install to the older gcc 4.2.0 with same results:
> /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0
> $ ls
> include  install-tools  libgcc.a  libgcc_eh.a  libgcc_s.a  libgcov.a  
> libsupc++.a  ppc64  pthread
> 
> Below, I ran 'make check' to test the results of make (since I could not find 
> a significant error in make output) and got the following:
> $ make > make.log 2>&1
> <-- ~:/opt/eai/ci/subversion -->
> $ make check
> ERROR:root:code for hash md5 was not found.
> [053/109] 
> x509-test...FAILURE
> [054/109] authz_tests.pymake: 1254-004 The error code from the last command 
> is 1.
> 
> 
> Stop.
> 
> Any incidence on the result I see with 'make install'?
> Thanks,
> Anselm

This error means that «python -c 'from hashlib import md5'» fails on your
system.  It is does not shed light on the mod_dav_svn problems.¹

You can try running the tests manually with 'cd subversion/tests/cmdline &&
./basic_tests.py', possibly passing --bin=/usr/local/bin to test
already-installed binaries.  (That will run just a subset of the tests.)

It would also be interesting to see how far davautocheck reaches (it is
invoked as «make davautocheck APACHE_MPM=…» or «cd subversion/tests/cmdline &&
APACHE_MPM=… ./davautocheck.sh»).  I'm curious to see whether it will
successfully set up an httpd instance or not.  Note that if it
successfully sets up httpd, it will fail over the hashlib issue after
that.

Cheers,

Daniel

¹ It _could_ conceivably be related, since mod_dav_svn is a shared
library for httpd and the hashlib module is sometimes implemented as a
shared library for the CPython interpreter — but you'd probably have
noticed if multiple programs had trouble loading shared libraries.

RE: FW: Error running make for subversion

[Joseph, Anselm]

Thanks for the reply, Daniel.
Update: 
I pointed the install to the older gcc 4.2.0 with same results:
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0
$ ls
include  install-tools  libgcc.a  libgcc_eh.a  libgcc_s.a  libgcov.a  
libsupc++.a  ppc64  pthread

Below, I ran 'make check' to test the results of make (since I could not find a 
significant error in make output) and got the following:
$ make > make.log 2>&1
<-- ~:/opt/eai/ci/subversion -->
$ make check
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/hashlib.py", line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/opt/freeware/lib/python2.7/hashlib.py", line 97, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512
[001/109] 
auth-test...FAILURE
[002/109] 
bit-array-test..FAILURE
[003/109] 
cache-test..FAILURE
[004/109] 
checksum-test...FAILURE
[005/109] 
client-test.FAILURE
[006/109] 
compat-test.FAILURE
[007/109] 
config-test.FAILURE
[008/109] 
conflict-data-test..FAILURE
[009/109] 
crypto-test.FAILURE
[010/109] 
db-test.FAILURE
[011/109] 
diff-diff3-test.FAILURE
[012/109] 
dirent_uri-test.FAILURE
[013/109] 
dump-load-test..FAILURE
[014/109] 
entries-compat-test.FAILURE
[015/109] 
error-code-test.FAILURE
[016/109] 
error-test..FAILURE
[017/109] 

Re: "svn status" does not show unversioned items been deleted but not committed

[Daniel Shahaf]

Andrey wrote on Wed, 14 Jun 2017 14:31 +0300:
> Bert Huijben  писал(а) в своём письме Wed, 14 Jun 2017  
> 13:29:18 +0300:
> 
> >> So, what about this issues? I see it as not opened yet. Will it be  
> >> fixed?
> >
> > It is not easy to really describe 'the issue'.
> >
> > How would you handle 'svn rm --keep-local ', where the current
> > behavior is the expected behavior.
> i think `svn status` must at least warn user that deleted file has been  
> locally replaced

The first column of `status` output reports not only the in-wc.db status
(e.g., 'A' / 'D' / 'R'), but also the on-disk status, e.g., '?' and '!'.
For example, compare how after 'svn add iota && /bin/rm iota', iota is
reported with status '!' rather than 'A'.  So I think it would make
sense to have a file that is scheduled to be deleted, but exists on
disk, to be reported as, say, a lowercase 'd'.

If we were designing from scratch, it might have been better to have
two columns — one for the on-disk status and one for the in-db status — 
so an added file that exists on disk would be 'AA' and an added file
that is missing would be 'A!', and similarly we could have ' ?' for
unversioned and 'D?' for deleted-in-db-but-exists-on-disk.  That would
have disentangled the overloaded first column.

> Backwards compatibility is important, availability to loose local changes  
> w/o a warning even more important than compatibility

We broke compatibility before, back in 1.6 when we added the seventh
column.  We can decide to do so again.

Why don't we continue this thread on dev@?  This is now a design
question, not a usage question.

Cheers,

Daniel

Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

Bert Huijben  писал(а) в своём письме Wed, 14 Jun 2017  
13:29:18 +0300:


So, what about this issues? I see it as not opened yet. Will it be  
fixed?


It is not easy to really describe 'the issue'.

How would you handle 'svn rm --keep-local ', where the current
behavior is the expected behavior.
i think `svn status` must at least warn user that deleted file has been  
locally replaced


In Subversion <= 1.6 versioned directories would always be available  
locally
until the delete was committed and we explicitly handled this case this  
way.




On the API level there is no real issue, as the information that  
something

exists locally is already available there...
So the thing that is missing is how to show this information from the  
'svn'

tool without breaking backwards compatibility.

Bert
Backwards compatibility is important, availability to loose local changes  
w/o a warning even more important than compatibility

RE: "svn status" does not show unversioned items been deleted but not committed

[Bert Huijben]

> -Original Message-
> From: Andrey [mailto:an...@inbox.ru]
> Sent: woensdag 14 juni 2017 12:22
> To: users@subversion.apache.org
> Subject: Re: "svn status" does not show unversioned items been deleted but
> not committed
> 
> So, what about this issues? I see it as not opened yet. Will it be fixed?

It is not easy to really describe 'the issue'.

How would you handle 'svn rm --keep-local ', where the current
behavior is the expected behavior.

In Subversion <= 1.6 versioned directories would always be available locally
until the delete was committed and we explicitly handled this case this way.



On the API level there is no real issue, as the information that something
exists locally is already available there...
So the thing that is missing is how to show this information from the 'svn'
tool without breaking backwards compatibility.

Bert

Re: "svn status" does not show unversioned items been deleted but not committed

[Andrey]

So, what about this issues? I see it as not opened yet. Will it be fixed?