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
Received on 2009-03-17 17:02:53 CET