Stefan Sperling wrote on Mon, Jun 25, 2012 at 23:27:37 +0200:
> On Mon, Jun 25, 2012 at 10:23:38PM +0100, Daniel Shahaf wrote:
> > From the peanut gallery: as long as svn1.7 errors out, but doesn't
> > corrupt any of the data or metadata, perhaps that's something we're
> > willing to live with?
>
On Tue, Jun 19, 2012 at 2:26 PM, wrote:
> Author: stsp
> Date: Tue Jun 19 18:26:30 2012
> New Revision: 1351792
>
> URL: http://svn.apache.org/viewvc?rev=1351792&view=rev
> Log:
> Teach 'svn merge' to invoke the interactive conflict resolution callback
> after the merge, not during the merge.
Do
On Mon, Jun 25, 2012 at 4:50 PM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_client/switch.c Mon Jun 25 20:50:17
> 2012
> @@ -94,8 +94,6 @@ switch_internal(svn_revnum_t *result_rev
> : NULL;
> /* Resolve conflicts post-switch for 1.7 and above API use
On Mon, Jun 25, 2012 at 6:23 PM, Johan Corveleyn wrote:
> On Mon, Jun 25, 2012 at 11:53 PM, Mark Phippard wrote:
>> On Jun 25, 2012, at 3:14 PM, Stefan Sperling wrote:
>...
>>> I don't see a way to avoid this problem for 1.7 clients, apart from either
>>> reverting the tree conflict description
On Mon, Jun 25, 2012 at 11:53 PM, Mark Phippard wrote:
> On Jun 25, 2012, at 3:14 PM, Stefan Sperling wrote:
>
>> On Mon, Jun 25, 2012 at 09:03:47PM +0200, Stefan Sperling wrote:
>>> on the same working copy. E.g. a 1.7 client might run into tree conflicts
>>> which it cannot understand because a
On Jun 25, 2012, at 23:25 , s...@apache.org wrote:
> Author: stsp
> Date: Mon Jun 25 21:25:47 2012
> New Revision: 1353748
>
> URL: http://svn.apache.org/viewvc?rev=1353748&view=rev
> Log:
> Following up to r1353730, fix a test failure due to passing the wrong number
> of arguments to a helper f
On Jun 25, 2012, at 3:14 PM, Stefan Sperling wrote:
> On Mon, Jun 25, 2012 at 09:03:47PM +0200, Stefan Sperling wrote:
>> on the same working copy. E.g. a 1.7 client might run into tree conflicts
>> which it cannot understand because a 1.8 client flagged a conflict involving
>> a move. I believe
On Mon, Jun 25, 2012 at 11:01:08PM +0200, Johan Corveleyn wrote:
> How about the other way around? Make 1.8 work with 1.7-format wc's,
> without requiring an upgrade. The upgrade would be optional, enabling
> new features and improvements. Would that be at all possible? That
> would make it possibl
On Mon, Jun 25, 2012 at 10:23:38PM +0100, Daniel Shahaf wrote:
> From the peanut gallery: as long as svn1.7 errors out, but doesn't
> corrupt any of the data or metadata, perhaps that's something we're
> willing to live with?
This approach might be suboptimal for GUI apps that use status to
refres
>From the peanut gallery: as long as svn1.7 errors out, but doesn't
corrupt any of the data or metadata, perhaps that's something we're
willing to live with?
Presumably the user would have a 1.8 client around to solve the conflict
with.
Stefan Sperling wrote on Mon, Jun 25, 2012 at 21:14:07 +0200
On Mon, Jun 25, 2012 at 9:14 PM, Stefan Sperling wrote:
> On Mon, Jun 25, 2012 at 09:03:47PM +0200, Stefan Sperling wrote:
>> on the same working copy. E.g. a 1.7 client might run into tree conflicts
>> which it cannot understand because a 1.8 client flagged a conflict involving
>> a move. I belie
On Mon, Jun 25, 2012 at 09:03:47PM +0200, Stefan Sperling wrote:
> on the same working copy. E.g. a 1.7 client might run into tree conflicts
> which it cannot understand because a 1.8 client flagged a conflict involving
> a move. I believe we should bump to avoid such problems.
FYI, here is what t
On Mon, Jun 25, 2012 at 08:42:30PM +0200, Johan Corveleyn wrote:
> Is there already a format bump planned for 1.8? Can a format bump be
> avoided? If we have to bump, how hard would it be to keep everything
> working with 1.7 clients too (albeit with less features, slower XYZ
> because of whatever,
On Mon, Jun 25, 2012 at 8:04 PM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
>> Sent: maandag 25 juni 2012 19:32
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r1353676 - in /subversion/trunk/subversion:
>> include/p
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: maandag 25 juni 2012 20:09
> To: dev@subversion.apache.org
> Cc: Bert Huijben; comm...@subversion.apache.org
> Subject: Re: svn commit: r1353676 - in /subversion/trunk/subversion:
> include/private/svn_wc_
On 06/25/2012 02:04 PM, Bert Huijben wrote:
> If we want to enable this code in 1.8 we should add an index on the
> md5_checksum in the pristine table with the format bump for 1.8.
>
> Currently the md5 lookup performs a table scan (but is only used from the
> deprecated libsvn_wc commit logic). F
> -Original Message-
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: maandag 25 juni 2012 19:32
> To: comm...@subversion.apache.org
> Subject: svn commit: r1353676 - in /subversion/trunk/subversion:
> include/private/svn_wc_private.h include/svn_ra.h libsvn_client/ra.c
>
Mark Phippard writes:
> On Mon, Jun 25, 2012 at 12:16 PM, Philip Martin
> wrote:
>
>> I would probably giving the user a mechanism to ask for exclusive locking
>> if the application does not request it.
Oops! I meant to write "I would avoid giving ..."
We cannot know whether $APP would work w
On Mon, Jun 25, 2012 at 12:16 PM, Philip Martin
wrote:
> Yes. Locking would be disabled by default. Applications would request
> exclusive locking if they use the Subversion API in a manner that is
> compatible with such locking. The 1.8 command line client is
> compatible, the 1.7 client need
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 25 juni 2012 18:17
> To: Mark Phippard
> Cc: Bert Huijben; dev@subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
>
> Mark Phippard writes:
Mark Phippard writes:
> On Mon, Jun 25, 2012 at 11:34 AM, Bert Huijben wrote:
>
>>> I think the solution is to default to non-exclusive locking and to allow
>>> an application to ask for exclusive locking. Then the command line
>>> client can be patched to ask for exclusive locking. And we pro
> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: maandag 25 juni 2012 17:44
> To: Bert Huijben
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
>
> On Mon, Jun 25, 2012 at 11:34 AM, Bert Huijben wrote:
>
Stefan Sperling writes:
> On Mon, Jun 25, 2012 at 05:21:53PM +0200, Bert Huijben wrote:
>> (I don't see how it can corrupt your working copy. It can make a local
>> change unnoticed, but I wouldn't call that corrupted)
>>
>> Bert
>
> I just meant to say that the db state is inconsistent wi
On Mon, Jun 25, 2012 at 11:34 AM, Bert Huijben wrote:
>> markp...@tigris.org writes:
>>
>> > http://subversion.tigris.org/issues/show_bug.cgi?id=4176
>>
>> > I think we need to find a way to include this patch. I would suggest
>> > a new runtime configuration option or an environment variable.
>
> -Original Message-
> From: Stefan Sperling [mailto:s...@apache.org]
> Sent: maandag 25 juni 2012 17:37
> To: C. Michael Pilato
> Cc: Bert Huijben; 'Subversion Development'
> Subject: Re: Trunk regression? ('svn update *')
>
> On Mon, Jun 25, 2012 at 11:30:42AM -0400, C. Michael Pilato
On Mon, Jun 25, 2012 at 11:30:42AM -0400, C. Michael Pilato wrote:
> On 06/25/2012 11:24 AM, Bert Huijben wrote:
> >>> It also still fails when there are unversioned targets, which pre-Berlin
> >>> gracefully "Skip"ped. :-(
> >>
> >> r1353587. I think this gets us back to where we were.
> >
> >
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 25 juni 2012 17:24
> To: dev@subversion.apache.org
> Subject: Re: [Issue 4176] wcng slow on network disks
>
> markp...@tigris.org writes:
>
> > http://subversion.tig
On 06/25/2012 11:24 AM, Bert Huijben wrote:
>>> It also still fails when there are unversioned targets, which pre-Berlin
>>> gracefully "Skip"ped. :-(
>>
>> r1353587. I think this gets us back to where we were.
>
> I'm not sure if it really brings us back where we were.
Sorry. I was referring
On Mon, Jun 25, 2012 at 05:21:53PM +0200, Bert Huijben wrote:
> (I don't see how it can corrupt your working copy. It can make a local change
> unnoticed, but I wouldn't call that corrupted)
>
> Bert
I just meant to say that the db state is inconsistent with the
expected state if this bug
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: maandag 25 juni 2012 17:02
> To: Subversion Development
> Subject: Re: Trunk regression? ('svn update *')
>
> On 06/25/2012 10:44 AM, C. Michael Pilato wrote:
> > On 06/25/2012 10:12 AM, Stefan Sperling w
markp...@tigris.org writes:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4176
> I think we need to find a way to include this patch. I would suggest
> a new runtime configuration option or an environment variable.
> Something like "Allow concurrent client access".
There are problems wi
> -Original Message-
> From: s...@apache.org [mailto:s...@apache.org]
> Sent: maandag 25 juni 2012 16:35
> To: comm...@subversion.apache.org
> Subject: svn commit: r1353577 - /subversion/branches/1.7.x/STATUS
>
> Author: stsp
> Date: Mon Jun 25 14:34:39 2012
> New Revision: 1353577
>
>
You're right, and I was wrong.
Yes, I've noticed the bug after running
$ svn propdel svn:eol-style file
And translated_size was untouched.
> Dmitry Pavlenko writes:
> > I would also ask you to add the fix to 1.7.x
> >
> > [[[
> > Fix a typo that could lead to wrong translated_size value.
> >
Dmitry Pavlenko writes:
> I would also ask you to add the fix to 1.7.x
>
> [[[
> Fix a typo that could lead to wrong translated_size value.
> if svn:eol-style is locally changed and svn:keywords is not, translated_size
> wasn't reset.
>
> * subversion/libsvn_wc/props.c
> (do_propset): SVN_PROP
On 06/25/2012 10:44 AM, C. Michael Pilato wrote:
> On 06/25/2012 10:12 AM, Stefan Sperling wrote:
>> On Mon, Jun 25, 2012 at 09:57:52AM -0400, C. Michael Pilato wrote:
>>> On 06/25/2012 09:42 AM, Stefan Sperling wrote:
It's a silly bug I introduced where the new codes tries to resolve
co
On 06/25/2012 10:12 AM, Stefan Sperling wrote:
> On Mon, Jun 25, 2012 at 09:57:52AM -0400, C. Michael Pilato wrote:
>> On 06/25/2012 09:42 AM, Stefan Sperling wrote:
>>> It's a silly bug I introduced where the new codes tries to resolve conflicts
>>> in an unversioned directory, the parent of all u
Not true. It was comparing old and new values of svn:keywords but should
compare old and new values
of svn:eol-style.
Ok, I got the idea of high-level problem.
> On Mon, Jun 25, 2012 at 04:03:42PM +0200, Dmitry Pavlenko wrote:
> > I would also ask you to add the fix to 1.7.x
> >
> > [[[
> > Fi
> -Original Message-
> From: s...@apache.org [mailto:s...@apache.org]
> Sent: maandag 25 juni 2012 16:27
> To: comm...@subversion.apache.org
> Subject: svn commit: r1353572 -
> /subversion/trunk/subversion/libsvn_wc/props.c
>
> Author: stsp
> Date: Mon Jun 25 14:27:16 2012
> New Revision
On Mon, Jun 25, 2012 at 04:03:42PM +0200, Dmitry Pavlenko wrote:
> I would also ask you to add the fix to 1.7.x
>
> [[[
> Fix a typo that could lead to wrong translated_size value.
> if svn:eol-style is locally changed and svn:keywords is not, translated_size
> wasn't reset.
>
> * subversion/lib
On Mon, Jun 25, 2012 at 09:57:52AM -0400, C. Michael Pilato wrote:
> On 06/25/2012 09:42 AM, Stefan Sperling wrote:
> > It's a silly bug I introduced where the new codes tries to resolve conflicts
> > in an unversioned directory, the parent of all update targets in your case.
> > Should be fixed as
I would also ask you to add the fix to 1.7.x
[[[
Fix a typo that could lead to wrong translated_size value.
if svn:eol-style is locally changed and svn:keywords is not, translated_size
wasn't reset.
* subversion/libsvn_wc/props.c
(do_propset): SVN_PROP_EOL_STYLE value should be checked, not
S
On 06/25/2012 09:42 AM, Stefan Sperling wrote:
> It's a silly bug I introduced where the new codes tries to resolve conflicts
> in an unversioned directory, the parent of all update targets in your case.
> Should be fixed as of r1353532.
Sweet. I was hoping it was something that simple. Thanks,
On Sun, Jun 24, 2012 at 8:50 PM, wrote:
> Started at Mon Jun 25 00:24:41 UTC 2012
>
> *Disclaimer* - This tests only file://-URL access on a GNU/Linux VM.
> This is intended to measure changes in performance of the local working
> copy layer, *only*. These results are *not* generally true for eve
On Mon, Jun 25, 2012 at 09:21:04AM -0400, C. Michael Pilato wrote:
> My days have begun the same for many months, now:
>
> $ cd ~/projects
> $ svn up *
>
> But it seems that recently a regression has been introduced into Subversion
> that causes this action to ultimately result in an error:
>
My days have begun the same for many months, now:
$ cd ~/projects
$ svn up *
But it seems that recently a regression has been introduced into Subversion
that causes this action to ultimately result in an error:
$ svn up *
Updating 'wc1':
At revision 2.
Updating 'wc2':
At revision 5
FYI, I *have* code that can produce charts, but haven't had a chance to put
it on the testing VM yet. It's just a matter of weeks now... :/
~Neels
On 2012-06-25 02:50, ne...@apache.org wrote:
> Started at Mon Jun 25 00:24:41 UTC 2012
>
> *Disclaimer* - This tests only file://-URL access on a GNU
On Jun 25, 2012 1:48 AM, wrote:
>
> I'm trying to use svn_wc_prop_set4 to set a property on my local working
> copy (1.7) and I keep getting the error:
>
> No write-lock in 'T:\VIP00192\test_1.7\LFD_Dev_14'
>
> OS: Windows
> Compiler: visual c++
> SVN package: svn-win32-1.7.5
>
> Leslie Donaldson
47 matches
Mail list logo
