Spin-off from issue #649:
In the course of investigating whether
svn_fs__rep_contents_write_stream() needs to retain the ability to
append to an existing rep (it doesn't), Mike Pilato and I discovered
that svn_fs__get_mutable_rep() copies the contents of its immutable
source rep into the new, mutable rep it creates. The only
circumstance where it doesn't do that is when it's passed NULL for the
source rep -- that is, when creating a new object, as in
svn_fs_make_dir or svn_fs_make_file.
However, if svn_fs__rep_contents_write_stream() is going to lose the
ability to change a rep that already has data, there is no point
creating new mutable reps with data in them already. Because if we
want to change the rep, we'll have to empty it out first (which is
what we're doing everywhere right now), and if we don't want to change
it, why were we making a mutable rep anyway?
There may be one or two edge cases where we make a mutable rep and
then immediately unmutify it; we can always copy over the data by hand
in those cases, though more likely we'll discover that we simply
didn't need to be making a mutable rep there at all.
Meanwhile, getting rid of all those unneeded copies should speed up
libsvn_fs quite a bit. Mike's doing this on the train as I type these
very words :-).
Task
Blocker