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

Re: svn commit: r21898 - branches/1.4.x

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-10-12 18:55:03 CEST

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.


Blair Zajac, Ph.D.
Subversion training, consulting and support
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

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.