You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2006/10/12 00:53:03 UTC
Re: svn commit: r21898 - branches/1.4.x
dlr@tigris.org wrote:
> Author: dlr
> Date: Wed Oct 11 17:11:57 2006
> New Revision: 21898
>
> Log:
> * STATUS: Nominate r21897, and approve r20992.
>
> Modified:
> branches/1.4.x/STATUS
>
> Modified: branches/1.4.x/STATUS
> URL: http://svn.collab.net/viewvc/svn/branches/1.4.x/STATUS?pathrev=21898&r1=21897&r2=21898
> ==============================================================================
> --- branches/1.4.x/STATUS (original)
> +++ branches/1.4.x/STATUS Wed Oct 11 17:11:57 2006
> @@ -155,6 +155,16 @@
> Votes:
> +1: lgo
>
> + * r21897
> + Add validation of the HEAD argument passed to 'svnmerge.py init'.
> + Justification:
> + This common gotcha otherwise results in an ugly stack trace with
> + no meaningful feedback to the user.
> + Votes:
> + +1: dlr
I'm thinking instead of just merging this change over, why don't we nominate all
the unmerged changes to the svnmerge*py files? There's a number of changes
there and I'd like to see 1.4.1 have all the fixes. Besides, I tried to merge
r21897 into 1.4.x and it didn't merge cleanly.
I don't know if our "no new features" policy for 1.4.x releases applies to
scripts, or even those in contrib/. which are not "officially" supported by us.
The only revision to svnmerge.py that affected other files was r19953, which we
could leave out.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r21898 - branches/1.4.x
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Wed, 11 Oct 2006, Blair Zajac wrote:
> ...
>>> + * r21897
>>> + Add validation of the HEAD argument passed to 'svnmerge.py init'.
>>> + Justification:
>>> + This common gotcha otherwise results in an ugly stack trace with
>>> + no meaningful feedback to the user.
>>> + Votes:
>>> + +1: dlr
>> I'm thinking instead of just merging this change over, why don't we
>> nominate all the unmerged changes to the svnmerge*py files? There's a
>> number of changes there and I'd like to see 1.4.1 have all the fixes.
>> Besides, I tried to merge r21897 into 1.4.x and it didn't merge cleanly.
>
> Sounds like a good idea to me.
>
>> I don't know if our "no new features" policy for 1.4.x releases applies to
>> scripts, or even those in contrib/. which are not "officially" supported by
>> us.
>
> FWIW, I've been unable to find this policy explicitly written up in
> HACKING. In fact, text in hacking suggests that new features are
> permitted in patch releases:
>
> "A patch ... never breaks compatibility ... However, new features
> offered by the release might be unsupported without a corresponding
> upgrade to the other side of the connection."
> - http://subversion.tigris.org/hacking.html#release-numbering
>
> Anyhow, in general I am in favor of not including new features in
> patch releases, but we might want to actually record such a guideline
> at some point as more than oral tradition.
I assumed it was there after our recent -1 on the Neon on Windows discussion.
>> The only revision to svnmerge.py that affected other files was r19953,
>> which we could leave out.
>
> r19953 didn't seem to affect svnmerge.py or its supporting files -- I
> assume you meant a different revnum?
Yes, a typo: r19553. That entire revision does merge cleanly into the 1.4.x
branch, so maybe it wouldn't hurt to merge that one also.
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r21898 - branches/1.4.x
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 11 Oct 2006, Blair Zajac wrote:
...
> >+ * r21897
> >+ Add validation of the HEAD argument passed to 'svnmerge.py init'.
> >+ Justification:
> >+ This common gotcha otherwise results in an ugly stack trace with
> >+ no meaningful feedback to the user.
> >+ Votes:
> >+ +1: dlr
>
> I'm thinking instead of just merging this change over, why don't we
> nominate all the unmerged changes to the svnmerge*py files? There's a
> number of changes there and I'd like to see 1.4.1 have all the fixes.
> Besides, I tried to merge r21897 into 1.4.x and it didn't merge cleanly.
Sounds like a good idea to me.
> I don't know if our "no new features" policy for 1.4.x releases applies to
> scripts, or even those in contrib/. which are not "officially" supported by
> us.
FWIW, I've been unable to find this policy explicitly written up in
HACKING. In fact, text in hacking suggests that new features are
permitted in patch releases:
"A patch ... never breaks compatibility ... However, new features
offered by the release might be unsupported without a corresponding
upgrade to the other side of the connection."
- http://subversion.tigris.org/hacking.html#release-numbering
Anyhow, in general I am in favor of not including new features in
patch releases, but we might want to actually record such a guideline
at some point as more than oral tradition.
svnmerge.py is a place where I think new, well-tested features make a
lot of sense in a patch release. It's code which will eventually be
outdated when a new minor release introduces Merge Tracking in
Subversion's core. (Note: r21898 is not a new feature, but some input
validation code.)
> The only revision to svnmerge.py that affected other files was r19953,
> which we could leave out.
r19953 didn't seem to affect svnmerge.py or its supporting files -- I
assume you meant a different revnum?