blob: 06d49af0559c98f9c9b6d7c4e08158a0d7a6111a [file] [log] [blame]
We are getting close to creating the 1.6.x branch. This file lists the tasks
we want to complete before branching. "Blocker" tasks must be done before we
branch, while "optional" tasks would be nice to have completed, but aren't
essential.
Tasks which need to happen before the 1.6.0 release, but aren't related to when
we branch should be put in the issue tracker with the 1.6 milestone.
Blocker:
* Make SHA1 code in FSFS backend conditional on format version. [hwright]
* Fix a bunch of rep-sharing issues in FSFS (or remove the feature):
- Storing only SHA1 checksums and not MD5 for new files almost
certainly leads to less robust updates/commits or performance
penalties; at the very least, we should figure out which one of
those it is doing and make sure we're making the right
decision. I'd recommend just storing both though (or removing
rep-sharing from FSFS). [BDB is now storing both.]
- svn_fs_fs__inc_rep_reuse (unlike svn_fs_fs__set_rep_reference) is
used outside of the control of the FSFS lock. Thus its
read-modify-write can have race conditions, leading to two
different rep key with the same reuse number. Now, I'm not 100%
sure how much of a problem this is; it would be good to document
the point of the reuse number somewhere (unless I'm missing it).
But I think it's to enable our dumb
compare-if-a-node-has-changed-by-if-its-rep-key-has-changed thing
to work, right? And so there could be a subtle,
difficult-to-diagnose problem if two reps end up with the same
reuse number. You could try to do this by wrapping the read and
write inside a transaction (with retry loop), but I don't
remember if SQLite transactions work that way.
A potentially better solution: The point of the reuse column,
AFAICT, is *not* to do a reference count. It's just to uniquify
references to the rep. So switch it from a number to a string,
and qualify the string by the name of the transaction that is
creating the reference. You can stick a counter for the current
transaction in foo.txn/next-ids or something. (Then you still
might have to worry about concurrent writes to the same
transaction, but of course that situation is full of problematic
race conditions in FSFS anyway; fortunately all you have to avoid
those is to avoid mod_dav_svn like the plague.)
- 'structure' has not been updated.
* Tree conflicts - essential issues:
- #3306: "svn resolved" target must be a victim, not a parent.
- Tree conflicts can break working copy as noted by markphip:
http://svn.haxx.se/dev/archive-2008-10/1090.shtml
* Bug: External diff can't find its temp file - regression in trunk since
1.5.4, <http://svn.haxx.se/dev/archive-2008-11/0047.shtml>.
- Fixed in APR, r712674. Workaround still needed in svn for older APRs.
Optional:
* Merge the sparse-directories deselection branch, as noted by kfogel:
http://svn.haxx.se/dev/archive-2008-10/1001.shtml
* Secure certificate passphrase caching on Windows, to bring it upto the
same level as the other password stores. (Issue 2489)
* Tree conflicts - essential issues:
- #3320; Commit not blocked by tree conflict
- #3139, #3209: Tests XFAIL due to changed tree-conflicts behaviour