-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kannan wrote:
[..]
> Thank you Philip/Bert for the feedback. Attaching an updated patch
> herewith as per Bert's comments.
>
Tweaking the log message.
> [[[
> Log:
> Make `--set-depth (empty|files|immediates) DIR' work, where DIR's depth
> had alrea
On Fri, 2010-01-08 at 11:39 +1100, Bojan Smojver wrote:
> No, I don't think that's going to work. Again, memory may vanish
> before another cleanup runs.
Essentially, this reduces is to the problem of a sibling pool, for which
the cleanup is hanging off the pool, but with lower memory use. Still n
On Fri, 2010-01-08 at 11:35 +1100, Bojan Smojver wrote:
> + mem = calloc(max + 1, sizeof(*ht->array));
> + apr_pool_cleanup_register(ht->pool, mem,
> + array_cleanup,apr_pool_cleanup_null);
No, I don't think that's going to work. Again, memory may vanish before
ano
On Fri, 2010-01-08 at 11:15 +1100, Bojan Smojver wrote:
> Why can't we just use malloc() for this and hang a cleanup off the
> pool? It would use less memory anyway than having another pool for
> this.
Quick and dirty example of what I mean here.
--
Bojan
Index: tables/apr_hash.c
===
On Thu, 2010-01-07 at 11:00 -0800, Neil Conway wrote:
> Well, the suggested fix of using a sibling pool to the hash table's
> pool would work, I think -- I'd be happy to prepare patches to
> implement that.
What would you hang the destruction of the array_pool against? The
parent pool? If so, we
On Thu, 2010-01-07 at 16:26 +0100, Ruediger Pluem wrote:
> This sounds like a valid point.
+1
> I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and
> only keep r817806 (trunk). Graham?
> IMHO we can backport this again later if the problem is sorted out in
> trunk.
I think we sh
On Thu, Jan 7, 2010 at 10:21 AM, Mark Mielke wrote:
> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>>
>> (You can get the same effect by creating a branch for each developer in
>> Subversion. You can imagine the horror that integration then becomes.)
>>
>
> It's only a horror because Subversion me
Julian,
I don't want to remove parts of the tree from the repository.
What I want is, effectively, a way to independently mark separate
parts of the tree with the same tag.
(I tried to explain it in my example). I don't see how your method
(using svn rm) does it.
If a tag is a property of a file
[Paul Burba]
> Once this is backported I think we are ready for 1.6.8. Anybody
> aware of any open issues preventing that?
Well, I still have a couple of ruby test failures on Debian
architectures I don't have easy access to, failures I can't reproduce
(and neither can anyone else I know). If I
I've filed an issue to track this at:
http://subversion.tigris.org/issues/show_bug.cgi?id=3559
Thanks for the report. And yes, I would agree that the behavior seems to
point to an order-of-operations problem that's probably triggered by hash
ordering.
--
C. Michael Pilato
CollabNet <> www.
Mark Mielke wrote:
> On 01/07/2010 02:11 PM, Branko Čibej wrote:
>> Mark Mielke wrote:
>>
>>> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>>>
Mark Mielke wrote:
> The model is a bit easier to implement in ClearCase and GIT, since
> these are both effectively th
On 01/07/2010 02:11 PM, Branko Čibej wrote:
Mark Mielke wrote:
On 01/07/2010 04:42 AM, Branko Čibej wrote:
Mark Mielke wrote:
The model is a bit easier to implement in ClearCase and GIT, since
these are both effectively the working copy is a different stream from
the parent
On Thu, Jan 7, 2010 at 7:26 AM, Ruediger Pluem wrote:
> This sounds like a valid point.
Yup. My fault -- sorry!
> I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and only
> keep r817806 (trunk). Graham?
> IMHO we can backport this again later if the problem is sorted out in trunk
Mark Mielke wrote:
> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>> Mark Mielke wrote:
>>
>>> The model is a bit easier to implement in ClearCase and GIT, since
>>> these are both effectively the working copy is a different stream from
>>> the parent whereas Subversion designer work flows tend t
On 01/07/2010 04:42 AM, Branko Čibej wrote:
Mark Mielke wrote:
The model is a bit easier to implement in ClearCase and GIT, since
these are both effectively the working copy is a different stream from
the parent whereas Subversion designer work flows tend to work
directly on "trunk".
On 07.01.2010 16:12, Bert Huijben wrote:
> Hi,
>
>
>
> Looking at apr's 1.3.x branch:
>
>
>
> In r817810 a change to the hash table implementation was introduced, which
> moves the data of a hash table from the main pool to a subpool (as seen from
> the pool passed to apr_ha
C. Michael Pilato wrote:
> Julian Foad wrote:
> > What about the forum interface?
> >
> > It's a bit late to say this, but it's just occurred to me that the old
> > list had a forum interface. Personally I don't use those much, but for
> > people looking to post a first question or answer a questi
Mark Mielke писал в своём письме Thu, 07 Jan 2010
08:53:27 +0300:
On 01/07/2010 12:30 AM, Ed wrote:
Correction. Now I know how to reproduce this.
Select the first link. Right click on one message (any one will
do) and the select Open in New Tab or Open in New Window. Then
presto, what is
On Jan 7, 2010, at 8:55 AM, C. Michael Pilato wrote:
> hwri...@apache.org wrote:
>> Author: hwright
>> Date: Thu Jan 7 14:27:23 2010
>> New Revision: 896893
>
> [...]
>
>> * subversion/svn/help-cmd.c
>> (svn_cl__help): Use the new URL.
>
> This didn't break getopt_tests.py?
Grr... probably
Hi,
Looking at apr's 1.3.x branch:
In r817810 a change to the hash table implementation was introduced, which
moves the data of a hash table from the main pool to a subpool (as seen from
the pool passed to apr_hash_make). This makes the contents of the hashtable
unavailable
hwri...@apache.org wrote:
> Author: hwright
> Date: Thu Jan 7 14:27:23 2010
> New Revision: 896893
[...]
> * subversion/svn/help-cmd.c
> (svn_cl__help): Use the new URL.
This didn't break getopt_tests.py?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development O
On 01/07/2010 07:53 PM, C. Michael Pilato wrote:
Kamesh Jayachandran wrote:
With all due respect, the proposed solution looks enormous compared to
the
size of the problem. Does the original problem exist in HTTPv2? At a
minimum, could the ra_dav providers not annotate the PROPFIND a
Julian Foad wrote:
> On Tue, 2010-01-05, Hyrum K. Wright wrote:
>> For those that aren't subscribed, Mike sent the warning mail earlier
>> today, and we'll turn off us...@s.t.o by the end of the week.
>
> What about the forum interface?
>
> It's a bit late to say this, but it's just occurred to m
On Jan 7, 2010, at 5:06 AM, Julian Foad wrote:
> On Tue, 2010-01-05, Hyrum K. Wright wrote:
>> For those that aren't subscribed, Mike sent the warning mail earlier
>> today, and we'll turn off us...@s.t.o by the end of the week.
>
> What about the forum interface?
>
> It's a bit late to say thi
Kamesh Jayachandran wrote:
>
>> With all due respect, the proposed solution looks enormous compared to
>> the
>> size of the problem. Does the original problem exist in HTTPv2? At a
>> minimum, could the ra_dav providers not annotate the PROPFIND as
>> "dont-proxy-this" without even touching th
With all due respect, the proposed solution looks enormous compared to the
size of the problem. Does the original problem exist in HTTPv2? At a
minimum, could the ra_dav providers not annotate the PROPFIND as
"dont-proxy-this" without even touching the RA (and higher) APIs?
I *think* n
Julian Foad wrote:
> Kamesh Jayachandran wrote:
>> svn ps versioned_prop val url_to_resource fails!
>>
>> Yes 'svn help ps' does not say that it supports it.
>>
>> But it has some code as if it supports it but fails.
>>
>> I have the following in-progress patch(It is not fully complete but
>> work
duncan.love...@bt.com wrote:
> Nobody fancy taking a look at this ? Seems like it a bug with a good
> test case and I can't see it recorded elsewhere. Did I post to the
> proper place ?
Nah, you did the right thing. I've got your original message marked for
processing, but many of us are still di
C. Michael Pilato wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: asdf"
>
> Wanna dive in and look into a patch?
>
Actually the svn: in property names should never have been
interpreted as an XML namespace n
Now you sound exactly as my boss sounds when I propose a fix somewhere :)
Not sure where to dive for the moment, we are mere users of SVN at the time
being, but if this error prevails we might have to dig deeper. Thanks for the
help though, great job you guys do!
Geir
-Original Message---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
[..]
> I looked for assignments to the "activity_coll" field, and found it in
> the function end_element(), where it copies it from the "cdata" field. I
> think that is where the canonicalization should be done.
My bad, misinterpret
Stas Cherkassky wrote:
[...]
> % svn co $SVNROOT/myproj -–depth empty myproj
> % svn update -–depth infinity myproj/dirA
>
> .. modifies it in some way and tries to tag:
>
> % svn mkdir $SVNROOT/tags/rel_X
> % svn copy myproj $SVNROOT/tags/rel_X/ -m “tagging part A of myproj
> for the next integ
On Thu, 2010-01-07 at 10:20 +0800, Ed wrote:
> Julian Foad wrote:
> > The report of "success" indicates a bug in the test harness. We had (and
> > still have) similar problems with the Linux test harness.
>
> I'm still having slight difficulties understanding these tests
> in the regards that an X
Kamesh Jayachandran wrote:
> svn ps versioned_prop val url_to_resource fails!
>
> Yes 'svn help ps' does not say that it supports it.
>
> But it has some code as if it supports it but fails.
>
> I have the following in-progress patch(It is not fully complete but
> works with ra_local and unauth
Hi,
I have a problem with tagging a sparse directory.
Suppose I have this structure:
myproj
dirA
...
dirB
...
I want user A to work on dirA, and user B - on dirB.
But both are contributing to the same release-candidate, let's call it rel_X.
(the idea is that integrator would b
Hi All,
svn ps versioned_prop val url_to_resource fails!
Yes 'svn help ps' does not say that it supports it.
But it has some code as if it supports it but fails.
I have the following in-progress patch(It is not fully complete but
works with ra_local and unauthenticated http).
Currently this
On Sat, 2009-12-26 at 16:06 +0100, Jan Horák wrote:
> I'm looking for some benchmark test utility to test speed and
> performance of the BDB and FSFS backends, but could not find anything.
> Does anybody know about any utility or script suitable for this purpose?
>
> Thanks to any advice.
Hi Ja
On Tue, 2010-01-05, Hyrum K. Wright wrote:
> For those that aren't subscribed, Mike sent the warning mail earlier
> today, and we'll turn off us...@s.t.o by the end of the week.
What about the forum interface?
It's a bit late to say this, but it's just occurred to me that the old
list had a forum
Mark Mielke wrote:
> The model is a bit easier to implement in ClearCase and GIT, since
> these are both effectively the working copy is a different stream from
> the parent whereas Subversion designer work flows tend to work
> directly on "trunk".
In both ClearCase and GIT (and more so in ClearCa
Lieven Govaerts wrote:
On Thu, Jan 7, 2010 at 3:52 AM, Ed wrote:
Hi
On the assumption that there is such an e-mail as
svn-break...@subversion.apache.org, the following patch
changes the e-mail address. Of course, if there doesn't
exist such an e-mail address, I suppose this patch
assumes one
> -Original Message-
> From: Peter Samuelson [mailto:pe...@p12n.org]
> Sent: donderdag 7 januari 2010 2:30
> To: Edgar Fuß
> Cc: dev@subversion.apache.org
> Subject: Re: Issue 3501: Repositories mounted on NFS don't work
>
>
> [Edgar Fuß]
> > To summarise the problem: recursive director
On Thu, Jan 7, 2010 at 3:52 AM, Ed wrote:
> Hi
>
> On the assumption that there is such an e-mail as
> svn-break...@subversion.apache.org, the following patch
> changes the e-mail address. Of course, if there doesn't
> exist such an e-mail address, I suppose this patch
> assumes one will exist?
42 matches
Mail list logo
