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