On 10/4/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On Oct 4, 2007 12:00 PM, David Glasser <glasser@davidglasser.net> wrote:
> > * We can't store a non-infinite depth in an entries file of a format
> > that a 1.4 client can write, because that can read to corruption, so
> > *at the very least* any entries file with non-infinite depth *must*
> > have a new format (9).
>
> FWIW, I agree with Jack on this - trying to educate people on
> when/why/how the upgrade happens is a lesson in futility. So +1 for
> bumping across the board whenever a 1.5 client touches the WC.
>
> Though, I wonder if there's another path forward (sadly not available
> for 1.4->1.5): can we tweak libsvn_wc to preserve extra fields that it
> doesn't know and keep them? That is, have libsvn_wc store (somewhere)
> whatever extra lines doesn't recognize at the end of the entry and
> just preserve it? This could help us from getting bit if we add WC
> features later on.
But it might bite us too. I think the fact that we don't retain
unrecognized information is by design: How would a 1.4 client ensure
the information it retains stays consistent with the operations it
performs?
> (Though even if 1.4 *did* preserve the fields for
> sparse directories, I have a feeling it still might break it if a 1.4
> tried to do an update; but I dunno - that's more specific to the
> feature than the WC entries modifications.) But, that gives us a
> potential escape hatch for later fields and future-proofing which an
> older client wouldn't be harmed by...we specifically picked
> line-delimited WC entries so it'd be easy to extend it, but I don't
> think we ever did the bits to ensure we preserved it. -- justin
I need more thought before I can agree preserving the information is a
good idea.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 5 09:10:56 2007