[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-10-24 21:40:15 CEST

On Mon, 24 Oct 2005, Erik Huelsmann wrote:

> > > If the wc-propcaching branch is merged to trunk without a WC format
> > bump, would working copies created by our current trunk client still
> > work? What would happen?

> They have to: even 1.0 working copies have to keep working, so the
> branch must provide a fallback for information not being available.

Yes, they have to. But, how does the WC lib know that it will need to
upgraade the WC?

Say I have a WC that has been used by our current trunk code. That means
it was bumped right after wc-replacements was merged.

Now, we work on the wc-propcaching branch, which means we will have a
non-trivial upgrade. By that, I mean that we need to rewrite files, not
just bump the format number. When we merge wc-propcaching, and I try to
use my pre-propcaching WC, it needs to be upgraded again. That won't
happen, because the format nubmer wasn't changed. But the WC code will
think we have the new format and assume it... Mess, crap, horror...

> > You've a good point there. My first reaction was the same as Erik's,
> but
> > by bumping in two steps will help our developers that build from
> trunk.

> Ok. Does that mean we will be doing double increments on function
> prototypes too from now? I liked the 'trunk is for developers' regime.

Erik, that's totally unrelated. The WC format number is not very vissible
and they are cheap. We don't always need to bump it for a new change
between releases, but in this case, I think it will save trunk users some
troble.

Thoughts?
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 24 21:41:24 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.