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.
<blair@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
Received on Thu Oct 12 18:55:22 2006