1.0.1 change candidates

On December 12, 2003, the trunk and 1.0 lines first diverged. It
happened when we created the 0.35 branch (r7994).

Since that time, many things have been ported from trunk to 1.0, but a
number of things have *not* been ported. Many of those things were
not worth the 1.0 risk, but were offhandely categorized as "fine for
1.0.1". Unfortunately, nobody's been keeping track of these 1.0.1
candidates up till now.

So today I read over the log of /trunk from -r7994:HEAD, and with
kfogel's help, *removed* all the revisions that had already been
merged into the 1.0 line. I reviewed what was left, trolling for
1.0.1 candidates, and then nominated some in the 1.0.1 section of the
STATUS file.

It's worth nothing that there were many changes I deliberately did
*not* nominate for 1.0.1. As HACKING describes, I tried to follow
these criteria when nominiating 1.0.1 change candidates:

 - a 1.0.1 change must match our compatibility rules (no API or ABI
   changes in any direction.)

 - the change should fix a non-trivial bug noticeable by users.

 - the change should be very simple and low-risk.

Here are a few examples which did not make the cut:

r8049
 clean up a zillion error leakages.

   --> an awful lot of code churn, and no noticeable bug seen by the
       user. Easy to wait until 1.1 for this.

r8137
 make ra_local save username creds to disk cache.

   --> has anyone ever complained about this?

r8078
 bugfix dir_delta() path-driving behavior

   --> ghudson noticed this when dir_delta drove his own custom
       editor. This might be noticed by people using our 1.0.0 public
       API, not sure. Either way, I wasn't up to the task of
       reviewing his code changes... it's a complex edge-case.

r8551
 make 'svn blame' bail on binary files.

   --> this change adds a new error code, so it's only 1.1 compatible,
       not 1.0.1. I'm going to file an issue to do a port of this
       change to 1.0.1 *without* the new error code.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 5 23:17:40 2004