Hi Paul,
Paul Burba wrote:
On Fri, Dec 18, 2009 at 4:16 AM, wrote:
Author: stylesen
Date: Fri Dec 18 09:16:18 2009
New Revision: 892189
URL: http://svn.apache.org/viewvc?rev=892189&view=rev
Log:
Merge r891672 from ^/subversion/trunk.
Modify subversion/tests/cmdline/externals_tests.py to cor
julianf...@apache.org wrote on Mon, 25 Jan 2010 at 17:29 -:
> Fix the expected output of an XFail test added in r902841, so that when the
> bug is fixed the test will have at least a chance of passing.
>
> + rav_svn(None, "Adding.*New|Adding.*first||Committed revision 4.", [],
You don't want
My take is deprecate the old package names (org.tigris.*), add the new
package name (org.apache.subversion.*), and remove the deprecated
names whenever we go to 2.0.
I'm moderately ambivalent on whether this happens for 1.7 or if can
wait for 1.8...
I don't see much else we can do under our versi
See below...
-- Forwarded message --
From: Greg Stein
Date: Mon, Jan 25, 2010 at 17:32
Subject: Re: Discussion: graduating Subversion
To: gene...@incubator.apache.org
On Mon, Jan 25, 2010 at 17:21, Craig L Russell wrote:
> Hi Greg,
>
> On Jan 25, 2010, at 12:49 PM, Greg Stein
On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad wrote:
> After merging all changes from a branch into the WC, a second attempt of
> the same merge brings in a different file.
>
> Full Details
>
> I tried a merge in a clean WC of the branch 1@902803, using an
> r902780M trunk build of svn. (I conf
On Fri, Dec 18, 2009 at 4:16 AM, wrote:
> Author: stylesen
> Date: Fri Dec 18 09:16:18 2009
> New Revision: 892189
>
> URL: http://svn.apache.org/viewvc?rev=892189&view=rev
> Log:
> Merge r891672 from ^/subversion/trunk.
>
> Modify subversion/tests/cmdline/externals_tests.py to correct some
> lat
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, 2010-01-25 at 11:29 -0500, Paul Burba wrote:
> On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad wrote:
> > The notification "Merging ... r891676 through ..." doesn't match the
> > actual recorded svn:mergeinfo "r891677-...".
> >
> > Full Details
> >
> > I tried a merge in a clean WC of the bra
On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad wrote:
> The notification "Merging ... r891676 through ..." doesn't match the
> actual recorded svn:mergeinfo "r891677-...".
>
> Full Details
>
> I tried a merge in a clean WC of the branch 1@902803, using an
> r902780M trunk build of svn. (I confir
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 Fri, 2010-01-22, Ivan Zhakov wrote:
> On Wed, Jan 13, 2010 at 6:04 PM, Julian Foad
> wrote:
> > On Mon, 2010-01-11, Ivan Zhakov wrote:
> > Your new patch now has a more descriptive error message, that is the
> > same as the one produced by the parse_spool_file() function, which is
> > good, b
> -Original Message-
> From: pbu...@apache.org [mailto:pbu...@apache.org]
> Sent: woensdag 6 januari 2010 17:49
> To: comm...@subversion.apache.org
> Subject: svn commit: r896522 -
> /subversion/trunk/subversion/tests/cmdline/resolve_tests.py
>
> Author: pburba
> Date: Wed Jan 6 16:48:3
Kannan wrote:
> Julian Foad wrote:
> > The notification "Merging ... r891676 through ..." doesn't match the
> > actual recorded svn:mergeinfo "r891677-...".
> [..]
> > Is that difference in the start revision of the range expected? (The
> > merge saying it's recording "r891676 through ..." versus d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
> The notification "Merging ... r891676 through ..." doesn't match the
> actual recorded svn:mergeinfo "r891677-...".
[..]
> Is that difference in the start revision of the range expected? (The
> merge saying it's recording "r891676
After merging all changes from a branch into the WC, a second attempt of
the same merge brings in a different file.
Full Details
I tried a merge in a clean WC of the branch 1@902803, using an
r902780M trunk build of svn. (I confirmed with an r902508 trunk build
that excludes the recent patch
The notification "Merging ... r891676 through ..." doesn't match the
actual recorded svn:mergeinfo "r891677-...".
Full Details
I tried a merge in a clean WC of the branch 1@902803, using an
r902780M trunk build of svn. (I confirmed with an r902508 trunk build
that excludes the recent patch to
On Sat, 2010-01-23, Paul Burba wrote:
> I committed this enhancement in r902509.
Thanks, Paul.
> A few things to note:
>
> 1) In my example at the start of this thread I used an ' A'
> notification to denote the addition of a mergeinfo property. That
> does not agree with how we notify propert
Hyrum K. Wright wrote:
> On Jan 25, 2010, at 1:17 AM, Noorul Islam K M wrote:
> > @@ -4352,7 +4390,8 @@
> > path_copy_in_repo_2475,
> > commit_copy_depth_empty,
> > copy_below_copy,
> > - XFail(move_below_move)
> > + XFail(move_bel
On Jan 25, 2010, at 1:17 AM, Noorul Islam K M wrote:
>
>> 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 dire
19 matches
Mail list logo
