On Tue, 2010-01-26, Noorul Islam K M wrote:
> Julian Foad writes:
> > Paul Burba wrote:
> >> Also, would you mind taking a stab at expanding the test to cover
> >> Alan's original problem? Specifically that a second working copy,
> >> when updated, gets both the move destination *and* the source
Julian Foad writes:
> Paul Burba wrote:
>> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M wrote:
>> > + # Move new added file to another one and commit.
>> > + second_path = os.path.join(new_path, 'second')
>> > + rav_svn(None, None, [], 'move', first_path, second_path)
>> > + rav_svn(Non
Paul Burba wrote:
> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M wrote:
> > + # Move new added file to another one and commit.
> > + second_path = os.path.join(new_path, 'second')
> > + rav_svn(None, None, [], 'move', first_path, second_path)
> > + rav_svn(None, None, ["Committed revision
On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M wrote:
>
> Julian,
>
> Please find attached test case patch for this scenario in trunk.
>
> [[[
> Log:
>
> New XFail test case for reverse merge move scenario. Rename fails after
> reverting a commit using reverse merge. This issue need to be fixed
> On Thu, 2009-12-17, Alan Spencer wrote:
>> I've been asked to analyse a problem we have had with subversion and
>> come to the conclusion there is a bug in at least the client.
>>
>>
>> The scenario was someone committed a new directory that made a build
>> fail and in order to free up the bu
Hi Alan.
Thanks for this report, and sorry for the long time to respond.
I finally got around to converting your recipe into an executable script
(on Linux) which is attached, and with this it is easy to reproduce the
problem.
On Thu, 2009-12-17, Alan Spencer wrote:
> I've been asked to analyse
