[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r36625 - in branches/1.6.x: . subversion/po subversion/svn

From: Branko Cibej <brane_at_xbc.nu>
Date: Tue, 17 Mar 2009 18:27:49 +0100

Jens,

every rule we have is there for a reason. None were imposed without
discussion and consent of the committers. You agreed to abide by these
rules when you accepted partial-commit access. You are free to propose
different rules, but you are not free to just ignore them when they're
not convenient.

Jens Seidel wrote:
> Hi,
>
> Greg your points are true. I will be more carefully in the future.
> Nevertheless no harm happened.
>
> On Tue, Mar 17, 2009 at 04:28:41PM +0100, Greg Stein wrote:
>
>> On Tue, Mar 17, 2009 at 15:57, Jens Seidel <jensseidel_at_users.sf.net> wrote:
>>
>>> On Tue, Mar 17, 2009 at 03:56:01PM +0100, Greg Stein wrote:
>>>
>>>> You touched a file in svn/main.c on the release branch. That is not
>>>> allowed. Your commit area is limited to subversion/po/ only.
>>>> *ESPECIALLY* when it comes to the *RELEASE BRANCH*.
>>>>
>>>> This is Bad.
>>>>
>>> I'm sorry, but why was the help message not updated before? I reported it
>>>
>> It was updated on trunk, and there is an outstanding VOTE to update it
>> on the branch.
>>
>
> And once someone merges it the person forgets (as usual) to update
> translations resulting in a very large help message which is again
> untranslated.
>
>
>>> All in all it's a minor change but I consider help messages important and it
>>> should not lie.
>>>
>> That is not your call to make. There is a VOTE for it. That is how
>> things work. None of the committers (full or partial) are free to
>> simply make changes in the release branch because they consider
>> something "important".
>>
>
> OK, but you are aware of the fact that many bugs could already be fixed
> in Subversion since years without such (sometimes useless) rules? Just
> ask people to follow common sense should be all rule required.
>
> (I once sent e.g. a trivial patch which removes the dependence on a
> installed svn binary during build or install (don't remember). I'm sure
> it is still not applied. I will not repeat old discussions but you have to
> agree that not everything is optimal with Subversions development model.)
>
>
>> It is a minor change, but not *that* minor. How do I know that the new
>> help output is correct? I can't just eyeball it. I have to set up a
>>
>
> Yep, this is difficult. But I ensured that the old output is wrong by
> searching the source for the old message and this didn't occurred. But I
> found the new string as expected (and as in trunk) in the tree conflict
> code.
>
>
>> tree conflict somehow and then run "svn status" to see what the
>> *actual* output is, and then compare it against what is being put into
>> the help text. Thus, it is not an "obvious fix".
>>
>
> This test happened already in trunk. I'm 100% sure that the old code in
> 1.6.x was wrong, I'm to 95% sure that the new code is OK. I'm to 99% sure
> it's better than the old string.
>
>
>> As it stands, it was scheduled to be fixed in 1.6.1. Not in 1.6.0.
>>
>
> I will not object any further. Do whatever you prefer ...
>
> Jens
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1342404
Received on 2009-03-17 18:28:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.