can be add
by passing exact the file name to svn add, e.g. with most
shells on Unix like OS,
$ svn add '/Users/abc/trunk/aa '
or
$ svn add /Users/abc/trunk/aa\
~ one space here.
Cheers,
--
Yasuhito FUTATSUKI
n diff -c 2237 --diff-cmd=bin/show_args.sh file:///var/db/svn/sysadmin/
Index: vendor/FreeBSD/releng/14.0/root
===
--- vendor/FreeBSD/releng/14.0/root (revision 2236)
+++ vendor/FreeBSD/releng/14.0/root (revision 2237)
Property changes on: vendor/FreeBSD/releng/14.0/root
___
Added: svn:ignore
## -0,0 +1,10 ##
+.bundle
+.cargo
+.config
+.history
+.lesshst
+.local
+.lsof_*
+.mysql_history
+.pgsql_history
+.python_history
]]]
Cheers,
--
Yasuhito FUTATSUKI
t;>
>>> Michael
>>>
>>
>> Hi Michael,
>>
>> Did this same invocation work as expected with an earlier SVN release? If
>> so, which release was that? That will help immensely...
>
> I dare to say that it has never worked. Tried 1.10.x and 1.11.x, both have
> the same issue.
As far as I saw subversion-1.6.0.tar.bz2, it uses autoconf 2.63 and
help string was expanded to "cat <<\_ACEOF ..." so the shell variables
cannot be replaced.
Cheers,
--
Yasuhito FUTATSUKI
Hello,
On 2024/09/25 19:04, Vincent Lefevre wrote:
> Hi,
>
> On 2024-09-25 11:58:43 +0900, Yasuhito FUTATSUKI wrote:
>> On 2024/09/25 9:17, Vincent Lefevre wrote:
>>
>> > Checking the error message might not be future-proof.
>>
>> Then, check the error
;:
if len(sys.argv) != 2:
print('Usage: %s ' % sys.argv[0])
exit(2)
try:
print('yes' if is_path_within_wc(sys.argv[1]) else 'no')
except Exception as e:
print('error:', e)
exit(1)
]]]
Cheers,
--
Yasuhito FUTATSUKI
and* having much time *and* having
ability to write the code for it. So both the worry for the health
of the project and stability of the code of master branch seems
to be correct for me.
Cheers,
--
Yasuhito FUTATSUKI
dings. If you are using Subversion
installed by apt, it might be available as python-subversion.
https://packages.ubuntu.com/focal/python-subversion
If you want to run ViewVC on Python 3.x, you need to use snapshot
on master branch (unreleased 1.3-dev) from https://viewvc.org/nightly/
or get it from git repo. In the case, you need Subversion >= 1.14
because of Python 3 bindings support.
Cheers,
--
Yasuhito FUTATSUKI
-2020-17525,
CVE-2021-28544, and CVE-2022-24070. However those all had been fixed
in 1.13.0-3ubuntu0.2.
Cheers,
--
Yasuhito FUTATSUKI /
The message below seem to be intended to be sent not to me but
the to users@ list, so I forward.
-- Yasuhito FUTATSUKI
Forwarded Message
Return-Path:
References:
<6cdf06d3-7080-8edc-97b6-dcc00df31...@poem.co.jp>
In-Reply-To: <6cdf06d3-7080-8edc-97b6-dcc00df31...@p
asiest way. However I can't see you have no problem on upgrading
or not.
Cheers,
--
Yasuhito FUTATSUKI /
You are welcome. Good to know you could find the cause.
On 2023/10/17 22:43, Paul S. Aspinwall wrote:
Hi,
Many thanks for your reply. You are correct - ssh was surreptitiously using
another old version of svn!
- Paul.
On 10/16/23 19:22, Yasuhito FUTATSUKI wrote:
Hello,
On 2023/10/16 23:06
s a bug??
If you are surely using 1.14.2 of svnserve, then it can be broken.
In this case I'm not sure I can answer your question.
What is the result of 'svnadmin info' for your repository?
Cheers,
--
Yasuhito FUTATSUKI
Hello,
On 2023/09/01 18:04, Magnus Lyrberg wrote:
Unfortunately 'svnadmin load' ignores the revision information in the dump
file. If the new repository is empty it will start with revision 1
regardless of
what the dump file says.
I made a quick test to verify this:
svnadmin load /var/svn/repo
kage
available for Ubuntu 22.04, because the ViewCVS project have not
released ViewVC which support Python 3.X yet, and the ViewVC
package maintainer on Debian wasn't interested in 1.3-dev version
of ViewVC.
See also:
https://github.com/viewvc/viewvc/issues/310
Cheers,
--
Yasuhito FUTATSUKI
dialog window of TortoiseSVN, but I don't
know how it implements those options. So I can't answer
your question directly.
If you want to know what it exactly does, the source code
will tell you.
Cheers,
--
Yasuhito FUTATSUKI
f 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
ack vulnerable serves, but I didn't
analyze the code, because we can use Expat which is not affected
by CVE-2016-0718.
Cheers,
--
Yasuhito FUTATSUKI
${revision_base}" = "${revision_head}" ; then exit 0; fi
${svn} log -r $((${revision_base}+1)):HEAD --incremental "$1"
]]]
or if you allowe to be shown 'No such revision' error:
[[[
#!/bin/sh
# if This is not in your command search paths, please change it.
svn=svn
${svn} log -r $((`${svn} info -r BASE --show-item revision "$1"`+1)):HEAD \
--incremental "$1"
]]]
or check the BASE revision number in advance and filter out the log
on its revision number from the result of 'svn log -r BASE:HEAD'.
In addition, to get "exactly" what you want, you need forbidding
everyone to commit change on the target path just after you examine
the HEAD revision until you run 'svn update', and I think it is not
good idea.
Cheers,
--
Yasuhito FUTATSUKI
change that was
> already taken into account.
> Is that a bug in svn or am I misunderstanding something? I would have
> expected an empty result, given that there was no incoming change
> during the next svn up.
In this case, both of "BASE" and "HEAD" revisions are 103730, so it
is equivalent to 'svn log -r 103730:103730', and in r103730, there
is some changes in '.'. That is why it showed the log message.
Cheers,
--
Yasuhito FUTATSUKI
:\TMP"(netware only)
"/tmp"
"/var/tmp"
"/usr/tmp"
P_tmpdir (POSIX define)
`pwd`
(https://svn.apache.org/viewvc?view=revision&revision=818841)
So $TMPDIR will be used if it is set, although it might not be user case.
Cheers,
--
Yasuhito FUTATSUKI
key are quite
> > dangerous.
>
> It's no need to give write access for the purpose of this thread
> and threre is a way to give read only permisson, but it is off topic.
I'm very sorry but I overlooked it contains 'commit back' operation.
So this part was incorrect.
Cheers,
--
Yasuhito FUTATSUKI
In article
nka...@gmail.com writes:
> Sorry for message without content, re-sending with content.
>
> > On Mon, Feb 22, 2021 at 3:25 PM Yasuhito FUTATSUKI
>
> > > If you want to use ssh key other than default key or alternative tcp port
> > > other than 22, y
.
I don't think there is a safe way that a process kicked by cron can
get credentials but other processes which have same privilage can't
get them.
Cheers,
--
Yasuhito FUTATSUKI
htricks
If you want to use ssh key other than default key or alternative tcp port
other than 22, you can use them by overriding ssh tunnel setting with SVN_SSH
environment variable or config file, etc. (Of course, if you want to use non
standard port for ssh connection you also need to change configuration of
sshd on server side).
Cheers,
--
Yasuhito FUTATSUKI
On 2021/02/17 6:17, Lev Serebryakov wrote:
> On 16.02.2021 23:52, Yasuhito FUTATSUKI wrote:
>>
>
>>> However, I don't think it is not an issue of Subversion release tarball
>>> but an issue of FreeBSD ports.
>>
>> This may be incorrect. It seem
ports which support both of Python 2 bindings and Python 3 bindings.)
I tried it and found:
[[[
$ ls -l subversion/bindings/swig/python/libsvn/*.so
lrwxr-xr-x 1 futatuki staff7 13 Feb 17 05:12
subversion/bindings/swig/python/libsvn/*.so@ -> ../.libs/*.so
]]]
If copy-swig-py target executed before building
subversion/bindings/swig/python/.lib/*.so, this can be occured.
Cheers,
--
Yasuhito FUTATSUKI
.so
]]]
On install, *.so modules will be installed in the same directory in
libsvn/*.py, so I think they works without trouble.
(I'm sorry, but I didn't try fresh ports tree yet because I'm using custom
ports which support both of Python 2 bindings and Python 3 bindings.)
Cheers,
--
Yasuhito FUTATSUKI
d000)
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0 (0x801592000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8015d3000)
libthr.so.3 => /lib/libthr.so.3 (0x8015e1000)
libc.so.7 => /lib/libc.so.7 (0x80024e000)
libssl.so.111 => /usr/lib/libssl.so.111 (0x80160e000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x8016a6000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801998000)
libgdbm.so.6 => /usr/local/lib/libgdbm.so.6 (0x8019b9000)
libm.so.5 => /lib/libm.so.5 (0x8019ca000)
]]]
Cheers,
--
Yasuhito FUTATSUKI
tion(&repos_relpath,
&peg_rev,
&node_kind,
conflict,
]]]
Cheers,
--
Yasuhito FUTATSUKI
wc-ng, finding the pristine file is more
> complicated. Do I have to learn how to read wc-ng? Or is there any easier
> way?
How about using "svn export -rBASE filea.cpp some_safer_path"
to obtain filea.cpp (orig)?
Cheers,
--
Yasuhito FUTATSUKI
of "C" 15 years ago at university; I ha
>ve done mostly OOP since then (C++, C++ .Net, C#, VBA). I am thinking about co
>ntributing to SVN, but I doubt I will be of great help in "C" language.
Roughly speaking, C++ is a superset of C, so I believe you can do it,
if you want to do.
Please see 'Apache Subversion Community Guide (aka "HACKING")'[1] for
how to contribute, including how to read the Subversion source code.
[1] https://subversion.apache.org/docs/community-guide/
Cheers,
--
Yasuhito FUTATSUKI
gument (HEAD) given to -c
>
> Did I misunderstand the documentaiton, or is it a bug?
As the error message says, '-c' option accepts only numeric revision.
It seems it is a kind of bug that the help text is not kind enough.
Cheers,
--
Yasuhito FUTATSUKI
rsion>.
Although I didn't built/test some feature, but source RPM
shows how I built with base/update and epel packages.
JFYI.
Cheers,
--
Yasuhito FUTATSUKI
core.svn_utf_cstring_from_utf8() vice versa.
(Note that Those functions also depend on locale, and cause worse result
on "C" locale).
Cheers,
--
Yasuhito FUTATSUKI
nable-maintainer-mode --prefix=/tmp/subversion_target
> PYTHON=/usr/bin/python2.7 SWIG=/usr/bin/swig-2
> make -j4
> make install
> # Step 3 of subversion/bindings/swig/INSTALL
> make clean-swig-py
> make swig-py
> make check-swig-py
Those steps seems ok.
Cheers,
--
Yasuhito FUTATSUKI
620%40%3Cdev.subversion.apache.org%3E
Cheers,
--
Yasuhito FUTATSUKI
ted if 'make swig-py' is allowed
by the result of configure (by "._swig_py_checked" target in Makefile),
so it didn't stop as we expected.
The 1.14.0 release tarball contains also '.swig_pl_checked' and
'.swig_rb_checked' files. Should they omit from release tarball?
Also, should the configure script remove them?
Cheers,
--
Yasuhito FUTATSUKI
the PATH, then it can be avoid without passing
> > --without-swig option to configure.
>
> `--without-swig` doesn't help without patch. I'll try patch, thank you!
Aha, I mean without '--without-swig' :)
Anyway, I think it is need the patch for FreeBSD ports.
Cheers,
--
Yasuhito FUTATSUKI
n/sh
echo Version 3.0.12
]]]
and explicitly specify it by --with-swig=/path/to/fake-script.
Or alternatively, apply attached patch, and pass --without-swig option
to configure.
Cheers,
--
Yasuhito FUTATSUKI
Index: build/ac-macros/swig.m4
===
ll add support for Python 3 but
> until then once has no choice but use Python 2 if they are using the
> bindings.
Even if we use Subversion 1.14 LTS, we can't use Python 3 bindings
without modifying existing application programs, mainly str/bytes
distinction.
>
> Aside from that ... unfortunately I have no help to offer on the original
> problem.
>
Cheers,
--
Yasuhito FUTATSUKI
mail, user_is_admin from users;'
where is the file path to the database file you specified on
configure the service.
Please see https://github.com/usvn/usvn/blob/1.0.7/library/SQL/sqlite.sql#L45
for table schema, and manual of sqlite3 utility for output format and other
options.
--
Yasuhito FUTATSUKI
own problem. Subversion swig Python bindings doesn't support
Python 3 yet. There is a feature branch to work for it.
(inactive 2 months on the surface, though)
https://svn.apache.org/viewvc/subversion/branches/swig-py3/
--
Yasuhito FUTATSUKI
ogger.warn('| ' + x.rstrip())
"x" is a bytes object derived from an element of "contents".
TypeError: can only concatenate str (not "bytes") to str
FAIL: tree_conflict_tests.py 26: endless loop when resolving local-missing dir
END: tree_conflict_tests.py
ELAPSED: tree_conflict_tests.py 0:01:17.563191
--8<---cut here---end--->8---
Cheers,
--
Yasuhito FUTATSUKI
lient.h is mistaken, isn't it?
--
Yasuhito FUTATSUKI
44 matches
Mail list logo
