Am 2024-10-15 um 12:23 schrieb Daniel Sahlberg:
Den mån 14 okt. 2024 kl 13:07 skrev Franz Sirl ker...@lauterbach.com <mailto:franz.sirl-ker...@lauterbach.com>>:
Hi,
the attached patch fixes both issue 4856 and the (different) bug
we were seeing in one of our own rep
Hi,
the attached patch fixes both issue 4856 and the (different) bug
we were seeing in one of our own repositories.
The problem boils down to the fact that with `svn log --xml --verbose`
a log-item is opened every time the PATH_CHANGE_RECEIVER callback is
used. But if the revision is later declar
Hi Nathan,
after further checking it turns out the failure mode I see is exactly
the same like issue 4856, only you need to use --verbose and http to see
it (`r` is the repository like created by `repro-4856.sh`):
```
> svn log --xml --verbose --use-merge-history -r 9:10 http://svn/r/A4
>/de
Am 2024-10-02 um 17:10 schrieb Franz Sirl:
So I came up with the attached tentative and so far untested patch.
I'm currently building packages and will test them as soon as build is
finished.
Unfortunately the patch is just papering over the real bug. The XML
error is gone, bu
Am 2024-10-02 um 16:02 schrieb Nathan Hartman:
On Tue, Oct 1, 2024 at 10:03 AM Franz Sirl
wrote:
Looking at the transferred data with wireshark shows this at the end:
```
...
... (>4 lines of modified-path/added-path redacted)
...
```
So the closing tag `` is missing. This closing
Hi,
recently this svn log command started to fail like that:
```
> svn log --xml --verbose --search @ --use-merge-history --incremental
--revision 172342:{2024-09-30}
http://svn/svn/project/branches/cd/2024_09 >/dev/null
svn: E175009: The XML response contains invalid XML
svn: E130003: Malfor
Hi,
a simple pre-commit hook like:
```
#!/bin/bash
/bin/echo -e '-\x0c-' >&2
exit 1
```
causes the following error messages on the client:
```
svn: E175002: Commit failed (details follow):
svn: E175002: Unexpected server error 500 'Internal Server Error' on
'/svn/repo'
svn: E200042:
Am 2018-07-21 um 16:27 schrieb Franz Sirl:
Am 2018-07-20 um 16:46 schrieb Franz Sirl:
Am 2018-07-20 um 15:55 schrieb Branko Čibej:
On 20.07.2018 15:37, Franz Sirl wrote:
Hi,
this already happened a few times here, but now I managed to re-create
it reliably.
This happens at least on Linux
Am 2018-07-20 um 16:46 schrieb Franz Sirl:
Am 2018-07-20 um 15:55 schrieb Branko Čibej:
On 20.07.2018 15:37, Franz Sirl wrote:
Hi,
this already happened a few times here, but now I managed to re-create
it reliably.
This happens at least on Linux with subversion-1.8/subversion-1.10 and
on
Am 2018-07-20 um 15:55 schrieb Branko Čibej:
On 20.07.2018 15:37, Franz Sirl wrote:
Hi,
this already happened a few times here, but now I managed to re-create
it reliably.
This happens at least on Linux with subversion-1.8/subversion-1.10 and
on Windows
with TortoiseSVN-1.9, didn't test
Hi,
this already happened a few times here, but now I managed to re-create
it reliably.
This happens at least on Linux with subversion-1.8/subversion-1.10 and
on Windows
with TortoiseSVN-1.9, didn't test older versions yet. Server is
subversion-1.9.5
on Linux, a "svnadmin verify" of a reposit
Hi,
anyone care to comment on this? Is this report OK to enter into the
issue database?
Franz
Am 2010-06-14 10:55, schrieb Franz Sirl:
Hi,
we stumbled over an annoying issue with subversion 1.6.11. If we update
a WC with versioned file externals, files where the version is not equal
to
Hi,
we stumbled over an annoying issue with subversion 1.6.11. If we update
a WC with versioned file externals, files where the version is not equal
to the last revision of the file, are double-updated on _every_ update
like this:
[u...@machine:~/a/test_file_externals]$ svn up
Utrunk/com
13 matches
Mail list logo
