Definition: kidney blame == blame -r N:M with MN. Currently it is
an error (raised by svn_client_blame5()).
By and large, it should do exactly what 'blame -r M:N' does: walk the
revisions from before-the-colon revision to after-the-colon revision
and then print the contents of the after the
C. Michael Pilato 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.
+1.
+1. I'll be there by 12:00; if you could kindly
On Wed, Jun 12, 2013 at 5:52 PM, Daniel Shahaf danie...@elego.de wrote:
What about an optional output mode that prints the gaps only, but all of
them?
e.g., if I do 'blame -r 25:29', the optional output mode would print all
lines added in r26 or in r27 or in r28 that are not present in r29,
On 13.06.2013 10:35, Daniel Shahaf wrote:
It seems to me it should ideally print '3' for every line, and the user
should pass '-r 2:3' if he wants to distinguish added in r3 from
added before r3. It would be easy to preserve the current behaviour,
though, of printing '-' rather than '2'
Branko Čibej wrote on Thu, Jun 13, 2013 at 10:54:47 +0200:
On 13.06.2013 10:35, Daniel Shahaf wrote:
It seems to me it should ideally print '3' for every line, and the user
should pass '-r 2:3' if he wants to distinguish added in r3 from
added before r3. It would be easy to preserve the
On Wed, Jun 12, 2013 at 5:56 PM, Ben Reser b...@reser.org wrote:
I'm going to be on vacation for the next two weeks. I'm happy to have
the tarball and everything ready to go but it'd be nice if someone
else can do the final bit of sending the announcement email and
updating the website. If
At the risk of jinxing the proposed June 18th release date for 1.8.0,
I'm posting the proposed tarballs for signing and testing:
https://dist.apache.org/repos/dist/dev/subversion
These are cut from the same magic rev as 1.8.0-rc3, meaning that if
you've already tested rc3, you can just verify
On Wed, Jun 12, 2013 at 7:22 PM, Paul Burba ptbu...@gmail.com wrote:
Let me know if r1492295 fixes the problem for you. As you mentioned
there are other problems running the Ruby tests on Windows on an out
of tree build so I can't run the tests to completion, but this should
fix the LoadError
-Original Message-
From: Daniel Shahaf [mailto:danie...@elego.de]
Sent: donderdag 13 juni 2013 10:36
To: dev@subversion.apache.org
Subject: Kidney blame's behaviour and edge cases
Another issue: what should 'blame -r 3:3' do? Currently it is allowed,
and prints '-' for lines
Hi,
The attached patch fixes the README file for the cmdline tests to
reflect the files which are actually present in the svntest subdirectory.
[[[
Fix for the README file for the cmdline tests
* subversion/tests/cmdline/README
Fix the section about the contents of the svntest subdirectory
Hi,
Sorry, I forgot to set a subject line in my last email...
The attached patch fixes the README file for the cmdline tests to
reflect the files which are actually present in the svntest subdirectory.
[[[
Fix for the README file for the cmdline tests
* subversion/tests/cmdline/README
Fix
On Thu, Jun 13, 2013 at 1:13 PM, Markus Schaber m.scha...@codesys.com wrote:
The attached patch fixes the README file for the cmdline tests to
reflect the files which are actually present in the svntest subdirectory.
Committed in r1492634.
Hi,
This are two alternative proposals for the test suite:
Rationale: Developers restrain from implementing some tests because they just
take to much time to run at every commit.
Other test systems like JUnit, NUnit or the CODESYS Test Manager come with ways
to select unit tests by category,
What follows is my summary of a conversation held today at the Hackathon
around reducing Subversion's lengthy (and unpredictable) release cycles.
Universally, attendees expressed interest in shorter, time-based release
cycles. The sole reason stated provided for feature-driven releases was for
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
In the interest of serving our user base, we are proposing that each release
live on the trunk for at most nine months. The first six months of this
period are open to new features. In the first three months of the new
feature
On Thu, Jun 13, 2013 at 3:20 PM, Markus Schaber m.scha...@codesys.com wrote:
This are two alternative proposals for the test suite:
Rationale: Developers restrain from implementing some tests because they just
take to much time to run at every commit.
I don't think that's a problem with
Hi, Ben,
Von: Ben Reser [b...@reser.org]
On Thu, Jun 13, 2013 at 3:20 PM, Markus Schaber m.scha...@codesys.com wrote:
This are two alternative proposals for the test suite:
Rationale: Developers restrain from implementing some tests because they
just take to much time to run at every
On Thu, Jun 13, 2013 at 4:11 PM, Markus Schaber m.scha...@codesys.com wrote:
I definitely remember that an existing test case which I had written was
cut down in r1356418 because it took to long, and later converted into
an #ifdef in r1356442.
I think there's only two tests that are like that,
On 13.06.2013 15:43, Daniel Shahaf wrote:
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
In the interest of serving our user base, we are proposing that each release
live on the trunk for at most nine months. The first six months of this
period are open to new features. In
Daniel:
I think that simply enabling MN (where it is now an error) will create the
situation where the user makes a mistake, gets something they don't expect
and tries to interpret it based on their desire - leading to confusion. I
believe MN should still be an error. A new option (--reverse ?)
On Thu, Jun 13, 2013 at 6:10 PM, Doug Robinson
doug.robin...@wandisco.com wrote:
Daniel:
I think that simply enabling MN (where it is now an error) will create the
situation where the user makes a mistake, gets something they don't expect
and tries to interpret it based on their desire -
Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Jun 13, 2013 at 6:10 PM, Doug Robinson
doug.robin...@wandisco.com wrote:
Daniel:
I think that simply enabling MN (where it is now an error) will
create the
situation where the user makes a mistake, gets something they don't
expect
and tries
On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote:
On 13.06.2013 15:43, Daniel Shahaf wrote:
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
In the interest of serving our user base, we are proposing that each release
live on the trunk for at most nine
[[[
Rework branch and log message documentation. Tidy HTML.
* community-guide/conventions.part.html
(log-messages): Rework relocated branch log message documentation
moved from community-guide/general.part.html#lightweight-branches.
Remove mention of 'CIA' and substitute with ASFBot
Thanks for the patch, Gabriela. If you make a common change throughout
your patch, then you have my +1 for commit.
Some of your (patched/new) links look like this:
a href=...
LINK TEXT/a
The whitespace between the and LINK will appear significant. On a
browser, it might end up looking like:
On 06/13/2013 08:00 PM, Greg Stein wrote:
On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote:
On 13.06.2013 15:43, Daniel Shahaf wrote:
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
In the interest of serving our user base, we are proposing that each
On 13.06.2013 20:00, Greg Stein wrote:
On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote:
On 13.06.2013 15:43, Daniel Shahaf wrote:
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
In the interest of serving our user base, we are proposing that each
On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej br...@wandisco.com wrote:
On 13.06.2013 20:00, Greg Stein wrote:
...
People don't pay attention to branches. That has been empirically proven.
If you want eyeballs, then you code on trunk.
I have to disagree here -- even through you know I
On 14.06.2013 04:30, Greg Stein wrote:
On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej br...@wandisco.com wrote:
I submit it's time to change that. We've historically done everything on
trunk and released when it's ready, and the result is that every
release takes longer to produce -- 1.8 was,
29 matches
Mail list logo
