> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 18 maart 2015 15:09
> To: dev@subversion.apache.org
> Subject: 1.7.20 release candidates up for testing/signing
>
> The 1.7.20 release is now up for testing/signing at
> https://dist.apache.org/repos/dis
Ben Reser wrote on Thu, Mar 19, 2015 at 11:33:54 -0700:
> On 3/18/15 11:57 PM, Daniel Shahaf wrote:
> > That link isn't stable: issues disappear from it as soon as they are
> > merged to 1.9.x, so if we fix issue #4560 tomorrow it won't appear in
> > the link, even though it does affect 1.9.0-beta1
Stefan Sperling wrote on Thu, Mar 19, 2015 at 11:31:09 +0100:
> On Thu, Mar 19, 2015 at 10:19:18AM +0100, Stefan Sperling wrote:
> > I agree with Daniel's point that resolving to 'mine-full' is not the same as
> > resolving to 'working'. Else, why do we even have these two different
> > options?
>
Stefan Sperling writes:
> The 1.7.20 release is now up for testing/signing at
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures there.
>
> The anticipated release day is March 31.
>
> Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures
> (segf
On 18 March 2015 at 17:04, Stefan Sperling wrote:
> The 1.8.13 release is now up for testing/signing at
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures there.
> The anticipated release day is March 31.
>
> Note that the 1.8.12 release was tagged and then skipped be
On 18 March 2015 at 17:09, Stefan Sperling wrote:
> The 1.7.20 release is now up for testing/signing at
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures there.
>
> The anticipated release day is March 31.
>
> Note that libsvn_subr/mergeinfo-test 6 and 10 may have oc
Philip Martin writes:
> node of r9, near the end of the file db/revs/0/0. On my Linux box the
db/revs/0/9 !
--
Philip
Johan Corveleyn writes:
>
> svn: E160004: Corrupt node-revision '0.0.r9/882'
> svn: E160004: Missing id field in node-rev
I don't see that on my Linux box. That's a complaint about the root
node of r9, near the end of the file db/revs/0/0. On my Linux box the
offset is 881 not 882, and the fi
On Thu, Mar 19, 2015 at 6:06 PM, Johan Corveleyn wrote:
> On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote:
>> The 1.7.20 release is now up for testing/signing at
>> https://dist.apache.org/repos/dist/dev/subversion
>> Please add your signatures there.
>>
>> The anticipated release day is M
> -Original Message-
> From: Ben Reser [mailto:bre...@apache.org]
> Sent: donderdag 19 maart 2015 19:34
> To: Daniel Shahaf
> Cc: Subversion Development
> Subject: Re: Apache Subversion 1.9.0-beta1 released
>
> On 3/18/15 11:57 PM, Daniel Shahaf wrote:
> > That link isn't stable: issues
On 3/18/15 11:57 PM, Daniel Shahaf wrote:
> That link isn't stable: issues disappear from it as soon as they are
> merged to 1.9.x, so if we fix issue #4560 tomorrow it won't appear in
> the link, even though it does affect 1.9.0-beta1.
>
> Next time, it would be better to explicitly list the known
Summary:
+1 to release
Platform:
Linux (Debian/jessie) 64-bit
Tested:
(local, svn, svn/sasl, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb)
swig-pl, swig-py, swig-rb, ctypes-python
javahl x (fsfs, bdb)
Results:
All tests successful apart from known failures for log_tests.py 37
a
On Wed, Mar 18, 2015 at 3:04 PM, Stefan Sperling wrote:
> The 1.8.13 release is now up for testing/signing at
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures there.
> The anticipated release day is March 31.
>
> Note that the 1.8.12 release was tagged and then skip
On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling wrote:
> The 1.7.20 release is now up for testing/signing at
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures there.
>
> The anticipated release day is March 31.
>
> Note that libsvn_subr/mergeinfo-test 6 and 10 may h
On 19.03.2015 11:43, Marc Strapetz wrote:
> Attached example performs an endless series of remote status against
> the Subversion repository. When invoked with -Xmx24M, the VM will run
> out of memory soon. Monitoring with jvisualvm shows that the used heap
> size constantly grows. Monitoring with
Johan Corveleyn wrote:
> Another step further, but now I get this (don't really understand why):
>
> [[[
> libsvn_delta.def : error LNK2001: unresolved external symbol
> svn_editor3__insert_shims
That function is declared in svn_editor3e.h and never defined nor referenced.
Rather than debug why i
Attached example performs an endless series of remote status against the
Subversion repository. When invoked with -Xmx24M, the VM will run out of
memory soon. Monitoring with jvisualvm shows that the used heap size
constantly grows. Monitoring with the Task Manager shows that the
allocated memo
On Thu, Mar 19, 2015 at 10:19:18AM +0100, Stefan Sperling wrote:
> I agree with Daniel's point that resolving to 'mine-full' is not the same as
> resolving to 'working'. Else, why do we even have these two different options?
>
> Perhaps the answer is to stop offering 'mine-full' for binaries, sinc
Stefan Fuhrmann writes:
> static svn_error_t *
> -test_fsfs_config_opts(const svn_test_opts_t *opts,
> - apr_pool_t *pool)
> +test_create_with_config_opts(const svn_test_opts_t *opts,
> + apr_pool_t *pool)
> {
>apr_hash_t *fs_config;
>svn
On Thu, Mar 19, 2015 at 07:27:54AM +, Bert Huijben wrote:
> If Subversion considers the file to be unmergeable, the .mine file isn't
> created, since it would be identical to the working file.)
I don't think that's a very good argument. There are two problems with this:
The book's argument hi
Why are you quoting the svnbook definition of .mine .rOLD .rNEW to me?
I know what they are.
If your point was the ".mine file isn't created because it would be
identical to the working file", then, again: I don't care about the
implementation right now. I don't care whether the contents is store
From the svn book (‘Postponing conflicts’ in the 1.7 version. Probably the main
text before interactive resolution was added)
[[
For every conflicted file, Subversion places three extra unversioned files in
your working copy:
filename.mine
This is the file as it existed in your working copy
Daniel Shahaf wrote on Thu, Mar 19, 2015 at 07:14:57 +:
> It won't be hard to turn it into a tools/dev/ script that automatically
> edits build.conf to add anything that's missing, if anyone thinks that's
> a good idea...
I have in mind a script that developers can run locally before
committin
Bert Huijben wrote on Thu, Mar 19, 2015 at 00:44:02 +0100:
> > [[[
> > svn_repos-1.lib(commit.obj) : error LNK2019: unresolved external
> > symbol _svn_editor3p__insert_shims referenced in funct
> > ion _svn_repos_get_commit_editor5
> > [C:\research\svn\dev\move-tracking-2\build\win32\vcnet-
> > vc
This is not how Subversion worked until stsp changed this earlier this week. It
worked this way for text conflicts, but not for binary conflicts.
What you ask is a bigger change, that in my opinion is better solved by storing
the conflict details as checksums pointing into the binary blob/prist
Stefan Sperling wrote on Thu, Mar 19, 2015 at 01:02:12 +0100:
> On Wed, Mar 18, 2015 at 10:53:11PM +0100, Bert Huijben wrote:
> > (Extending my original answer)
> >
> > Mine-full should just be implemented as a simple resolve without changing
> > the file. The right 'mine' file is already in the
26 matches
Mail list logo
