A year ago the numbers were about reversed (we haven seen 3 windows
signatures before unix). It really depends when the release is available
for testing: in weekends and holidays there are other developers active
than at the start of a businessweek.
The huge performance improvements in 1.7 (or the
On 8.1.2013 21:28, Ben Reser wrote:
I think flat out the problem is that building on Windows is just a
pain. I remember it took me several days to get a working build
environment so I could be the last signature on 1.6.19. Unfortunately
I can't be the last vote on the more recent releases becau
Ben Reser wrote on Tue, Jan 08, 2013 at 22:08:11 -0800:
> Not so much because I don't trust us as because I know not everyone is
> running absolutely every test.
Speaking of which, I think nearly no one builds+tests with non-standard
flags, such as:
-DSVN_FS_FS_DEFAULT_MAX_FILES_PER_DIR=4
-DPACK_
On Tue, Jan 8, 2013 at 9:10 PM, Daniel Shahaf wrote:
> Can buildbot provide one of the votes?
Part of the problem with the Windows build is that developers upgrade
dependencies to meeting the trunk recommendations/requirements. Then
the new versions aren't supported by the old releases. The bui
Stefan Fuhrmann wrote on Wed, Jan 09, 2013 at 05:29:02 +0100:
> Explicit tests on that platform are, therefore, indispensable. And it should
> be two independent votes rather than one to make unclean / incomplete
> builds and environments less likely to mask issues. But given Ben's
> numbers, two v
On Wed, Jan 9, 2013 at 4:36 AM, Justin Erenkrantz wrote:
> On Tue, Jan 8, 2013 at 10:07 PM, Ben Reser wrote:
>
>> Given stefan2's argument I don't think it's unreasonable to lower the
>> Windows votes, but I think removing them entirely is probably going
>> too far.
>>
>
> Given the fact that we
On Tue, Jan 8, 2013 at 10:07 PM, Ben Reser wrote:
> Given stefan2's argument I don't think it's unreasonable to lower the
> Windows votes, but I think removing them entirely is probably going
> too far.
>
Given the fact that we repeatedly have trouble securing votes just for
Windows, I think you
On Tue, Jan 8, 2013 at 6:43 PM, Justin Erenkrantz wrote:
> IMO, we should follow most other (all?) ASF projects - you need 3 +1s for
> release regardless of platform. The fact that we require 3 +1s just for
> Windows is very odd - we don't require 3 +1s for Mac and 3 +1s for RHEL and
> 3 +1s for
IMO, we should follow most other (all?) ASF projects - you need 3 +1s for
release regardless of platform. The fact that we require 3 +1s just for
Windows is very odd - we don't require 3 +1s for Mac and 3 +1s for RHEL and
3 +1s for Ubuntu, etc. -- justin
On Jan 8, 2013 3:29 PM, "Ben Reser" wrote
On Tue, Jan 8, 2013 at 3:46 PM, Gabriela Gibson
wrote:
> In line 555 and 690 in crypto.c, there are the following FIXME's:
>
> /* ### FIXME: This should be a SHA-256. */
> SVN_ERR(svn_checksum(&stuff_sum, svn_checksum_sha1, stuff_vector,
>stuff_len, scratch_pool));
T
On Thu, Dec 20, 2012 at 4:56 PM, Julian Foad wrote:
>> Author: pburba
>
>> Date: Thu Dec 20 21:19:08 2012
>> New Revision: 1424708
>>
>> URL: http://svn.apache.org/viewvc?rev=1424708&view=rev
>> Log:
>> Store repos root relative paths in NODES.INHERITED_PROPS rather than full
>> URLs.
>
> Glad to
In line 555 and 690 in crypto.c, there are the following FIXME's:
/* ### FIXME: This should be a SHA-256. */
SVN_ERR(svn_checksum(&stuff_sum, svn_checksum_sha1, stuff_vector,
stuff_len, scratch_pool));
The problem appears to be that there is no sha-256 implementation
On Tue, Jan 8, 2013 at 1:30 PM, Johan Corveleyn wrote:
> I think the problem is worse with 1.6. At least I myself was
> absolutely not looking forward to testing another release of 1.6 (but
> did it anyway, after a week or so of waiting). As you say, setting up
> a build environment for Subversion
On Tue, Jan 8, 2013 at 9:28 PM, Ben Reser wrote:
> We seem to be having trouble getting releases out the door and the
> delay is almost always related to Windows votes.
>
> Consider the following data:
> Release Planned Actual Unix vs Windows
> 1.6.19 10 Sep 2012
I'm happy to announce the release of Apache Subversion 1.6.20.
Please choose the mirror closest to you by visiting:
http://subversion.apache.org/download/#supported-releases
The SHA1 checksums are:
215083e6fc367b46fa76be82841115a32f0a5766 subversion-1.6.20.tar.gz
6b2af448dbc20b36099d
vijay wrote on Tue, Jan 08, 2013 at 15:30:46 +0530:
> On Thursday 20 December 2012 07:52 PM, vijay wrote:
>>>
>>> I note that 'svnadmin create r; svnrdump dump file://$PWD/r/foo' does
>>> not error --- maybe your patch fixes that too?
>>
>> The attached patch fixes this issue. This patch is differe
SUMMARY:
+1 to release
PLATFORM:
Windows 7
VS 2008 SP1
Java 1.6
COMPONENTS:
Apache2.2.15
OpenSSL 1.0.0a
Neon0.29.6
ZLib 1.2.4
VERIFIED:
signature and sha1
TESTED:
JavaHL
ra_local | ra_svn
RESULTS:
All passed
SIGNATURES:
subversion-1.6.20.zip
---
We seem to be having trouble getting releases out the door and the
delay is almost always related to Windows votes.
Consider the following data:
Release Planned Actual Unix vs Windows
1.6.19 10 Sep 2012 21 Sep 2012 7 days
1.7.7 09 Oct 2012 09
On Tue, Jan 8, 2013 at 3:36 PM, Branko Čibej wrote:
> On 08.01.2013 11:24, Johan Corveleyn wrote:
>> (all as disjoint working copies, the sparse working copy feature
>> is/was a bit too obscure for me, so I didn't know about that. I just
>> checked out one after the other the things I need).
>
> T
On Tue, Jan 8, 2013 at 8:36 AM, Ben Reser wrote:
> Not sure how I managed to leave the list off. If that happens again
> feel free to add the list back on.
>
> Looks like Stefan has committed an earlier version of your patch.
> I'll go ahead and fix up the changes from this patch to apply over
>
Julian Foad writes:
> Philip Martin
>
>> "Bert Huijben" writes:
+ # The incoming "move" creates a tree-conflict as an incoming change
+ # in a local move. We don't yet track moves on the server so we
+ # don't recognise the incoming change as a move.
expected_outpu
Not sure how I managed to leave the list off. If that happens again
feel free to add the list back on.
Looks like Stefan has committed an earlier version of your patch.
I'll go ahead and fix up the changes from this patch to apply over
what he committed.
On Mon, Jan 7, 2013 at 12:53 PM, Gabriela
I (Julian Foad) wrote:
> Oh, and let's not forget 'patch'. Patch looks roughly like this:
>
> * read diff information from the patch file
>
> --> merge this diff into the WC working/actual state
>
> (patch-merge, like a 3-way merge; don't record mergeinfo;
> record conflic
Philip Martin
> "Bert Huijben" writes:
>>> + # The incoming "move" creates a tree-conflict as an incoming change
>>> + # in a local move. We don't yet track moves on the server so we
>>> + # don't recognise the incoming change as a move.
>>> expected_output = svntest.wc.State(wc_dir, {
Dear merge enthusiats,
I have been formulating a plan for how to re-architect Subversion's merge
implementation -- meaning generally all the merging done by "svn merge" and
also the merging done by "svn update". I have also been thinking about how
to bring rename tracking into merging, and this w
"Bert Huijben" writes:
>> + # The incoming "move" creates a tree-conflict as an incoming change
>> + # in a local move. We don't yet track moves on the server so we
>> + # don't recognise the incoming change as a move.
>>expected_output = svntest.wc.State(wc_dir, {
>> -'A/B/E2/alpha'
On Tue, Jan 08, 2013 at 09:20:13AM -0500, Mark Phippard wrote:
> On Tue, Jan 8, 2013 at 8:57 AM, Stefan Sperling wrote:
> > Can't the intercepting code decide to ask the user to update a subtree
> > before refactoring it?
>
> The best answer I can give right now is "I do not think so".
> Generall
> -Original Message-
> From: phi...@apache.org [mailto:phi...@apache.org]
> Sent: maandag 7 januari 2013 16:11
> To: comm...@subversion.apache.org
> Subject: svn commit: r1429832 -
> /subversion/trunk/subversion/tests/cmdline/update_tests.py
>
> Author: philip
> Date: Mon Jan 7 15:11:06
On 01/08/2013 04:20 AM, i...@apache.org wrote:
> Author: ivan
> Date: Tue Jan 8 09:20:54 2013
> New Revision: 1430185
>
> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
> Log:
> mod_dav_svn: Advertise if server supports sending properties in update
> report in skelta mode.
Ivan,
What m
On Tue, 8 Jan 2013 12:40:17 +0100
Stefan Sperling wrote:
> Assume for a second that 'svn patch' already had the ability to flag
> conflicts in the working copy (this is a planned feature). Should we
> then still create an unversioned skip file or do something else?
I like the idea of being able
On 08.01.2013 11:24, Johan Corveleyn wrote:
> (all as disjoint working copies, the sparse working copy feature
> is/was a bit too obscure for me, so I didn't know about that. I just
> checked out one after the other the things I need).
This is actually an argument for my point of view. :)
Subvers
I think we should fall back to this scenario if we can't keep the move
tracked, instead of just not trying at all for these users at all.
This way those clients that must stay compatible for their users can at
least try to use the new feature instead of always do the dumb thing.
> -Original Message-
> From: Stefan Sperling [mailto:s...@apache.org]
> Sent: dinsdag 8 januari 2013 14:58
> To: Mark Phippard
> Cc: Johan Corveleyn; Philip Martin; Bert Huijben; Daniel Shahaf;
> dev@subversion.apache.org
> Subject: Re: 'svn mv' between disjoint wc's of disjoint subtrees
On Tue, Jan 8, 2013 at 8:57 AM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 08:40:19AM -0500, Mark Phippard wrote:
>> Disjoint working copies are kind of the norm for IDE users, at least
>> Eclipse. Unfortunately since it is the IDE that is kind of creating
>> this situation it is not necess
Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 11:03:41AM +0100, Neels Hofmeyr wrote:
>> I've just used 'svn patch'. There were missing target files, but I only
>> noticed a lot later; because all the text conflicts had .svnpatch.rej
>> files, but the missing targets were only listed in 'svn p
On Tue, Jan 08, 2013 at 08:40:19AM -0500, Mark Phippard wrote:
> Disjoint working copies are kind of the norm for IDE users, at least
> Eclipse. Unfortunately since it is the IDE that is kind of creating
> this situation it is not necessarily obvious to the user that there is
> anything "special"
On Tue, Jan 8, 2013 at 7:42 AM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 01:22:42PM +0100, Johan Corveleyn wrote:
>> Then let's say +0. I'd like it even better if this could be handled
>> correctly with move-tracking, but I can't help in any meaningful way
>> myself with that (and I rather
On Sun, Jan 06, 2013 at 09:38:45PM +, Gabriela Gibson wrote:
> On 04/01/13 04:07, Ben Reser wrote:
> (snip)
>
> Thank you very much for the comments.
>
> A new patch is attached.
Thanks, committed in r1430275.
Two minor nits which I left unfixed:
- You didn't linkify the packages/ director
On Tue, Jan 08, 2013 at 12:46:34PM +0100, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 10:23:22AM +, Philip Martin wrote:
> > I think move between disjoint working copies
> > will have to degrade to copy+delete,
>
> +1
>
> That should be relatively straightforward to do.
Done in r1430272
On Tue, Jan 8, 2013 at 1:42 PM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 01:22:42PM +0100, Johan Corveleyn wrote:
>> Then let's say +0. I'd like it even better if this could be handled
>> correctly with move-tracking, but I can't help in any meaningful way
>> myself with that (and I rather
On Tue, Jan 08, 2013 at 01:22:42PM +0100, Johan Corveleyn wrote:
> Then let's say +0. I'd like it even better if this could be handled
> correctly with move-tracking, but I can't help in any meaningful way
> myself with that (and I rather agree that we shouldn't postpone
> releasing for too long, a
On Tue, Jan 8, 2013 at 1:14 PM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 01:08:04PM +0100, Johan Corveleyn wrote:
>> -0 for now, but maybe I don't understand. Are you guys talking about:
>>
>> 1) 'svn mv wc1/A wc2' will error out, and user will have to figure
>> out that he needs to exec
On Tue, Jan 08, 2013 at 01:08:04PM +0100, Johan Corveleyn wrote:
> -0 for now, but maybe I don't understand. Are you guys talking about:
>
> 1) 'svn mv wc1/A wc2' will error out, and user will have to figure
> out that he needs to execute 'svn copy; svn delete'
>
> or
>
> 2) 'svn mv wc1/A wc
On Tue, Jan 08, 2013 at 09:00:38AM +, Bert Huijben wrote:
> Local moves and metadata only moves without all kinds of unexpected error
> scenarios are essential for integrations of Subversion tools in third party
> tools.
>
> *Not everybody uses ‘svn’ where move can be an interactive operation.
On Tue, Jan 8, 2013 at 12:46 PM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 10:23:22AM +, Philip Martin wrote:
>> I think move between disjoint working copies
>> will have to degrade to copy+delete,
>
> +1
>
> That should be relatively straightforward to do.
-0 for now, but maybe I don'
On Tue, Jan 08, 2013 at 10:23:22AM +, Philip Martin wrote:
> I think move between disjoint working copies
> will have to degrade to copy+delete,
+1
That should be relatively straightforward to do.
On Tue, Jan 08, 2013 at 09:56:26AM +0100, Johan Corveleyn wrote:
> Well, cross-wc.db commits are certainly supposed to work since 1.7:
>
> - issue #2381 [1] (Cannot commit multiple WC paths which lack a common
> parent directory), fixed in r1091928 by Bert.
>
> Does that mean cross-wc moves shoul
On Tue, Jan 08, 2013 at 11:03:41AM +0100, Neels Hofmeyr wrote:
> I've just used 'svn patch'. There were missing target files, but I only
> noticed a lot later; because all the text conflicts had .svnpatch.rej
> files, but the missing targets were only listed in 'svn patch' output.
>
> So in my par
"Bert Huijben" writes:
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: dinsdag 8 januari 2013 11:23
>> To: Bert Huijben
>> Cc: Daniel Shahaf; Stefan Sperling; dev@subversion.apache.org
>> Subject: Re: 'svn mv' between d
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 8 januari 2013 10:35
> To: dev@subversion.apache.org
> Subject: Re: 'svn mv' between disjoint wc's of disjoint subtrees
>
> On 08.01.2013 10:05, Bert Huijben wrote:
> > I don’t think we can keep the mov
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 8 januari 2013 10:35
> To: dev@subversion.apache.org
> Subject: Re: 'svn mv' between disjoint wc's of disjoint subtrees
>
> On 08.01.2013 10:05, Bert Huijben wrote:
> > I don’t think we can keep the mov
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 8 januari 2013 11:23
> To: Bert Huijben
> Cc: Daniel Shahaf; Stefan Sperling; dev@subversion.apache.org
> Subject: Re: 'svn mv' between disjoint wc's of disjoint subtr
On Tue, Jan 8, 2013 at 10:35 AM, Branko Čibej wrote:
> On 08.01.2013 10:05, Bert Huijben wrote:
>> I don’t think we can keep the moved-to tracking working between
>> multiple dbs, but I don't think we can just break that you can ‘svn
>> mv’ data between working copies.
>>
>> Maybe it should still
Bert Huijben writes:
> We use a single transaction for moves within one db.
> (and a transaction on both dbs at the same time for multi db)
I think we use a single transaction for the copy half of the move, but
the whole move is two transactions with the delete half as the second
transaction. T
I've just used 'svn patch'. There were missing target files, but I only
noticed a lot later; because all the text conflicts had .svnpatch.rej
files, but the missing targets were only listed in 'svn patch' output.
So in my particular case it would have helped to have .svnpatch.rej
files for missing
On Thursday 20 December 2012 07:52 PM, vijay wrote:
I note that 'svnadmin create r; svnrdump dump file://$PWD/r/foo' does
not error --- maybe your patch fixes that too?
The attached patch fixes this issue. This patch is different from the
previous versions.
We have to error out immediately if
On 08.01.2013 10:05, Bert Huijben wrote:
> I don’t think we can keep the moved-to tracking working between
> multiple dbs, but I don't think we can just break that you can ‘svn
> mv’ data between working copies.
>
> Maybe it should still work as add+delete in that case, but beaking
> scenarios is
I don’t think we can keep the moved-to tracking working between multiple
dbs, but I don't think we can just break that you can ‘svn mv’ data between
working copies.
Maybe it should still work as add+delete in that case, but beaking
scenarios is for 2.0, not for 1.8.
We shouldn’t break user scena
We use a single transaction for moves within one db.
(and a transaction on both dbs at the same time for multi db)
Moving between working copies is fully supported since 1.0.
And requiring copy + delete in scenarios where you can move no breaks case
changes on case insensitive filesystems.
Just
On Tue, Jan 8, 2013 at 1:56 AM, Stefan Sperling wrote:
> On Tue, Jan 08, 2013 at 02:28:34AM +0200, Daniel Shahaf wrote:
>> Over at infra@ we ran into an issue where an 'svn mv' between two
>> disjoint working copies --- each wc is of a different subtree of trunk
>> --- became a mv without history.
60 matches
Mail list logo
