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
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."
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
> 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?
Received on Thu Oct 12 17:15:19 2006
- application/pgp-signature attachment: stored