A user wrote to dev@ today:
> I have now taken the plunge and moved to using version 1.7 tsvn for my
> development.
>
> After updating one of my working copies from 1.6 using TortoiseSVN
> from 2011/03/20 subversion 1.7.0 r1082999 [...]
I don't know the whole chain of communication or miscommunic
On Mon, 2011-03-21, Alan Wood wrote:
> Hi Devs
> I have now taken the plunge and moved to using version 1.7 tsvn for my
> development.
>
> After updating one of my working copies from 1.6 using TortoiseSVN from
> 2011/03/20
> subversion 1.7.0 r1082999 I had the following error:
Hi Alan. Not a
On Mon, Mar 21, 2011 at 12:33:34PM +1300, Alan Wood wrote:
> There should not have been any conflict data of any sort in this
> working copy as I am the only developer and I have only every had
> one working copy.
That's not a valid assumption.
It is possible to inflict tree conflicts upon your
On 21 Mar 2011 at 10:48, Stefan Sperling wrote:
> On Mon, Mar 21, 2011 at 12:33:34PM +1300, Alan Wood wrote:
> > There should not have been any conflict data of any sort in this
> > working copy as I am the only developer and I have only every had
> > one working copy.
>
> That's not a valid
Alan Wood wrote:
> Sorry for the confusion with the version labels.
No problem. I was just concerned that maybe we weren't successfully
getting the message out that these are builds of software that is still
under development, but it sounds like you were aware so that's OK. It
did make me double
On Mon, Mar 21, 2011 at 05:38, Julian Foad wrote:
> A user wrote to dev@ today:
>> I have now taken the plunge and moved to using version 1.7 tsvn for my
>> development.
>>
>> After updating one of my working copies from 1.6 using TortoiseSVN
>> from 2011/03/20 subversion 1.7.0 r1082999 [...]
>
>
On Mon, Mar 21, 2011 at 10:36, wrote:
> Author: rhuijben
> Date: Mon Mar 21 14:36:21 2011
> New Revision: 1083805
>
> URL: http://svn.apache.org/viewvc?rev=1083805&view=rev
> Log:
> Following up on storing tree conflicts on the node itself, stop looking
> for conflicts on nodes that don't exist w
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: maandag 21 maart 2011 16:19
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1083805 -
> /subversion/trunk/subversion/libsvn_wc/update_editor.c
>
> On Mon, Mar 21, 2011 at 10:36, wrote:
> > Author: rhu
I know that everyone is incredibly busy preparing 1.7, but would
someone please review and commit this patch? I don't want to see it
slip to 1.8.
Attached are the patch, the log message, and the two TGZ archives of
DUMP files (for the tests). They are the same as before, except that
I diff'ed ag
Danny Trebbien writes:
> Attached are the patch, the log message, and the two TGZ archives of
> DUMP files (for the tests).
The patch is missing.
--
Philip
[Mark Phippard]
> svnsync: E24: Can't open file
> '/Users/mphippard/tests/repos-test2/db/transactions/529-eq.txn/changes':
> Too many open files
I guess it would be helpful to know what the open files per process
limit is on your login, or on OS X Snow Leopard as a whole. That's
'ulimit -n'
On Mon, Mar 21, 2011 at 3:45 PM, Peter Samuelson wrote:
>
> [Mark Phippard]
>> svnsync: E24: Can't open file
>> '/Users/mphippard/tests/repos-test2/db/transactions/529-eq.txn/changes':
>> Too many open files
>
> I guess it would be helpful to know what the open files per process
> limit is on
Recently (last week or so), I've noticed that 'svn commit' has gotten
*really* slow. As in, it takes a full 30 seconds for 'svn commit' to return
when asked to perform a no-op commit of my Subversion trunk directory.
I was able to discern through code-stepping that the lion's share of the
time sp
On Mon, Mar 21, 2011 at 10:20 AM, Philip Martin
wrote:
> Danny Trebbien writes:
>> Attached are the patch, the log message, and the two TGZ archives of
>> DUMP files (for the tests).
>
> The patch is missing.
>
> --
> Philip
Sorry. Attached is the patch with a .txt extension.
Index: subversion/
On Mon, 2011-03-21 at 17:23 -0400, C. Michael Pilato wrote:
> Recently (last week or so), I've noticed that 'svn commit' has gotten
> *really* slow. As in, it takes a full 30 seconds for 'svn commit' to return
> when asked to perform a no-op commit of my Subversion trunk directory.
>
> I was able
On Mon, Mar 21, 2011 at 9:36 AM, wrote:
> Author: rhuijben
> Date: Mon Mar 21 14:36:21 2011
> New Revision: 1083805
>
> URL: http://svn.apache.org/viewvc?rev=1083805&view=rev
> Log:
> Following up on storing tree conflicts on the node itself, stop looking
> for conflicts on nodes that don't exist
On Mon, Mar 21, 2011 at 10:02 AM, wrote:
> Author: rhuijben
> Date: Mon Mar 21 15:02:27 2011
> New Revision: 1083817
>
> URL: http://svn.apache.org/viewvc?rev=1083817&view=rev
> Log:
> * subversion/libsvn_wc/wc_db.c
> (svn_wc__db_read_conflicts): Reset statement on error.
>
> Modified:
> subv
On Sun, Mar 20, 2011 at 3:32 PM, Johan Corveleyn wrote:
> Hi,
>
> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
> Although this is marked as "1.7-consider", I'd really like this to be
> fixed before release, since this is pretty important for me and my
> user base. So I'd l
On 03/21/2011 06:38 PM, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Mar 21 22:38:48 2011
> New Revision: 1084001
>
> URL: http://svn.apache.org/viewvc?rev=1084001&view=rev
> Log:
> Simplify and correct a query to allow it to be executed as 5 normal subqueries
> instead of a huge join
Translation status report for trunk@r1084064
lang trans untrans fuzzy obs
--
de2049 133 254 217
es1986 196 285 355
fr2171 11 29 24
it1840 342 479 174
ja1978
20 matches
Mail list logo
