On Mon, Apr 7, 2014 at 8:01 PM, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, Apr 07, 2014 at 18:00:21 +0200:
>> A new --file-merge option is the simplest way of solving this
>> problem I could come up with. It maps the options provided by
>> the internal merge tool to a command line flag:
On 4/7/14, 2:08 PM, Justin Erenkrantz wrote:
> To be pedantic, your last phrase could be mis-interpreted - I'm pretty
> sure that you mean that someone can indeed test with multiple
> platforms; not that "each person only has one vote".
Yes that's what I mean. You can't vote twice for Windows. B
On Mon, Apr 7, 2014 at 12:03 PM, Ben Reser wrote:
> So to summarize. 3 votes must come from separate individuals. Our platform
> testing requirements do not have to be met by separate people (though each
> person obviously can only have one vote for each platform).
+1.
To be pedantic, your las
Philip Martin writes:
>> + * ### Implementation here requires lock_callback is non-null.
>
> The implementation does
>
> if (!cb_err && lock_callback)
> cb_err = lock_callback(...)
>
> which allows lock_callback to be NULL.
Ah! You were referring to the wrapping callback in libsvn
On 4/7/14, 1:29 PM, Branko Čibej wrote:
> On 07.04.2014 13:20, Daniel Shahaf wrote:
>> Ben Reser wrote on Mon, Apr 07, 2014 at 08:58:52 -0600:
>>> for alpha/beta releases (no change for release candidates or normal
>>> releases). Require at least 1 vote for each platform (Windows/Unix)
>>> and at
Julian Foad writes:
> Hi Philip. I hope you don't mind, I've made a few more review comments
> and suggestions, in the form of a patch.
It would be better if your mail program didn't convert tabs to hard
spaces, as it is I can't apply the patch.
> +/** ### Document here not what the callers wil
On 07.04.2014 13:20, Daniel Shahaf wrote:
> Ben Reser wrote on Mon, Apr 07, 2014 at 08:58:52 -0600:
>> for alpha/beta releases (no change for release candidates or normal
>> releases). Require at least 1 vote for each platform (Windows/Unix)
>> and at least 3 votes total.
> Does this apply to 1.9.
Ben Reser wrote on Mon, Apr 07, 2014 at 08:58:52 -0600:
> for alpha/beta releases (no change for release candidates or normal
> releases). Require at least 1 vote for each platform (Windows/Unix)
> and at least 3 votes total.
Does this apply to 1.9.0-alpha2?
Julian Foad wrote on Mon, Apr 07, 2014 at 13:53:36 +0100:
> Bert Huijben wrote:
> > Julian Foad wrote:
> >> +1 to the suggestion. The current two-way info is pretty difficult to use
> >> in any
> >> non-trivial case, and the 3-way suggestion is significantly more usable
> >> and not
> >> much mor
Stefan Sperling wrote on Mon, Apr 07, 2014 at 18:00:21 +0200:
> A new --file-merge option is the simplest way of solving this
> problem I could come up with. It maps the options provided by
> the internal merge tool to a command line flag:
>
> --file-merge ARG : Set a pre-defined choice
Hi Philip. I hope you don't mind, I've made a few more review comments and
suggestions, in the form of a patch.
[[[
Index: subversion/include/svn_fs.h
===
--- subversion/include/svn_fs.h (revision 1585474)
+++ subversion/include/sv
Julian Foad wrote on Mon, Apr 07, 2014 at 11:36:57 +0100:
> Daniel Shahaf wrote:
>
> > Is this a good idea? ---
>
> Sure -- why not?
>
Because I wasn't sure whether that's a supported use-case or something
that just happens to work --- compare --editor-cmd='f(){ x=$0; echo
"Template text" > "$0
Philip Martin wrote:
> Julian Foad writes:
>> Imagine the caller is an svn GUI that has an offline mode in which the
>> user can queue up lock requests, and the software will send them to
>> the server when it's back on line. Does the GUI's back end need to run
>> through the queued lock requests
Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
>
> For example.
>
> If the votin
Julian Foad wrote:
> Regarding the new 'move' functionality supporting heuristic detection of
> moves
> [...] I think, like Stefan Sperling said [1], it should probably be reverted
> or
> moved to a branch or somehow hidden from public release, in 1.9.
>
> What do you think?
Oh, I have just se
Branko Čibej wrote:
> Please note: strictly speaking, it is not really a change in policy,
> because we haven't really been producing alpha and beta releases
> until now. An alpha or beta release is still considered an Apache
> release, and therefore falls under the 3+1/no-1 rule.
It's not no -1's
Hi Stefan Fuhrmann.
Regarding the new 'move' functionality supporting heuristic detection of moves
in the log APIs, that you added a few months ago, am I right in thinking this
is experimental? At least part of it is marked so.
The APIs and UI we're talking about include at least:
'svn log -
On 7 April 2014 20:38, Stefan Fuhrmann wrote:
> On Sun, Apr 6, 2014 at 5:36 PM, Ivan Zhakov wrote:
>>
>> On 6 April 2014 18:31, Stefan Fuhrmann
>> wrote:
>> > On Wed, Apr 2, 2014 at 12:13 PM, Ivan Zhakov wrote:
>> >>
>> >> On 31 January 2014 14:57, Ivan Zhakov wrote:
>> >> > On 31 January 2014
On Mon, Apr 7, 2014 at 4:58 PM, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
>
>
On Mon, Apr 7, 2014 at 6:28 PM, Stefan Sperling wrote:
> > As far as I can tell, the svn_fs_move() is never called (quite
> surprising).
> > Moreover, I'm unable to find any unit tests for svn_fs_move(). So it's
> not
> > worth to change the repository format for non-used feature.
>
> Agreed. Bu
Stefan Sperling wrote:
> Ivan Zhakov wrote:
>> 3. I am not sure that the log adressing feature in the current
>> desing and implementaion is really valuable for users. On the other
>> side, we have the FSX format that is treated as experimental. The much
>> better way is to release log adressi
On Sun, Apr 6, 2014 at 5:36 PM, Ivan Zhakov wrote:
> On 6 April 2014 18:31, Stefan Fuhrmann
> wrote:
> > On Wed, Apr 2, 2014 at 12:13 PM, Ivan Zhakov wrote:
> >>
> >> On 31 January 2014 14:57, Ivan Zhakov wrote:
> >> > On 31 January 2014 05:50, Evgeny Kotkov
> >> > wrote:
> >> >>> This only a
On Mon, Apr 07, 2014 at 07:21:56PM +0400, Ivan Zhakov wrote:
> 3. I am not sure that the log adressing feature in the current
> desing and implementaion is really valuable for users. On the other
> side, we have the FSX format that is treated as experimental. The much
> better way is to release log
On 07.04.2014 08:58, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
>
> For example
On Mon, Apr 7, 2014 at 5:17 PM, C. Michael Pilato wrote:
> On 04/07/2014 11:10 AM, Branko Čibej wrote:
> > On 07.04.2014 09:06, C. Michael Pilato wrote:
> >> On 04/07/2014 10:58 AM, Ben Reser wrote:
> >>> Let's adopt Johan's suggestion from the other thread.
> >>>
> >>> Specifically, for alpha/bet
On 4/7/14, 9:10 AM, Branko Čibej wrote:
> On 07.04.2014 09:06, C. Michael Pilato wrote:
>> On 04/07/2014 10:58 AM, Ben Reser wrote:
>>> Let's adopt Johan's suggestion from the other thread.
>>>
>>> Specifically, for alpha/beta releases (no change for release candidates or
>>> normal releases). Req
Hi,
the patch below adds a --file-merge option, in an attempt to solve
issue #4487 "add a scriptable non-interactive option for additive merges"
http://subversion.tigris.org/issues/show_bug.cgi?id=4487
There's been a discussion on IRC about this today:
http://colabti.org/irclogger/irclogger_log/s
On 07.04.2014 09:30, Ivan Zhakov wrote:
> On 7 April 2014 18:58, Ben Reser wrote:
>> Let's adopt Johan's suggestion from the other thread.
>>
>> Specifically, for alpha/beta releases (no change for release candidates or
>> normal releases). Require at least 1 vote for each platform (Windows/Unix)
On 07.04.2014 09:33, Ivan Zhakov wrote:
> On 2 April 2014 22:24, Branko Čibej wrote:
>> On 02.04.2014 18:26, Ben Reser wrote:
>>
>> On 4/2/14, 4:08 AM, Ivan Zhakov wrote:
>>
>> So given these reasons I'm -1 on proposed release policy change.
>>
>> Can you clarify if you mean this as a veto or just
On 2 April 2014 22:24, Branko Čibej wrote:
> On 02.04.2014 18:26, Ben Reser wrote:
>
> On 4/2/14, 4:08 AM, Ivan Zhakov wrote:
>
> So given these reasons I'm -1 on proposed release policy change.
>
> Can you clarify if you mean this as a veto or just a vote against. I'm a
> tad
> fuzzy if vetos ap
On 7 April 2014 18:58, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
>
> For exam
On 4 April 2014 20:45, Ben Reser wrote:
>
> On 4/4/14, 5:02 AM, Ivan Zhakov wrote:
[...]
> > My opinion on Subversion 1.9.0 is the following: release Subversion
> > 1.9.0 ASAP without FSFS format change. We have many FSFS performance
> > improvements in trunk that doesn't require format change.
>
+1
On Mon, Apr 7, 2014 at 10:58 AM, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform
> (Windows/Unix) and
> at least 3 votes tota
On 04/07/2014 11:10 AM, Branko Čibej wrote:
> On 07.04.2014 09:06, C. Michael Pilato wrote:
>> On 04/07/2014 10:58 AM, Ben Reser wrote:
>>> Let's adopt Johan's suggestion from the other thread.
>>>
>>> Specifically, for alpha/beta releases (no change for release candidates or
>>> normal releases).
On 07.04.2014 09:06, C. Michael Pilato wrote:
> On 04/07/2014 10:58 AM, Ben Reser wrote:
>> Let's adopt Johan's suggestion from the other thread.
>>
>> Specifically, for alpha/beta releases (no change for release candidates or
>> normal releases). Require at least 1 vote for each platform (Windows
On 04/07/2014 10:58 AM, Ben Reser wrote:
> Let's adopt Johan's suggestion from the other thread.
>
> Specifically, for alpha/beta releases (no change for release candidates or
> normal releases). Require at least 1 vote for each platform (Windows/Unix)
> and
> at least 3 votes total.
Quick clar
Let's adopt Johan's suggestion from the other thread.
Specifically, for alpha/beta releases (no change for release candidates or
normal releases). Require at least 1 vote for each platform (Windows/Unix) and
at least 3 votes total.
For example.
If the voting was like this:
+3 Unix
Then we'd st
On 4/1/14, 1:17 PM, Ben Reser wrote:
> It's proving to be impossible to move forward with the alpha2 release.
>
> Let's officially say that alpha and beta releases only require 3 votes
> (platform doesn't matter). This does not apply to release candidates.
Canceling this vote. New vote incoming
On 07.04.2014 05:08, Julian Foad wrote:
> Here's a thought about what to do with this alpha release.
>
> Part of Ivan's concern is the maintenance burden and the stability of the
> FSFS changes, and alpha testing will not really help us to reveal or
> understand those issues. While we discuss tho
Julian Foad writes:
> Imagine the caller is an svn GUI that has an offline mode in which the
> user can queue up lock requests, and the software will send them to
> the server when it's back on line. Does the GUI's back end need to run
> through the queued lock requests and re-group them into bat
Bert Huijben wrote:
> Julian Foad wrote:
>> +1 to the suggestion. The current two-way info is pretty difficult to use in
>> any
>> non-trivial case, and the 3-way suggestion is significantly more usable and
>> not
>> much more difficult to understand. Furthermore it is what I expect to see for
>>
Daniel Shahaf writes:
> --- subversion/libsvn_wc/merge.c 2011-08-06 19:15:44.0 +0400
> +++ subversion/libsvn_wc/merge.c 2011-09-07 21:47:19.0 +0400
> @@ -413,7 +413,7 @@
>target_marker,
>righ
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 7 april 2014 12:32
> To: Bert Huijben
> Cc: 'Daniel Shahaf'; 'Lev Serebryakov'; dev@subversion.apache.org
> Subject: Re: Three-way merge markers by default
>
> Bert Huijben wrote:
> > Daniel Shah
Ben Reser wrote:
> [...] given that we need 3 Windows votes and the only person
> that seems to have a functional Windows setup who could vote right now seems
> to
> be you.
>
> Given our current policies that's essentially placing you in the position of
> being able to veto moving forward with
Daniel Shahaf wrote:
> Is this a good idea? ---
Sure -- why not?
> [[[
> Test that 'svnadmin freeze' is nestable.
>
> This would be useful in practice as a means to easily freeze a (small)
> number of repositories simultaneously. It also verifies that 'freeze'
> doesn't take system-global lock
Bert Huijben wrote:
> Daniel Shahaf wrote:
>> What do people feel about applying this patch (from the FreeBSD port) to
>> trunk?
[...]
>> All it does is change the contents of conflict files in --accept=postpone
>> mode: it causes conflict markers to be rendered not as two sides
>> <<
>>
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: maandag 7 april 2014 10:35
> To: dev@subversion.apache.org
> Cc: Lev Serebryakov
> Subject: Three-way merge markers by default
>
> What do people feel about applying this patch (from the FreeBSD port) to
Is this a good idea? ---
[[[
Test that 'svnadmin freeze' is nestable.
This would be useful in practice as a means to easily freeze a (small)
number of repositories simultaneously. It also verifies that 'freeze'
doesn't take system-global locks.
Incidentally, this is also the first 'svnadmin fre
What do people feel about applying this patch (from the FreeBSD port) to trunk?
[[[
http://svn.freebsd.org/ports/head/devel/subversion/files/extra-patch-3way-conflict-markers
(mod_dav_svn)
https://svnweb.freebsd.org/ports/head/devel/subversion/files/extra-patch-3way-conflict-markers?view=log
(vi
49 matches
Mail list logo
