-Original Message-
From: Julian Foad [mailto:julianf...@btopenworld.com]
Sent: woensdag 12 juni 2013 00:28
To: Bert Huijben
Cc: Stefan Sperling; 'Johan Corveleyn'; 'Subversion Development'
Subject: Re: Automatic tree conflicts resolution during svn update
Bert Huijben wrote:
On Wed, Jun 12, 2013 at 8:52 AM, rhuij...@apache.org wrote:
Author: rhuijben
Date: Wed Jun 12 06:52:44 2013
New Revision: 1492079
URL: http://svn.apache.org/r1492079
Log:
* STATUS: Extend group and cast vote
Modified:
subversion/branches/1.8.x/STATUS
Modified:
On Wed, Jun 12, 2013 at 08:47:32AM +0200, Bert Huijben wrote:
At the time we are resolving the BASE nodes at the original location have
been updated to the target revision, but the place that the code has been
moved to is still at the old revision.
Doing nothing keeps you in a state where
On 06/11/2013 05:42 PM, Stefan Sperling wrote:
On Mon, Jun 10, 2013 at 07:21:19PM +0400, Danil Shopyrin wrote:
The current draft of the Subversion 1.8 Release Notes announces
automatic tree conflicts resolution for locally moved files and
directories. But it seems that this feature does not
danie...@apache.org wrote on Wed, Jun 12, 2013 at 10:29:35 -:
Author: danielsh
Date: Wed Jun 12 10:29:34 2013
New Revision: 1492134
URL: http://svn.apache.org/r1492134
Log:
Add an XFail test for 'svn blame -r 3:1' (where 3 1).
Not filing an issue since I plan to commit a fix soon.
On Tue, Jun 11, 2013 at 4:12 PM, Stefan Sperling s...@elego.de wrote:
I think the problem with 'svn' is that the menu options were too hard
to figure out. After some discussion with Ivan, I've tweaked the conflict
prompt menu for clarity in this commit: http://svn.apache.org/r1491762
Does
Daniel Shahaf wrote:
danie...@apache.org wrote on Wed, Jun 12, 2013 at 10:29:35 -:
Author: danielsh
Date: Wed Jun 12 10:29:34 2013
New Revision: 1492134
URL: http://svn.apache.org/r1492134
Log:
Add an XFail test for 'svn blame -r 3:1' (where 3 1).
Not filing an issue since
On Wed, Jun 12, 2013 at 12:59 PM, Danil Shopyrin da...@visualsvn.com wrote:
On Tue, Jun 11, 2013 at 4:12 PM, Stefan Sperling s...@elego.de wrote:
I think the problem with 'svn' is that the menu options were too hard
to figure out. After some discussion with Ivan, I've tweaked the conflict
Julian Foad wrote on Wed, Jun 12, 2013 at 12:22:31 +0100:
Daniel Shahaf wrote:
danie...@apache.org wrote on Wed, Jun 12, 2013 at 10:29:35 -:
Author: danielsh
Date: Wed Jun 12 10:29:34 2013
New Revision: 1492134
URL: http://svn.apache.org/r1492134
Log:
Add an XFail
Kinda wish we hadn't merged this into 1.8.x. Unless we revert this
means there will be changes to the 1.8.0 tarball from rc3. I'm fine
with that, but I'm not sure I would have done it for just this change
since it increases the testing that has to be done (at least one
Windows) for the final
On Wed, Jun 12, 2013 at 01:34:37PM +0200, Johan Corveleyn wrote:
Can't we improve this? (not talking about emergency fixing 1.8.x, but
thinking longer term). Can't we put the incoming edits somewhere, so
the user can do something useful (manually) with them? Perhaps put
them in the moved-file
On Wed, Jun 12, 2013 at 02:59:26PM +0400, Danil Shopyrin wrote:
The new prompt menu makes a great improvement. The most important part
is that 'apply edit' action is marked as 'recommended'.
I've gone one step further and removed the non-recommended option
from the prompt. It now looks like
On Wed, Jun 12, 2013 at 1:57 PM, Ben Reser b...@reser.org wrote:
Kinda wish we hadn't merged this into 1.8.x. Unless we revert this
means there will be changes to the 1.8.0 tarball from rc3. I'm fine
with that, but I'm not sure I would have done it for just this change
since it increases the
On Wed, Jun 12, 2013 at 10:48 AM, rhuij...@apache.org wrote:
Author: rhuijben
Date: Wed Jun 12 08:48:32 2013
New Revision: 1492118
URL: http://svn.apache.org/r1492118
Log:
* STATUS: Extend group to fix merge
Modified:
subversion/branches/1.8.x/STATUS
Modified:
Markus Schaber wrote:
On Mon, Jun 10, 2013 at 01:38:48PM -, danie...@apache.org wrote:
It would have been easy to find what revision removed the line break if we
had a reverse blame --- that is, a blame that walks the chain of diffs from
newerto older, rather than from older to newer.
Hi All,
I came across a bug in one of the Atlassian tools that suggests that there
was an API compatibility break in the JavaHL between versions 1.6 and 1.7.
I am not sure when/if I get time to look more into it, therefore I am
sharing with the group meanwhile. The following comment is from the
On Wed, Jun 12, 2013 at 1:57 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 01:34:37PM +0200, Johan Corveleyn wrote:
Can't we improve this? (not talking about emergency fixing 1.8.x, but
thinking longer term). Can't we put the incoming edits somewhere, so
the user can do
On 6/11/13, Daniel Shahaf danie...@elego.de wrote:
Gabriela Gibson wrote on Mon, Jun 10, 2013 at 23:39:45 +0100:
On 6/10/13, Daniel Shahaf danie...@elego.de wrote:
* @a invoke_diff_cmd takes an argument which is used to call an
* external diff program. When invoked, the argument may not be
On 12.06.2013 08:47, Bert Huijben wrote:
-Original Message-
From: Julian Foad [mailto:julianf...@btopenworld.com]
Sent: woensdag 12 juni 2013 00:28
To: Bert Huijben
Cc: Stefan Sperling; 'Johan Corveleyn'; 'Subversion Development'
Subject: Re: Automatic tree conflicts resolution
On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
Okay, but doesn't postpone still needs to have a well defined
behavior (and probably as good as possible), even if only for
supporting the --accept=postpone command line option?
What is as good as possible?
The --accept postpone
On Wed, Jun 12, 2013 at 3:25 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
Okay, but doesn't postpone still needs to have a well defined
behavior (and probably as good as possible), even if only for
supporting the --accept=postpone
On Wed, Jun 12, 2013 at 3:26 PM, Branko Čibej br...@wandisco.com wrote:
Messing with a release candidate for the sake of a couple minor test
suite tweaks is not my idea of sane release management.
In other words, -1 to putting this in 1.8.0. Instead, I propose we
revert that change and
Ben Reser wrote on Wed, Jun 12, 2013 at 15:32:58 +0200:
On Wed, Jun 12, 2013 at 3:26 PM, Branko Čibej br...@wandisco.com wrote:
Messing with a release candidate for the sake of a couple minor test
suite tweaks is not my idea of sane release management.
In other words, -1 to putting this
-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com]
Sent: woensdag 12 juni 2013 15:20
To: dev@subversion.apache.org
Subject: Re: Automatic tree conflicts resolution during svn update
On 12.06.2013 08:47, Bert Huijben wrote:
-Original Message-
From:
On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
I'd say, just edit the moved file with the incoming content, embedded
in conflict markers, just like what we do for text conflicts. That, I
think, would be as good as possible.
That's basically what updating the move is doing
On Wed, Jun 12, 2013 at 3:35 PM, Daniel Shahaf danie...@elego.de wrote:
Note that if you revert it, the mergebot will just merge it _again_ the
following night (your time), unless you also move the entry out of the
(second) Approved section.
Thanks for the reminder.
Hi Prabhu,
below is my review of the changes on the verify-keep-going branch.
Most of my comments point out minor formatting issues. I believe
the test part is the only code that might need some adjustment.
Otherwise it looks very good to me.
Index: BRANCH-README
On 06/12/2013 06:57 PM, Johan Corveleyn wrote:
On Wed, Jun 12, 2013 at 3:25 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 03:04:56PM +0200, Johan Corveleyn wrote:
Okay, but doesn't postpone still needs to have a well defined
behavior (and probably as good as possible), even
On 06/12/2013 05:55 PM, Julian Foad wrote:
Markus Schaber wrote:
On Mon, Jun 10, 2013 at 01:38:48PM -, danie...@apache.org wrote:
It would have been easy to find what revision removed the line break if we
had a reverse blame --- that is, a blame that walks the chain of diffs from
newerto
On 12.06.2013 14:42, Vladimir Berezniker wrote:
Hi All,
I came across a bug in one of the Atlassian tools that suggests that
there was an API compatibility break in the JavaHL between versions
1.6 and 1.7. I am not sure when/if I get time to look more into it,
therefore I am sharing with
On Wed, Jun 12, 2013 at 2:06 PM, i...@apache.org i...@apache.org wrote:
Author: ivan
Date: Wed Jun 12 12:06:03 2013
New Revision: 1492168
URL: http://svn.apache.org/r1492168
Log:
Implement '--log' option for 'svn mergeinfo --show-revs' subcommand to print
revisions log message, author and
On 12.06.2013 15:42, Bert Huijben wrote:
-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com]
Sent: woensdag 12 juni 2013 15:20
To: dev@subversion.apache.org
Subject: Re: Automatic tree conflicts resolution during svn update
On 12.06.2013 08:47, Bert Huijben wrote:
-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com]
Sent: woensdag 12 juni 2013 16:13
To: dev@subversion.apache.org
Subject: Re: Automatic tree conflicts resolution during svn update
On 12.06.2013 15:42, Bert Huijben wrote:
-Original Message-
From:
On Wed, Jun 12, 2013 at 10:03 AM, bre...@apache.org wrote:
Author: breser
Date: Wed Jun 12 14:03:00 2013
New Revision: 1492211
URL: http://svn.apache.org/r1492211
Log:
Revert r1492189, this isn't nearly enough to enable https support.
Yeah... I don't think asyncore can really handle SSL
On Wed, Jun 12, 2013 at 2:25 PM, Julian Foad julianf...@btopenworld.com wrote:
Markus Schaber wrote:
On Mon, Jun 10, 2013 at 01:38:48PM -, danie...@apache.org wrote:
It would have been easy to find what revision removed the line break if we
had a reverse blame --- that is, a blame that
On Wed, Jun 12, 2013 at 5:03 PM, Greg Stein gst...@gmail.com wrote:
Yeah... I don't think asyncore can really handle SSL sockets. But
maybe using ssl.wrap_socket() could make it work. Override
create_socket(), provide some more params, etc.
Client should probably support https even if server
On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
I'd say, just edit the moved file with the incoming content, embedded
in conflict markers, just like what we do for text conflicts. That, I
think, would be as
Lieven Govaerts wrote:
On Wed, Jun 12, 2013 at 2:06 PM, i...@apache.org i...@apache.org wrote:
URL: http://svn.apache.org/r1492168
Log:
Implement '--log' option for 'svn mergeinfo --show-revs'
subcommand to print revisions log message, author and date.
Thank you!
This makes sense to
Lieven Govaerts wrote on Wed, Jun 12, 2013 at 16:10:46 +0200:
On Wed, Jun 12, 2013 at 2:06 PM, i...@apache.org i...@apache.org wrote:
Author: ivan
Date: Wed Jun 12 12:06:03 2013
New Revision: 1492168
URL: http://svn.apache.org/r1492168
Log:
Implement '--log' option for 'svn
Julian Foad wrote on Wed, Jun 12, 2013 at 16:29:52 +0100:
More generally, how many features of svn log do we want svn mergeinfo
--log to support?
--diff?
--quiet?
--verbose?
--search?
Can we think of a way of enabling these kinds of options, that doesn't
involve expanding the
Prabhu wrote:
On 06/12/2013 05:55 PM, Julian Foad wrote:
I have thought before that it would sometimes be useful to include blame
information on the gaps between lines. For each gap between adjacent lines
(and
before the first and after the last line), there is a revision in which any
On Wed, Jun 12, 2013 at 05:24:39PM +0200, Johan Corveleyn wrote:
On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
I'd say, just edit the moved file with the incoming content, embedded
in conflict markers,
Julian Foad wrote on Wed, Jun 12, 2013 at 16:41:59 +0100:
Prabhu wrote:
On 06/12/2013 05:55 PM, Julian Foad wrote:
I have thought before that it would sometimes be useful to include blame
information on the gaps between lines. For each gap between adjacent
lines (and
before the
1.8.0 expected release date is June 18th. So we'll need to have it
signed and staging to mirrors on the 17th. As a result I expect to
produce the 1.8.0 final tarball in the next few days. Since we should
have no changes from the rc3 tarball other than the version it
announces it should be
URL: http://svn.apache.org/r1492168
Log:
Implement '--log' option for 'svn mergeinfo --show-revs' subcommand to print
revisions log message, author and date.
* subversion/svn/mergeinfo-cmd.c
(): Include svn_compat.h and svn_props.h.
(SEP_STRING, print_log_details): New.
On 06/12/2013 07:07 AM, Branko Čibej wrote:
On 12.06.2013 14:42, Vladimir Berezniker wrote:
Hi All,
I came across a bug in one of the Atlassian tools that suggests that
there was an API compatibility break in the JavaHL between versions
1.6 and 1.7. I am not sure when/if I get time to look
On Tue, Jun 11, 2013 at 7:16 AM, Ben Reser b...@reser.org wrote:
On Fri, Jun 7, 2013 at 4:52 PM, Ben Reser b...@reser.org wrote:
I really don't understand why this change is necessary at all since as
you can see above the source tree is added to the load path with -I.
Sorry Ben, I missed your
On 12.06.2013 19:18, Blair Zajac wrote:
On 06/12/2013 07:07 AM, Branko Čibej wrote:
On 12.06.2013 14:42, Vladimir Berezniker wrote:
Hi All,
I came across a bug in one of the Atlassian tools that suggests that
there was an API compatibility break in the JavaHL between versions
1.6 and 1.7.
https://wiki.apache.org/subversion/Berlin2013 has 14 discussion items.
We haven't discussed any of them yet. When shall we do so? Tomorrow?
Friday?
On Wed, Jun 12, 2013 at 11:36 PM, Daniel Shahaf danie...@elego.de wrote:
https://wiki.apache.org/subversion/Berlin2013 has 14 discussion items.
We haven't discussed any of them yet. When shall we do so? Tomorrow?
Friday?
Thursday 11:00. Maybe continue after Lunch.
-- Stefan^2.
On 06/12/2013 11:41 PM, Stefan Fuhrmann wrote:
On Wed, Jun 12, 2013 at 11:36 PM, Daniel Shahaf danie...@elego.de
mailto:danie...@elego.de wrote:
https://wiki.apache.org/subversion/Berlin2013 has 14 discussion items.
We haven't discussed any of them yet. When shall we do so?
On Wed, Jun 12, 2013 at 5:46 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 05:24:39PM +0200, Johan Corveleyn wrote:
On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling s...@elego.de wrote:
On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
I'd say, just edit the
Before I forget, I just noticed that there is no mention anywhere in
the release notes about the http-bulk-updates or the corresponding
server side options. I think it's important to at least mention them,
and hopefully give some recommendations, in the section about serf.
The yellow box there,
53 matches
Mail list logo
