On Wed, May 18, 2011 at 3:24 PM, Ivan Zhakov wrote:
> On Wed, May 18, 2011 at 15:20, Daniel Shahaf wrote:
>> Milestone? 1.7.0? 1.7.0-consider?
>>
> Hi,
>
> It's definitely 1.7.0. Thanks for pointing on that.
I've got a hunch that r1468 in serf fixes this. Can you please
confirm? (It fixes th
On 05/19/2011 08:11 AM, Stefan Küng wrote:
>> Hrm. I rather expected that this change would have two components:
>>
>> 1. Remove references to 'svn' subcommands from share lib error messages.
>> 2. From the same places, return unique-enough error codes that the client
>> catches so *it* can give
On Wed, May 18, 2011 at 22:28, C. Michael Pilato wrote:
> On 05/18/2011 08:47 PM, stevek...@apache.org wrote:
>> Author: steveking
>> Date: Wed May 18 18:47:42 2011
>> New Revision: 1124375
>>
>> URL: http://svn.apache.org/viewvc?rev=1124375&view=rev
>> Log:
>> Resolve issue #3887, "Eliminate clie
Likewise. We asked Ivan to file a bug about it.
On May 19, 2011 12:55 AM, "Lieven Govaerts" wrote:
> On Wed, May 18, 2011 at 5:53 PM, wrote:
>
>> Author: cmpilato
>> Date: Wed May 18 15:53:04 2011
>> New Revision: 1124306
>>
>> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
>> Log:
>> * n
On 05/19/2011 12:54 AM, Lieven Govaerts wrote:
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven
I'd better let Ivan explain that, as it was from he that I learned of the
problem just this morning. Ivan?
--
C. Michael Pilato
CollabNet <>
On Wed, May 18, 2011 at 5:53 PM, wrote:
> Author: cmpilato
> Date: Wed May 18 15:53:04 2011
> New Revision: 1124306
>
> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
> Log:
> * notes/berlin-11-agenda
> Add my first-pass notes about the discussions we've had here in
> Berlin. Others ma
> -Original Message-
> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
> Sent: woensdag 18 mei 2011 23:22
> To: dev@subversion.apache.org
> Cc: comm...@subversion.apache.org
> Subject: Re: svn commit: r1104160 -
> /subversion/trunk/subversion/libsvn_subr/utf.c
>
> 2011/5/18 Branko Či
On Wed, May 18, 2011 at 9:25 PM, Johan Corveleyn wrote:
> On Wed, May 18, 2011 at 9:23 PM, Johan Corveleyn wrote:
>> On Wed, May 18, 2011 at 7:31 PM, Morten Kloster wrote:
>>> Thanks, Daniel.
>>>
>>> Johan:
>>> I've found your notes trunk/notes/diff-optimizations.txt. As you may
>>> have realize
2011/5/18 Branko Čibej :
> On 17.05.2011 14:16, Hyrum K Wright wrote:
>> apr_atomic_xchgptr() and friends are not available on APR 0.9. (This
>> is causing a buildbot build failure.)
>
> Maybe we should just drop support for APR-0.9 finally? I know that we
> sort of "promise" to support it, but re
On 05/18/2011 11:08 PM, Bob Archer wrote:
> "Source and destination URLs do not point to the same repository."
>
> ... is what he wanted?
Yes. At least, that's what the sleep-deprived remains of my brain is
telling me at the moment.
--
C. Michael Pilato
CollabNet <> www.collab.net <>
> On Wed, May 18, 2011 at 10:52 PM, C. Michael Pilato
> wrote:
> > On 05/18/2011 09:44 PM, Bob Archer wrote:
> >>> while working on issue #3887 I discovered an error message that
> >>> doesn't
> >>> sound right to me, but English is not my native language so I
> might
> >>> be
> >>> wrong:
> >>>
>
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej
> Sent: woensdag 18 mei 2011 21:25
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1103749 -
> /subversion/trunk/subversion/libsvn_wc/wc_db_wcroot.c
>
> On 17.05.2011 12:37, Stefan Fuhrm
On Wed, May 18, 2011 at 10:52 PM, C. Michael Pilato wrote:
> On 05/18/2011 09:44 PM, Bob Archer wrote:
>>> while working on issue #3887 I discovered an error message that
>>> doesn't
>>> sound right to me, but English is not my native language so I might
>>> be
>>> wrong:
>>>
>>> Source and destin
On 05/18/2011 09:44 PM, Bob Archer wrote:
>> while working on issue #3887 I discovered an error message that
>> doesn't
>> sound right to me, but English is not my native language so I might
>> be
>> wrong:
>>
>> Source and destination URLs appear not to all point to the same
>> repository.
>
> Sh
On 05/18/2011 08:47 PM, stevek...@apache.org wrote:
> Author: steveking
> Date: Wed May 18 18:47:42 2011
> New Revision: 1124375
>
> URL: http://svn.apache.org/viewvc?rev=1124375&view=rev
> Log:
> Resolve issue #3887, "Eliminate client-specific suggestions from shared
> libraries", by changing th
Bob Archer wrote on Wed, May 18, 2011 at 15:44:25 -0400:
> > while working on issue #3887 I discovered an error message that
> > doesn't
> > sound right to me, but English is not my native language so I might
> > be
> > wrong:
> >
> > Source and destination URLs appear not to all point to the same
> while working on issue #3887 I discovered an error message that
> doesn't
> sound right to me, but English is not my native language so I might
> be
> wrong:
>
> Source and destination URLs appear not to all point to the same
> repository.
Should it be:
"Source and destination URLs do not all
On 17.05.2011 11:36, Stefan Sperling wrote:
> On Tue, May 17, 2011 at 12:45:50AM +0200, Stefan Sperling wrote:
>> Any comments or objections?
> Neels didn't like the arbitrary "round to 00:00 of next day" rules
> and everyone in the hackathon room seems to agree. So "one day ago"
> is now the same
On Wed, May 18, 2011 at 9:23 PM, Johan Corveleyn wrote:
> On Wed, May 18, 2011 at 7:31 PM, Morten Kloster wrote:
>> Thanks, Daniel.
>>
>> Johan:
>> I've found your notes trunk/notes/diff-optimizations.txt. As you may
>> have realized, my patch is a slightly different approach to the
>> problem yo
On 17.05.2011 12:37, Stefan Fuhrmann wrote:
> On 17.05.2011 10:11, Greg Stein wrote:
>> On May 16, 2011 10:29 AM, wrote:
>>> Author: stefan2
>>> Date: Mon May 16 14:28:45 2011
>>> New Revision: 1103749
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1103749&view=rev
>>> Log:
>>> SVN status will try
On Wed, May 18, 2011 at 7:31 PM, Morten Kloster wrote:
> Thanks, Daniel.
>
> Johan:
> I've found your notes trunk/notes/diff-optimizations.txt. As you may
> have realized, my patch is a slightly different approach to the
> problem you discuss in section I.5, "Discarding non-matching
> lines before
`svn log -r{DATE}` recently stopped to work correctly. I use Subversion trunk
r1124331.
Example in working copy of Subversion trunk:
$ svn log -r{2011-05-15}
$
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Descrip
On Wed, 2011-05-18 at 14:24 -0400, Stefan Küng wrote:
> the "not to all point..." just doesn't sound right.
It's a split infinitive, which doesn't make it necessarily bad English
but can make it sound wrong. "Not to point to the same repository"
would be more concise and just as precise, in my op
On Wed, May 18, 2011 at 6:32 PM, Paul Burba wrote:
> On Tue, May 17, 2011 at 9:48 AM, Mark Phippard wrote:
>
>> There are some vetos in the 1.6.x branch that seem like they are
>> questioning the change, not just whether it was a candidate for
>> backport. What does that mean for trunk and 1.7?
Hi,
while working on issue #3887 I discovered an error message that doesn't
sound right to me, but English is not my native language so I might be
wrong:
Source and destination URLs appear not to all point to the same repository.
the "not to all point..." just doesn't sound right.
This is i
Thanks, Daniel.
Johan:
I've found your notes trunk/notes/diff-optimizations.txt. As you may
have realized, my patch is a slightly different approach to the
problem you discuss in section I.5, "Discarding non-matching
lines before running the LCS (Longest Common Subsequence)
algorithm." - rather th
On 18.05.2011 13:47, C. Michael Pilato wrote:
On 05/18/2011 12:44 PM, Hyrum K Wright wrote:
On Wed, May 18, 2011 at 11:17 AM, C. Michael Pilato wrote:
On 05/18/2011 09:53 AM, Bert Huijben wrote:
One obvious case is that libsvn_client sometimes suggests that you
should do a 'svn something', wh
On Tue, May 17, 2011 at 9:48 AM, Mark Phippard wrote:
> There are some vetos in the 1.6.x branch that seem like they are
> questioning the change, not just whether it was a candidate for
> backport. What does that mean for trunk and 1.7? Here are the items
> I am thinking of (leaving out the it
On 05/18/2011 03:35 PM, Mark Phippard wrote:
> I think there are two primary things that you could accomplish by
> being together and able to talk to each other:
>
> 1) Talk about what stands between where we are now and a finished
> release. Make note of any items not captured in the tracker and
On Wednesday 18 May 2011 08:03 PM, Paul Burba wrote:
On Wed, May 18, 2011 at 9:15 AM, Arwin Arni wrote:
Hi All,
I have attached a test case for Issue 3867
(http://subversion.tigris.org/issues/show_bug.cgi?id=3867)
Issue Summary:
reintegrate merges create mergeinfo for non-existent paths
Rega
> Fire up your testing environments: they're going to get some use
> over
> the next couple of months.
>
> In an effort to release early and often, I'd like to cut the first
> 1.7.0 pre-release on June 1. This will likely be a beta release,
> since there are still blocking issues, but I hope to g
On Wed, May 18, 2011 at 9:59 AM, Mark Phippard wrote:
> On Wed, May 18, 2011 at 2:55 AM, Daniel Shahaf
> wrote:
>> Mike remarked that svn:mergeinfo should never have been user-visible...
>>
>> So: what if we made svn_property_kind(NULL, SVN_PROP_MERGEINFO) return
>> a value other than svn_prop_r
On Wed, May 18, 2011 at 9:15 AM, Arwin Arni wrote:
> Hi All,
>
> I have attached a test case for Issue 3867
> (http://subversion.tigris.org/issues/show_bug.cgi?id=3867)
>
> Issue Summary:
> reintegrate merges create mergeinfo for non-existent paths
>
> Regards,
> Arwin Arni
Thanks Arwin. I commi
Paul Burba wrote on Wed, May 18, 2011 at 09:51:17 -0400:
> On Wed, May 18, 2011 at 5:41 AM, Hyrum K Wright wrote:
> > On Wed, May 18, 2011 at 9:32 AM, Bert Huijben wrote:
> >> It would completely break mergetracking for about a dozen reasons :(
> >>
> >> I'll answer more detailed later, but this
On Wed, May 18, 2011 at 2:55 AM, Daniel Shahaf wrote:
> Mike remarked that svn:mergeinfo should never have been user-visible...
>
> So: what if we made svn_property_kind(NULL, SVN_PROP_MERGEINFO) return
> a value other than svn_prop_regular_kind, at least when both server and
> client were ≥1.7?
On Wed, May 18, 2011 at 3:51 PM, Paul Burba wrote:
...
>>> [I suspect it might, but want to hear others' thoughts before laying
>>> out my own.]
>>
>> I don't think hiding it completely is the way to go, but there has
>> been some half-implemented code to filter propchanges from various
>> operati
On Wed, May 18, 2011 at 3:43 PM, Julian Foad wrote:
> C. Michael Pilato wrote:
>> On 05/18/2011 02:02 PM, C. Michael Pilato wrote:
>> > On 05/18/2011 01:34 PM, C. Michael Pilato wrote:
>> >> You mentioned not being able to provide a patch, but would you be
>> >> willing/able to at least file an is
On Wed, May 18, 2011 at 5:41 AM, Hyrum K Wright wrote:
> On Wed, May 18, 2011 at 9:32 AM, Bert Huijben wrote:
>> It would completely break mergetracking for about a dozen reasons :(
>>
>> I'll answer more detailed later, but this would just remove the
>> property everywhere.
>>
>> And if you coul
C. Michael Pilato wrote:
> On 05/18/2011 02:02 PM, C. Michael Pilato wrote:
> > On 05/18/2011 01:34 PM, C. Michael Pilato wrote:
> >> You mentioned not being able to provide a patch, but would you be
> >> willing/able to at least file an issue for this in our tracker?
> >
> > Actually, I'm messing
danie...@apache.org wrote on Wed, May 18, 2011 at 13:22:30 -:
> Author: danielsh
> Date: Wed May 18 13:22:29 2011
> New Revision: 1124254
>
> URL: http://svn.apache.org/viewvc?rev=1124254&view=rev
> Log:
> cache_inprocess.c =~ s/assert/SVN_ERR_ASSERT/
>
> * subversion/libsvn_subr/cache-inproc
On Wed, May 18, 2011 at 8:52 AM, Greg Stein wrote:
>> We are not the only software project in the world working on hard
>> problems or that finds it difficult to provide estimates. It sucks,
>> but part of being a professional is doing the best you can.
>
> Do you think that you can plan around
On 18.05.2011 12:42, Daniel Shahaf wrote:
[[[
svn_fs_fs__dag_deserialize(const char *data)
{
dag_node_t *node = (dag_node_t *)data;
svn_fs_fs__id_deserialize(node,
(svn_fs_id_t **)&node->fresh_root_predecessor_id);
}
]]]
Here, the 'fresh_root_predecessor_id' me
On Wed, May 18, 2011 at 15:20, Daniel Shahaf wrote:
> Milestone? 1.7.0? 1.7.0-consider?
>
Hi,
It's definitely 1.7.0. Thanks for pointing on that.
--
Ivan Zhakov
I'm posting this here so Daniel can carry on with it and others can
comment.
Daniel and I were just looking at some caching functions and trying to
reduce the use of 'void *', 'void **' and casts, and we came up with
this patch for svn_temp_deserializer__resolve(). Before it could be
committed it
Milestone? 1.7.0? 1.7.0-consider?
zha...@tigris.org wrote on Wed, May 18, 2011 at 05:04:08 -0700:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3888
> Issue #|3888
> Summary|ra_serf unbound memory usage on
> checkout/export/update
>Compo
Hi All,
I have attached a test case for Issue 3867
(http://subversion.tigris.org/issues/show_bug.cgi?id=3867)
Issue Summary:
reintegrate merges create mergeinfo for non-existent paths
Regards,
Arwin Arni
Index: subversion/tests/cmdline/merge_reintegrate_tests.py
=
Mark Phippard wrote on Wed, May 18, 2011 at 07:43:12 -0400:
> Give the community a date. If it doesn't look like you can hit the
> date, then update the community with the new date and move on. It
> seems like the shame in possibly missing a date is being given too
> much weight. The community s
On Wed, May 18, 2011 at 07:43, Mark Phippard wrote:
> On Wed, May 18, 2011 at 7:25 AM, Greg Stein wrote:
>
>> If solving these were easy, then I believe they would have been done
>> by now. We're down to the hard issues, and people don't have a high
>> degree of confidence in planning when they w
On 05/17/2011 07:14 AM, Mark Eichin wrote:
> Great, thanks (in a fixing-broken-windows sense; svnrdump itself is
> still unusable-or-unsafe without sane revision number handling.)
I've filed http://subversion.tigris.org/issues/show_bug.cgi?id=3890 to track
this.
--
C. Michael Pilato
CollabNet
On 05/18/2011 02:02 PM, C. Michael Pilato wrote:
> On 05/18/2011 01:34 PM, C. Michael Pilato wrote:
>> You mentioned not being able to provide a patch, but would you be
>> willing/able to at least file an issue for this in our tracker?
>
> Actually, I'm messing around in the tracker at the moment.
On 05/18/2011 01:34 PM, C. Michael Pilato wrote:
> On 05/18/2011 01:23 PM, Konstantin Kolinko wrote:
>> My specific use case is doing a text search in some file manager [1] on
>> MS Windows. There I can specify mask and exclude mask for file name,
>> but cannot specify masks for the file path.
>>
On Tue, May 10, 2011 at 11:38 PM, Hyrum K Wright wrote:
> On Mon, May 9, 2011 at 1:01 PM, Hyrum K Wright wrote:
>> On Thu, May 5, 2011 at 9:37 AM, Hyrum K Wright wrote:
>>> On Mon, May 2, 2011 at 3:38 PM, Hyrum K Wright
>>> wrote:
Hi all,
There have a been a couple of user-reque
On 05/18/2011 12:44 PM, Hyrum K Wright wrote:
> On Wed, May 18, 2011 at 11:17 AM, C. Michael Pilato
> wrote:
>> On 05/18/2011 09:53 AM, Bert Huijben wrote:
>>> One obvious case is that libsvn_client sometimes suggests that you
>>> should do a 'svn something', which is only possible if you use svn
On Wed, May 18, 2011 at 7:25 AM, Greg Stein wrote:
> If solving these were easy, then I believe they would have been done
> by now. We're down to the hard issues, and people don't have a high
> degree of confidence in planning when they would be done.
We are not the only software project in the
On 05/18/2011 01:23 PM, Konstantin Kolinko wrote:
> My specific use case is doing a text search in some file manager [1] on
> MS Windows. There I can specify mask and exclude mask for file name,
> but cannot specify masks for the file path.
>
> Several workarounds are possible here, but I think t
On Wed, May 18, 2011 at 07:16, Mark Phippard wrote:
> On Wed, May 18, 2011 at 6:17 AM, Hyrum K Wright wrote:
>> Fire up your testing environments: they're going to get some use over
>> the next couple of months.
>>
>> In an effort to release early and often, I'd like to cut the first
>> 1.7.0 pre
2011/5/18 Hyrum K Wright :
> On Wed, May 18, 2011 at 12:35 PM, Konstantin Kolinko
> wrote:
>> Hi, all!
>>
>> Right now the files in the pristine storage of 1.7 wc are named just
>> by their checksums, e.g.
>>
>> .svn/pristine/00/00014966dd2c75cedf7fc9989accf25e54685e58
>>
>> I think it would be be
On Wed, May 18, 2011 at 6:17 AM, Hyrum K Wright wrote:
> Fire up your testing environments: they're going to get some use over
> the next couple of months.
>
> In an effort to release early and often, I'd like to cut the first
> 1.7.0 pre-release on June 1. This will likely be a beta release,
> s
On Wed, May 18, 2011 at 06:54, Hyrum K Wright wrote:
> On Wed, May 18, 2011 at 12:35 PM, Konstantin Kolinko
> wrote:
>> Hi, all!
>>
>> Right now the files in the pristine storage of 1.7 wc are named just
>> by their checksums, e.g.
>>
>> .svn/pristine/00/00014966dd2c75cedf7fc9989accf25e54685e58
>
On Wed, May 18, 2011 at 12:35 PM, Konstantin Kolinko
wrote:
> Hi, all!
>
> Right now the files in the pristine storage of 1.7 wc are named just
> by their checksums, e.g.
>
> .svn/pristine/00/00014966dd2c75cedf7fc9989accf25e54685e58
>
> I think it would be better to add ".svn-base" suffix to those
+1
Konstantin Kolinko wrote on Wed, May 18, 2011 at 14:35:29 +0400:
> Hi, all!
>
> Right now the files in the pristine storage of 1.7 wc are named just
> by their checksums, e.g.
>
> .svn/pristine/00/00014966dd2c75cedf7fc9989accf25e54685e58
>
> I think it would be better to add ".svn-base" suff
Stefan Sperling wrote on Wed, May 18, 2011 at 12:29:41 +0200:
> On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > > There doesn't seem to be a duplicated block. The revision file itself
> > > seems
> > > to be fine, expect that one of the lengths of the bad rev doesn't seem to
> >
On Wed, May 18, 2011 at 11:17 AM, C. Michael Pilato wrote:
> On 05/18/2011 09:53 AM, Bert Huijben wrote:
>> One obvious case is that libsvn_client sometimes suggests that you
>> should do a 'svn something', which is only possible if you use svn.
>
> libsvn_client should *never* give suggestions th
[[[
svn_fs_fs__dag_deserialize(const char *data)
{
dag_node_t *node = (dag_node_t *)data;
svn_fs_fs__id_deserialize(node,
(svn_fs_id_t **)&node->fresh_root_predecessor_id);
}
]]]
Here, the 'fresh_root_predecessor_id' member of '*node' is somewhere
within *data, and
Hi, all!
Right now the files in the pristine storage of 1.7 wc are named just
by their checksums, e.g.
.svn/pristine/00/00014966dd2c75cedf7fc9989accf25e54685e58
I think it would be better to add ".svn-base" suffix to those names,
so the above becomes
.svn/pristine/00/00014966dd2c75cedf7fc9989ac
On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > There doesn't seem to be a duplicated block. The revision file itself seems
> > to be fine, expect that one of the lengths of the bad rev doesn't seem to
>
> Huh? Are you referring to the two 'length' attributes in the text: and
>
On Wed, May 18, 2011 at 12:17:18PM +0200, Hyrum K Wright wrote:
> Fire up your testing environments: they're going to get some use over
> the next couple of months.
>
> In an effort to release early and often, I'd like to cut the first
> 1.7.0 pre-release on June 1. This will likely be a beta rel
Stefan Sperling wrote on Wed, May 18, 2011 at 12:12:48 +0200:
> On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> > What came out of this thread? Is this one of the known corruption kinds?
>
> It doesn't seem to be known.
> It could be a flipped bits on the hard drive for all we kn
Fire up your testing environments: they're going to get some use over
the next couple of months.
In an effort to release early and often, I'd like to cut the first
1.7.0 pre-release on June 1. This will likely be a beta release,
since there are still blocking issues, but I hope to get this into t
I found the docstring of the deserializer function types unclear as to
the use of @a POOL...
So, the following patch attempts to clarify the role of pools in that
interface:
[[[
Index: subversion/include/private/svn_cache.h
===
--- s
On Wed, May 18, 2011 at 11:27:27AM +0200, C. Michael Pilato wrote:
> Overall, I think the tone of this discussion is deplorable. There's no need
> to be rattling off threats of dropped commit privileges, etc.
+1
On 05/17/2011 05:35 PM, C. Michael Pilato wrote:
> Just came across this while trying to get some work done.
[...]
> svn: E155005: No write-lock in '/home/cmpilato/tests/revert-lock-failure-wc'
I filed http://subversion.tigris.org/issues/show_bug.cgi?id=3886 to track this.
--
C. Michael Pilato
On Wed, May 18, 2011 at 9:32 AM, Bert Huijben wrote:
> It would completely break mergetracking for about a dozen reasons :(
>
> I'll answer more detailed later, but this would just remove the
> property everywhere.
>
> And if you could hide it in a better way while still storing it in the
> wc, yo
On Wed, May 18, 2011 at 11:20 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: woensdag 18 mei 2011 11:16
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org; Hyrum K Wright
>> Subject: Re: svn commit: r1104610 - in
>> /subversion/tr
Greg Stein wrote on Wed, May 18, 2011 at 05:27:19 -0400:
> On Wed, May 18, 2011 at 05:20, Bert Huijben wrote:
> >...
> > And because Hyrum is our release manager, or maybe because he pays you some
> > checks, you threat him differently?
>
> Now you're totally out of line.
>
You're all in the sa
Bert Huijben wrote on Wed, May 18, 2011 at 11:27:06 +0200:
>
>
> > -Original Message-
> > From: C. Michael Pilato [mailto:cmpil...@collab.net]
> > Sent: woensdag 18 mei 2011 11:17
> > To: Bert Huijben
> > Cc: Daniel Shahaf; dev@subversion.apache.org
> > Subject: Re: enhancements for error
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: woensdag 18 mei 2011 11:17
> To: Bert Huijben
> Cc: Daniel Shahaf; dev@subversion.apache.org
> Subject: Re: enhancements for error reporting
>
> On 05/18/2011 09:53 AM, Bert Huijben wrote:
> > One obvious
On 05/18/2011 11:20 AM, Bert Huijben wrote:
> If I would have committed a change with similar breakage you would have
> shouted at me.
> And because Hyrum is our release manager, or maybe because he pays you some
> checks, you threat him differently?
Bert, this is foul play, and I don't mind sayin
On Wed, May 18, 2011 at 05:20, Bert Huijben wrote:
>...
> And because Hyrum is our release manager, or maybe because he pays you some
> checks, you threat him differently?
Now you're totally out of line.
-g
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: woensdag 18 mei 2011 11:16
> To: Bert Huijben
> Cc: dev@subversion.apache.org; Hyrum K Wright
> Subject: Re: svn commit: r1104610 - in
> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>
> On Wed, M
On Wed, May 18, 2011 at 11:13 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 11:11
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org; comm...@subversion.apache.org
>> Subject: Re: svn commit: r110461
On 05/18/2011 09:53 AM, Bert Huijben wrote:
> One obvious case is that libsvn_client sometimes suggests that you
> should do a 'svn something', which is only possible if you use svn.
libsvn_client should *never* give suggestions that refer to any particular
client binary's usage semantics! If suc
On Wed, May 18, 2011 at 05:11, Bert Huijben wrote:
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: woensdag 18 mei 2011 11:07
>> To: dev@subversion.apache.org
>> Cc: Hyrum K Wright
>> Subject: RE: svn commit: r1104610 - in
>> /subversion/trunk/subversion/libsvn
> -Original Message-
> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
> Sent: woensdag 18 mei 2011 11:11
> To: Bert Huijben
> Cc: dev@subversion.apache.org; comm...@subversion.apache.org
> Subject: Re: svn commit: r1104610 - in
> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: woensdag 18 mei 2011 11:07
> To: dev@subversion.apache.org
> Cc: Hyrum K Wright
> Subject: RE: svn commit: r1104610 - in
> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>
> No, we said if somebody
On Wed, May 18, 2011 at 1:48 AM, Bert Huijben wrote:
>> -Original Message-
>> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 1:11
>> To: dev@subversion.apache.org
>> Cc: comm...@subversion.apache.org
>> Subject: Re: svn commit: r1104610 - in
>> /subversio
No, we said if somebody breaks the build, then it can be reverted.
Breaking the tests does not qualify. You were out of line. I just got
telling off people in Lucene-land for this. I also said that if it were up
to me, I would warn somebody about the anti social behavior once, and remove
their com
Please don't mix whitespace changes with functional changes.
I'm attaching a version of the patch re-generated with -x-pw.
[[[
Index: subversion/libsvn_diff/diff.c
===
--- subversion/libsvn_diff/diff.c (revision 1104340)
+++ su
On Wed, May 18, 2011 at 8:33 AM, Johan Corveleyn wrote:
> On Wed, May 18, 2011 at 1:56 AM, Morten Kloster wrote:
>> Log message:
>>
>> Speed-up of libsvn_diff using token counts
>> By using indices, not node pointers, to refer to tokens, and counting
>> the number of each token, the longest commo
Bert Huijben wrote on Wed, May 18, 2011 at 00:53:48 -0700:
> One obvious case is that libsvn_client sometimes suggests that you
> should do a 'svn something', which is only possible if you use svn.
>
I can't find any of these; you might have meant libsvn_wc?
subversion/libsvn_client% grep \'svn
One obvious case is that libsvn_client sometimes suggests that you
should do a 'svn something', which is only possible if you use svn.
+1 on better + documented error codes in similar cases, to fix this.
Bert Huijben (Cell phone) From: Daniel Shahaf
Sent: woensdag 18 mei 2011 9:40
To: dev@subvers
I don't understand why we would need to change the libraries when the
cmdline client can already figure out --- using the same libraries ---
what advice to print.
Stefan Küng wrote on Wed, May 18, 2011 at 07:32:09 +0200:
> On Tue, May 17, 2011 at 22:55, C. Michael Pilato wrote:
> > On 05/17/2011
It would completely break mergetracking for about a dozen reasons :(
I'll answer more detailed later, but this would just remove the
property everywhere.
And if you could hide it in a better way while still storing it in the
wc, you would always forget to commit your mergeinfo only changes.
Bert
93 matches
Mail list logo
