On Wed, Feb 13, 2013 at 5:28 PM, Ben Reser wrote:
> ... Retrieving values out of a
> svn_opt_revision_t object would have exercised the issue since you're
> calling the generated accessor function
>
Err, no. The accessor functions don't go through the typemap, only
the wrappers for "real" functi
> -Original Message-
> From: phi...@apache.org [mailto:phi...@apache.org]
> Sent: vrijdag 15 februari 2013 13:09
> To: comm...@subversion.apache.org
> Subject: svn commit: r1446548 -
> /subversion/trunk/subversion/tests/cmdline/update_tests.py
>
> Author: philip
> Date: Fri Feb 15 12:08:
Stefan Sperling writes:
> Philip indicated yesterday on IRC that all local move features
> he wanted to get to implemented for 1.8 now have code written.
> So now we're all waiting for the "local moves" yellow light on
> roadmap.html to turn green.
On IRC I stated that the major features had *an
"Bert Huijben" writes:
>> + # Adding prev_status=' ' and prev_treeconflict='C' to A will make
>> + # the test PASS but why are we getting two conflicts?
>>expected_output = svntest.wc.State(wc_dir, {
>> + 'A' : Item(status=' ', treeconflict='C'),
>>})
>
> Thanks for tweaking...
>
"Bert Huijben" writes:
>> + # This update raises a tree-conflict on A. The conflict cannot be
>> + # resolved to update the move destination because the move source is
>> + # mixed rev.
>
> Is it easy to test that resolving fails?
It is already tested in op-depth-test.c:finite_move_update_bu
On Fri, Feb 15, 2013 at 01:12:49PM +, Philip Martin wrote:
> The way move-update works is that an update that attempts to change a
> move source raises move-away-edit tree-conflicts on the move source.
> The user resolves those conflicts to transfer the changes to the move
> destination. The p
On Fri, Feb 15, 2013 at 9:07 AM, Stefan Sperling wrote:
> Note that I am referring to options offered by the CLI user interface,
> not the API. The API might expose more low-level operations as has been
> requested by GUI client developers in the past. But since we haven't
> really advanced the c
On Fri, Feb 15, 2013 at 9:20 AM, Mark Phippard wrote:
> On Fri, Feb 15, 2013 at 9:07 AM, Stefan Sperling wrote:
>
>> Note that I am referring to options offered by the CLI user interface,
>> not the API. The API might expose more low-level operations as has been
>> requested by GUI client develop
> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: vrijdag 15 februari 2013 15:23
> To: Philip Martin; dev@subversion.apache.org
> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at least
start
> making alpha releases?)
>
> On Fri, Feb 15, 201
On Fri, Feb 15, 2013 at 9:57 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Mark Phippard [mailto:markp...@gmail.com]
>> Sent: vrijdag 15 februari 2013 15:23
>> To: Philip Martin; dev@subversion.apache.org
>> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at l
> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: Friday, 15 February 2013 09:23
> To: Philip Martin; dev@subversion.apache.org
> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at least
start
> making alpha releases?)
>
> On Fri, Feb 15, 2013
> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: vrijdag 15 februari 2013 16:07
> To: Bert Huijben
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: move conflict resolution UI (was: Re: branch 1.8 or at least
start
> making alpha releases?)
>
>
On Fri, Feb 15, 2013 at 10:28 AM, Bert Huijben wrote:
> I didn't write it down, but my intention would be to auto resolve everything
> within reach of the update.
>
> (root = root of wc)
> root/trunk
> root/branches
> root/branches/1.6.x
> root/branches/1.7.x
>
> svn up root/trunk
>
> So in this
Stefan Sperling writes:
> On Fri, Feb 15, 2013 at 01:12:49PM +, Philip Martin wrote:
>>
>> When such an update happens a move-away-edit tree-conflict is raised but
>> now it cannot be resolved as 'mine-conflict' to transfer the changes to
>> the move destination as the move source is not sui
I (Julian Foad) wrote on 2013-02-11:
> Alexander Thomas wrote:
>> This originated from one of my requirement where svn* binaries and
>> tools need to be installed in same location. I'm not sure this one
>> qualifies as a valid patch, because for this to happen someone
>> should tweaks Makefile.in
Hi, can anyone help me a little bit for these questions: How does SVN work
when recovering to a desired copy, specifically, how EXACTLY SVN does by
combining the delta to reconstruct a desired file version.In CVS, they
record the delta (for text file), as well as the update information like in
whic
On Fri, Feb 15, 2013 at 9:20 AM, Bo Chen wrote:
> Hi, can anyone help me a little bit for these questions: How does SVN work
> when recovering to a desired copy, specifically, how EXACTLY SVN does by
> combining the delta to reconstruct a desired file version.In CVS, they
> record the delta (for t
On Fri, Feb 15, 2013 at 12:58 AM, Roderich Schupp
wrote:
> Err, no. The accessor functions don't go through the typemap, only
> the wrappers for "real" functions do that (add a printf() or warn() at the
> start of svn_swig_pl_set_revision() to see when it's called).
I guess this depends on the S
On Fri, Feb 15, 2013 at 11:41 AM, Ben Reser wrote:
> I wouldn't bother to do the testing like this. You can create an
> _p_svn_opt_revision_t without needing to get it from something like
> svn_wc_parse_externals_description3(). e.g.
>
> my $rev = SVN::_Core::new_svn_opt_revision_t();
> $rev->ki
The attached 'merge-again-after-conflicts-1.patch' partially addresses the
problem whereby merge currently doesn't continue to the next revision range
after interactive conflict resolution, even if you resolve all the conflicts.
I'm not sure whether to commit this yet, as it's broken for non-me
20 matches
Mail list logo
