There is a small amount of concern over the affect of change 16855 on
the wc format.
16855 is the change, currently on trunk, and proposed for 1.3.x, which
stops outputting "END\n" to empty prop files, wasting 4 bytes (which
ends up wasting a disk block per file on most FSen, and multiplying out
for gcc, 250 meg of space per checkout)
To clarify:
16855 is backwards compatible with the clients *we* have produced.
WC's created by something with patch in 16855 are read and written just
fine by prior SVN version.
I tested:
1.2.x against a 1.3.x with 16855 wc
1.3.x without 16855 against a 1.3.x with 16855 wc
1.3.x with 16855 against a 1.2.x wc
The same guarantee is true of anything accessing the WC through our
bindings libraries (IE bindings from 1.2.x accessing the wc do fine
here, as would anything using our hash reading functions through the
bindings, if those are exposed).
The case that it may introduce real incompatibility is with our secret
neighbors, and the not-so-secret JavaSVN.
Our secret neighbors are those people who have chosen, instead of using
our bindings library, or even our on-disk hash reading function, to
write their own code entirely to access the WC properties from first
principles and staring at tons of WC files (i guess).
They are secret because nobody is quite sure if they exist.
In other words, nobody is aware of a project other than JavaSVN that
does this.
Nobody is quite sure whether we should care about them very much,
either, if they didn't emulate what we were doing properly.
The secondary concern is people who have scripts operating in the wc.
Theoretically, this change could affect them, but really only if they
had scripted parsing our hashtables, and were incredibly anal retentive
about seeing "END\n". This seems like it's a very small set of people
or scripts, if any. Unlike regular users, people whose code depends on
whether "END\n" exists in the props file or not probably can
In the interest of full disclosure, this change *will* break JavaSVN,
because they haven't reimplemented entirely what hash_read does.
However, the fix they would need is roughly 2 lines of code, and we
aren't even sure if they are going to need any *other* fixes for stuff
produced by 1.3.x anyway, due to other things they haven't
reimplemented.
Thus, my inclination in response to these concerns is that if and when
this change merges to the 1.3 branch, is to simply put in a large
release note in a developer section, give a heads up at RC time to all
the people we know about who might be affected, and call that that.
I also believe we should fully document the WC format in 1.4, so people
reimplementing it aren't hit by our little implementation niggles.
This probably means moving away from hash_read, which has little niggles
in it (in fact, it's one of those niggles that allows this change to be
backwards compatible), to hash_read2, which is unforgiving.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 21 01:01:52 2005