defined symbols (SVN_WITH_SYMMETRIC_MERGE)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
If that would be the problem here the windows ra buildbot would have
failed.
I think the problem is that the extractor wasn't used, while public
APIs were added/
defined symbols (SVN_WITH_SYMMETRIC_MERGE)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
You probably need a other gen-make.py call to regenerate the .def files
before building.
Bert Huijben (Cell phone)
From: Johan Corveleyn
Sent: 10-4-2012 3:20
To:
Johan Corveleyn wrote on Tue, Apr 10, 2012 at 03:19:24 +0200:
> (This reminds me of a similar problem I had a couple of months ago
> with some debug helpers which were also only defined conditional on
> SVN_DEBUG. I fixed it by moving the #ifdef SVN_DEBUG markers a bit
> deeper so the functions wer
On Mon, Apr 9, 2012 at 4:00 PM, Daniel Shahaf wrote:
> Joe Swatosh wrote on Mon, Apr 09, 2012 at 15:25:47 -0700:
>> Hi Daniel,
>> On Sun, Apr 8, 2012 at 2:30 PM, Daniel Shahaf wrote:
>> > joeswat...@apache.org wrote on Fri, Apr 06, 2012 at 18:28:30 -:
>> >> Author: joeswatosh
>> >> Date: Fri
Hi,
I haven't built trunk for a while, and now that I'm catching up I get
the following build errors (with my release build):
libsvn_client.def : error LNK2001: unresolved external symbol
svn_client__do_symmetric_merge
libsvn_client.def : error LNK2001: unresolved external symbol
svn_client__find
Joe Swatosh wrote on Mon, Apr 09, 2012 at 15:25:47 -0700:
> Hi Daniel,
>
> On Sun, Apr 8, 2012 at 2:30 PM, Daniel Shahaf wrote:
> > joeswat...@apache.org wrote on Fri, Apr 06, 2012 at 18:28:30 -:
> >> Author: joeswatosh
> >> Date: Fri Apr 6 18:28:30 2012
> >> New Revision: 1310535
> >>
>
>
Hi Daniel,
On Sun, Apr 8, 2012 at 2:30 PM, Daniel Shahaf wrote:
> joeswat...@apache.org wrote on Fri, Apr 06, 2012 at 18:28:30 -:
>> Author: joeswatosh
>> Date: Fri Apr 6 18:28:30 2012
>> New Revision: 1310535
>>
>> def test_changelists_get_without_block
>> assert_changelists do |c
Just talked a bit about the move problem with Justin. I figured out that if
src or dst are not in the negotiated root, then you are NOT moving. You
delete, or you copy [from the repository]. Ev2 just needs to edit the
receiver's state to a new state. It does not have to retain history about a
move.
(sorry for terse toppost; phone)
Yeah, I was concerned about switched paths, too, but haven't figured out a
solid way to represent copy sources in an update. Maybe src_relpath is
always repos-based, and dst is negotiated.
But that doesn't translate well to move's semantics.
On Apr 9, 2012 5:03 PM
On Mon, Apr 9, 2012 at 4:34 PM, wrote:
> Author: stefan2
> Date: Mon Apr 9 21:34:21 2012
> New Revision: 1311469
>
> URL: http://svn.apache.org/viewvc?rev=1311469&view=rev
> Log:
> Add special API for reading and writing integer settings
> (similar to what we already have for bools).
>
> * subve
> -Original Message-
> From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com]
> Sent: maandag 9 april 2012 17:26
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Subject: Re: Ev2 paths (was: svn commit: r1310925 ...)
> For repos->wc drives, my initial thought was to have the "relpath
On Sat, Apr 7, 2012 at 7:35 PM, Greg Stein wrote:
> Hyrum,
>
> This is a start to fix the URL issue. I'm away for a while, so feel
> free to patch up the two map_to_* functions with the right magic.
That's just like you: break everything and then go on vacation. ;)
> There is a separate issue ab
On Sun, Apr 8, 2012 at 4:35 AM, Greg Stein wrote:
> One thought: maybe it is proper/appropriate to simply state that the
> relpath values *must* be repos_relpath values. IOW, that Ev2 drives
> are always in reference to a given repository; thus, all relpaths must
> be relative to that repos root.
13 matches
Mail list logo
