Dmitry Pavlenko wrote on 06/20/2012 11:14:58 AM:
> simple_providers.c (svn_auth__simple_creds_cache_get): I propose to
> drop all assignments
> "need_to_save = FALSE" except the initial one; otherwise assignment
> to FALSE may override existing
> TRUE value. This may happen if default_username
On 06/20/2012 01:25 PM, Stefan Sperling wrote:
>> (Sorry if the above reads like a cranky old-timer putting the brakes on
>> progress -- I trust you know that's not my intent.)
>
> But it doesn't help much to say something like this without also suggesting
> a viable alternative. I would love to s
On Wed, Jun 20, 2012 at 1:25 PM, Stefan Sperling wrote:
> On Wed, Jun 20, 2012 at 11:39:40AM -0400, C. Michael Pilato wrote:
>> But let's back up a bit, though.
>>
>> I'm not convinced that the changes you wish to make to subtree handling are
>> all that desirable, at least when not considered as
On Wed, Jun 20, 2012 at 11:39 AM, C. Michael Pilato wrote:
> On 06/20/2012 10:59 AM, Julian Foad wrote:
>> HOW SHOULD SYMMETRIC MERGE BEHAVE?
>>
>> What does this mean for how the initial implementation of symmetric merge
>> should behave?
>>
>> My intention so far has been to make the 'sync-like'
On Wed, Jun 20, 2012 at 10:59 AM, Julian Foad
wrote:
> Warning: long email. Merge gurus and enthusiasts please comment!
>
> At the Hackathon last week, the biggest single topic I discussed with others
> was the handling of subtree merges: both the current handling (which Paul
> told me a lot ab
On Wed, Jun 20, 2012 at 2:48 PM, C. Michael Pilato wrote:
>...
> Can you at least then give a quick review on this approach for a more proper
> fix? I've not tested it ... just trying to see if I can grok your new
> magical XML handling stuff (which is pretty sweet, by the way!)
Thanks.
Your pa
On 06/20/2012 02:32 PM, Greg Stein wrote:
> On Wed, Jun 20, 2012 at 2:30 PM, C. Michael Pilato
> wrote:
>> On 06/20/2012 02:24 PM, gst...@apache.org wrote:
>>> + /* If we are talking to an old server, then the sha1-checksum property
>>> + will not exist. In our property parsing code, we don'
On Wed, Jun 20, 2012 at 2:30 PM, C. Michael Pilato wrote:
> On 06/20/2012 02:24 PM, gst...@apache.org wrote:
>> + /* If we are talking to an old server, then the sha1-checksum property
>> + will not exist. In our property parsing code, we don't bother to
>> + check the element which woul
On 06/20/2012 02:24 PM, gst...@apache.org wrote:
> + /* If we are talking to an old server, then the sha1-checksum property
> + will not exist. In our property parsing code, we don't bother to
> + check the element which would indicate a 404. That section
> + needs to name the 404'd p
On Wed, Jun 20, 2012 at 1:05 PM, Stefan Sperling wrote:
> On Wed, Jun 20, 2012 at 07:12:43AM -0400, Greg Stein wrote:
>> Stefan: this should fix your "cat" problem. If the server is old, then
>> it reports the property as missing. We don't examine the specific
>> status results (tho we should, but
On Wed, Jun 20, 2012 at 11:39:40AM -0400, C. Michael Pilato wrote:
> But let's back up a bit, though.
>
> I'm not convinced that the changes you wish to make to subtree handling are
> all that desirable, at least when not considered as part of much, much
> larger rethinking of Subversion's fundame
On Wed, Jun 20, 2012 at 07:12:43AM -0400, Greg Stein wrote:
> Stefan: this should fix your "cat" problem. If the server is old, then
> it reports the property as missing. We don't examine the specific
> status results (tho we should, but then again: we don't talk to any
> servers but our own), so w
simple_providers.c (svn_auth__simple_creds_cache_get): I propose to drop all
assignments
"need_to_save = FALSE" except the initial one; otherwise assignment to FALSE
may override existing
TRUE value. This may happen if default_username!=username and
default_password==password: in this
case ne
On 06/20/2012 10:59 AM, Julian Foad wrote:
> HOW SHOULD SYMMETRIC MERGE BEHAVE?
>
> What does this mean for how the initial implementation of symmetric merge
> should behave?
>
> My intention so far has been to make the 'sync-like' direction of
> symmetric merge (that is, same direction as previo
Warning: long email. Merge gurus and enthusiasts please comment!
At the Hackathon last week, the biggest single topic I discussed with others
was the handling of subtree merges: both the current handling (which Paul told
me a lot about), and how we could model them in a more pure/general/consis
On Wed, Jun 20, 2012 at 8:08 AM, Ivan Zhakov wrote:
> On Wed, Jun 20, 2012 at 3:12 PM, Greg Stein wrote:
>> Stefan: this should fix your "cat" problem. If the server is old, then
>> it reports the property as missing. We don't examine the specific
>> status results (tho we should, but then again:
On Jun 19, 2012, at 22:12 , s...@apache.org wrote:
> Author: stsp
> Date: Tue Jun 19 20:12:34 2012
> New Revision: 1351834
>
> URL: http://svn.apache.org/viewvc?rev=1351834&view=rev
> Log:
> Fix a crash in JavaHL due to my recent changes for delayed invocation of
> the interactive conflict resol
On Wed, Jun 20, 2012 at 3:12 PM, Greg Stein wrote:
> Stefan: this should fix your "cat" problem. If the server is old, then
> it reports the property as missing. We don't examine the specific
> status results (tho we should, but then again: we don't talk to any
> servers but our own), so we just s
Stefan: this should fix your "cat" problem. If the server is old, then
it reports the property as missing. We don't examine the specific
status results (tho we should, but then again: we don't talk to any
servers but our own), so we just see where it names
the property that was missing.
Basically
/subversion/trunk/subversion/libsvn_client/switch.c
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Another option would be to make svn choose the new behavior by not
passing a conflict resolver the old way.
And maybe you couls even take this one one s
On Wed, Jun 20, 2012 at 01:54:29AM -0400, Greg Stein wrote:
> On Jun 19, 2012 9:52 PM, wrote:
> >...
> > + if (resolve_conflicts_post_switch)
> > +{
> > + /* Remove the conflict resolution callback from the client context.
> > + * We invoke it after of the switch instead of during
21 matches
Mail list logo
