On 1/10/14, 4:19 AM, Philip Martin wrote:
> It is not fixed. If you look a few lines down we pass a NULL path:
>
> apr_text_append(resource->pool, option,
> dav_svn__build_uri(resource->info->repos,
>
> DAV_SVN__BUI
On 11.01.2014 01:02, Ben Reser wrote:
> On 1/10/14, 3:17 PM, Branko Čibej wrote:
>> We could even not add an option, and instead only remove pristines that are
>> "old enough"; e.g., touch the file timestamp every time a pristine file is
>> used, and have "svn cleanup" only remove those prisitines
On 1/10/14, 3:17 PM, Branko Čibej wrote:
> We could even not add an option, and instead only remove pristines that are
> "old enough"; e.g., touch the file timestamp every time a pristine file is
> used, and have "svn cleanup" only remove those prisitines that haven't been
> used for a certain peri
On 10.01.2014 20:11, C. Michael Pilato wrote:
> On 01/10/2014 02:00 PM, Ben Reser wrote:
>> Wish that cleaning up pristines hadn't been overloaded into cleanup. Ran
>> into
>> a situation where I crashed the client today. So I needed to run cleanup,
>> but
>> I hadn't run cleanup in a very long
On 1/10/14, 12:30 AM, Антон Бреусов wrote:
> It will be very good to add a note to the documentation about this issue here:
> https://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap
Added a warning section covering this.
> And probably here too:
> http://svnbook.red-bean.com/e
On 01/10/2014 02:00 PM, Ben Reser wrote:
> Wish that cleaning up pristines hadn't been overloaded into cleanup. Ran into
> a situation where I crashed the client today. So I needed to run cleanup, but
> I hadn't run cleanup in a very long time so of course it took a while since it
> also went thr
Wish that cleaning up pristines hadn't been overloaded into cleanup. Ran into
a situation where I crashed the client today. So I needed to run cleanup, but
I hadn't run cleanup in a very long time so of course it took a while since it
also went through all the pristines to cleanup the unreference
Philip Martin writes:
> "Bert Huijben" writes:
>
>> Your segfault should be properly fixed with r1557094, but we should probably
>> also run some tests on a repository that is at the server root (instead of
>> only a parent path).
>
> It is not fixed. If you look a few lines down we pass a NULL
"Bert Huijben" writes:
> Your segfault should be properly fixed with r1557094, but we should probably
> also run some tests on a repository that is at the server root (instead of
> only a parent path).
It is not fixed. If you look a few lines down we pass a NULL path:
apr_text_append
> -Original Message-
> From: lieven.govae...@gmail.com [mailto:lieven.govae...@gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: vrijdag 10 januari 2014 11:53
> To: Subversion Development
> Subject: Segfault in mod_dav_svn with repositories on /
>
> Hi,
>
>
> a customer is seeing repro
Hi,
a customer is seeing reproducible httpd child process segfaults when
using Subversion.
Setup:
- Subversion 1.8.1 - WANDisco package subversion-1.8.1-1.x86_64.rpm
- Apache 2.2.15 - RedHat package httpd-2.2.15-26.el6.x86_64
- OS: Red Hat Enterprise Linux Server release 6.4
- Client: svn, versi
Hi,
Just for your information: rhuijben gave me the +1 to commit the fix to the
/1.7.x-r1551579 branch via IRC (#ankhsvn).
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Sc
Hi,
r1551579 is nominated for 1.7.X backport by rhuijben, with a backport branch.
I wanted to test said branch to make my (non-binding) vote for this issue, and
it seems that the backport branch needs another fix added:
In r1427830, the function svn_wc__get_wc_root was renamed to svn_wc__get_wc
Indeed, this was an issue, after removing AddEncoding directives it works
now! Thank you. They were in my config on global level ( context
) for a long time since Apache 1.3.x maybe.
It will be very good to add a note to the documentation about this issue
here:
https://subversion.apache.org/docs/r
14 matches
Mail list logo
