You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2005/10/23 14:04:54 UTC
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
On 10/23/05, zhakov@tigris.org <zh...@tigris.org> wrote:
> Author: zhakov
> Date: Sun Oct 23 08:28:56 2005
> New Revision: 16940
>
> Added:
> branches/wc-propcaching/TODO
> - copied unchanged from r15510, /branches/wc-propcaching/TODO
> Modified:
> branches/wc-propcaching/subversion/libsvn_wc/lock.c
> branches/wc-propcaching/subversion/libsvn_wc/wc.h
>
> Log:
> Merge r15503-15510 (all changes) from the old branch.
>
> Modified: branches/wc-propcaching/subversion/libsvn_wc/lock.c
> Url: http://svn.collab.net/viewcvs/svn/branches/wc-propcaching/subversion/libsvn_wc/lock.c?rev=16940&p1=branches/wc-propcaching/subversion/libsvn_wc/lock.c&p2=branches/wc-propcaching/subversion/libsvn_wc/lock.c&r1=16939&r2=16940
> ==============================================================================
> --- branches/wc-propcaching/subversion/libsvn_wc/lock.c (original)
> +++ branches/wc-propcaching/subversion/libsvn_wc/lock.c Sun Oct 23 08:28:56 2005
> @@ -106,6 +106,11 @@
> adm_access->path,
> pool));
>
> + /* ### TODO: upgrade from format 5 to format 6. */
> + /* ### Upgrading currently disabled. */
> +
> + return SVN_NO_ERROR;
> +
> /* We can upgrade all formats that are accepted by
> svn_wc__check_format. */
> if (adm_access->wc_format != SVN_WC__VERSION)
>
> Modified: branches/wc-propcaching/subversion/libsvn_wc/wc.h
> Url: http://svn.collab.net/viewcvs/svn/branches/wc-propcaching/subversion/libsvn_wc/wc.h?rev=16940&p1=branches/wc-propcaching/subversion/libsvn_wc/wc.h&p2=branches/wc-propcaching/subversion/libsvn_wc/wc.h&r1=16939&r2=16940
> ==============================================================================
> --- branches/wc-propcaching/subversion/libsvn_wc/wc.h (original)
> +++ branches/wc-propcaching/subversion/libsvn_wc/wc.h Sun Oct 23 08:28:56 2005
> @@ -60,10 +60,15 @@
> * The change from 4 to 5 was the addition of support for replacing files
> * with history.
> *
> + * The change from 5 to 6 was the introduction of caching of property
> + * modification state and certain properties in the entries file.
> + *
> * Please document any further format changes here.
> */
> -#define SVN_WC__VERSION 5
> +#define SVN_WC__VERSION 6
trunk has already been bumped wrt 1.3.x; another bump is not required
iff you merge the branch back before 1.4.
bye,
Erik.
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/24/05, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> 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?
Kind of depends on the design? (which we don't have atm)
> 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.
Ok, ok, you're right.
> The WC format number is not very vissible and they are cheap.
You're right there too.
> 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
> trouble.
Let's see what problems it creates if we don't when we're ready to
merge back and discuss then. Agreed?
bye,
Erik.
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
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
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by Erik Huelsmann <eh...@gmail.com>.
> > 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.
> >Erik, I have same question. Also what is extra pay incrementing WC
> >format by two between releases?
Not much. It may look weird though. We don't introduce and deprecate
functions in our public api between 1.x and 1.(x+1) though, so, I'd
say there is no precedent for doing it. Especially since we need to
have fallback anyway, I see no reason to do the double increment.
> 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.
bye,
Erik.
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 23 Oct 2005, Ivan Zhakov wrote:
> On 10/23/05, David James <ja...@gmail.com> wrote:
> On 10/23/05, Erik Huelsmann <eh...@gmail.com> wrote:
> > On 10/23/05, zhakov@tigris.org <zh...@tigris.org> wrote:
> > > Author: zhakov
> > > Date: Sun Oct 23 08:28:56 2005
> > > New Revision: 16940
> > >
> > > Added:
> > > branches/wc-propcaching/TODO
> > > - copied unchanged from r15510, /branches/wc-propcaching/TODO
> > > Modified:
> > > branches/wc-propcaching/subversion/libsvn_wc/lock.c
> > > branches/wc-propcaching/subversion/libsvn_wc/wc.h
> > >
> > > Log:
> > > Merge r15503-15510 (all changes) from the old branch.
> > >
==============================================================================
> > > --- branches/wc-propcaching/subversion/libsvn_wc/wc.h (original)
> > > +++ branches/wc-propcaching/subversion/libsvn_wc/wc.h Sun Oct 23 08:28:56 2005
> > > @@ -60,10 +60,15 @@
> > > * The change from 4 to 5 was the addition of support for replacing files
> > > * with history.
> > > *
> > > + * The change from 5 to 6 was the introduction of caching of property
> > > + * modification state and certain properties in the entries file.
> > > + *
> > > * Please document any further format changes here.
> > > */
> > > -#define SVN_WC__VERSION 5
> > > +#define SVN_WC__VERSION 6
> > trunk has already been bumped wrt 1.3.x; another bump is not required
> > iff you merge the branch back before 1.4.
> 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?
>Erik, I have same question. Also what is extra pay incrementing WC
>format by two between releases?
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.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by Ivan Zhakov <ch...@gmail.com>.
On 10/23/05, David James <ja...@gmail.com> wrote:
> On 10/23/05, Erik Huelsmann <eh...@gmail.com> wrote:
> > On 10/23/05, zhakov@tigris.org <zh...@tigris.org> wrote:
> > > Author: zhakov
> > > Date: Sun Oct 23 08:28:56 2005
> > > New Revision: 16940
> > >
> > > Added:
> > > branches/wc-propcaching/TODO
> > > - copied unchanged from r15510, /branches/wc-propcaching/TODO
> > > Modified:
> > > branches/wc-propcaching/subversion/libsvn_wc/lock.c
> > > branches/wc-propcaching/subversion/libsvn_wc/wc.h
> > >
> > > Log:
> > > Merge r15503-15510 (all changes) from the old branch.
> > >
==============================================================================
> > > --- branches/wc-propcaching/subversion/libsvn_wc/wc.h (original)
> > > +++ branches/wc-propcaching/subversion/libsvn_wc/wc.h Sun Oct 23 08:28:56 2005
> > > @@ -60,10 +60,15 @@
> > > * The change from 4 to 5 was the addition of support for replacing files
> > > * with history.
> > > *
> > > + * The change from 5 to 6 was the introduction of caching of property
> > > + * modification state and certain properties in the entries file.
> > > + *
> > > * Please document any further format changes here.
> > > */
> > > -#define SVN_WC__VERSION 5
> > > +#define SVN_WC__VERSION 6
> > trunk has already been bumped wrt 1.3.x; another bump is not required
> > iff you merge the branch back before 1.4.
> 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?
Erik, I have same question. Also what is extra pay incrementing WC
format by two between releases?
--
Ivan Zhakov
Re: svn commit: r16940 - in branches/wc-propcaching: subversion/libsvn_wc
Posted by David James <ja...@gmail.com>.
On 10/23/05, Erik Huelsmann <eh...@gmail.com> wrote:
> On 10/23/05, zhakov@tigris.org <zh...@tigris.org> wrote:
> > Author: zhakov
> > Date: Sun Oct 23 08:28:56 2005
> > New Revision: 16940
> >
> > Added:
> > branches/wc-propcaching/TODO
> > - copied unchanged from r15510, /branches/wc-propcaching/TODO
> > Modified:
> > branches/wc-propcaching/subversion/libsvn_wc/lock.c
> > branches/wc-propcaching/subversion/libsvn_wc/wc.h
> >
> > Log:
> > Merge r15503-15510 (all changes) from the old branch.
> >
> > Modified: branches/wc-propcaching/subversion/libsvn_wc/lock.c
> > Url: http://svn.collab.net/viewcvs/svn/branches/wc-propcaching/subversion/libsvn_wc/lock.c?rev=16940&p1=branches/wc-propcaching/subversion/libsvn_wc/lock.c&p2=branches/wc-propcaching/subversion/libsvn_wc/lock.c&r1=16939&r2=16940
> > ==============================================================================
> > --- branches/wc-propcaching/subversion/libsvn_wc/lock.c (original)
> > +++ branches/wc-propcaching/subversion/libsvn_wc/lock.c Sun Oct 23 08:28:56 2005
> > @@ -106,6 +106,11 @@
> > adm_access->path,
> > pool));
> >
> > + /* ### TODO: upgrade from format 5 to format 6. */
> > + /* ### Upgrading currently disabled. */
> > +
> > + return SVN_NO_ERROR;
> > +
> > /* We can upgrade all formats that are accepted by
> > svn_wc__check_format. */
> > if (adm_access->wc_format != SVN_WC__VERSION)
> >
> > Modified: branches/wc-propcaching/subversion/libsvn_wc/wc.h
> > Url: http://svn.collab.net/viewcvs/svn/branches/wc-propcaching/subversion/libsvn_wc/wc.h?rev=16940&p1=branches/wc-propcaching/subversion/libsvn_wc/wc.h&p2=branches/wc-propcaching/subversion/libsvn_wc/wc.h&r1=16939&r2=16940
> > ==============================================================================
> > --- branches/wc-propcaching/subversion/libsvn_wc/wc.h (original)
> > +++ branches/wc-propcaching/subversion/libsvn_wc/wc.h Sun Oct 23 08:28:56 2005
> > @@ -60,10 +60,15 @@
> > * The change from 4 to 5 was the addition of support for replacing files
> > * with history.
> > *
> > + * The change from 5 to 6 was the introduction of caching of property
> > + * modification state and certain properties in the entries file.
> > + *
> > * Please document any further format changes here.
> > */
> > -#define SVN_WC__VERSION 5
> > +#define SVN_WC__VERSION 6
> trunk has already been bumped wrt 1.3.x; another bump is not required
> iff you merge the branch back before 1.4.
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?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james