You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2010/08/20 16:31:27 UTC

svn commit: r987526 - /subversion/trunk/subversion/libsvn_wc/upgrade.c

Author: julianfoad
Date: Fri Aug 20 14:31:27 2010
New Revision: 987526

URL: http://svn.apache.org/viewvc?rev=987526&view=rev
Log:
* subversion/libsvn_wc/upgrade.c
  (svn_wc__upgrade_sdb): Tweak a comment.

Modified:
    subversion/trunk/subversion/libsvn_wc/upgrade.c

Modified: subversion/trunk/subversion/libsvn_wc/upgrade.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/upgrade.c?rev=987526&r1=987525&r2=987526&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_wc/upgrade.c (original)
+++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27 2010
@@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
         /* ### TODO: Either upgrade to single-DB format here, or quit
          * at format 18 and ask the user to run the external script
          * 'tools/dev/wc-ng/bump-to-19.py'. */
-        break;
-
-        /* FALLTHROUGH  */
+        break; /* not FALLTHROUGH  */
 #endif
 
       /* ### future bumps go here.  */



Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Greg Stein <gs...@gmail.com>.
On Sun, Aug 22, 2010 at 17:23, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Sun, Aug 22, 2010 at 11:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Greg Stein wrote on Fri, Aug 20, 2010 at 14:11:21 -0400:
>>> I wish you wouldn't change the subject line so often.
>>
>> Why not?  It has proper References: and In-Reply-To:.  Should be enough
>> for threading to work, no?
>
> Not with Gmail - changes in subjects are treated as a new
> conversation.  -- justin

Yup. And empirical evidence shows that it is not enough. Both Bert and
I responded to the original thread before noting this "new thread" was
related in some way.

Cheers,
-g

Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Justin Erenkrantz wrote on Sun, Aug 22, 2010 at 14:23:15 -0700:
> On Sun, Aug 22, 2010 at 11:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Fri, Aug 20, 2010 at 14:11:21 -0400:
> >> I wish you wouldn't change the subject line so often.
> >
> > Why not?  It has proper References: and In-Reply-To:.  Should be enough
> > for threading to work, no?
> 
> Not with Gmail - changes in subjects are treated as a new
> conversation.  -- justin

<snip/>

Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Justin Erenkrantz wrote on Sun, Aug 22, 2010 at 14:23:15 -0700:
> On Sun, Aug 22, 2010 at 11:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Fri, Aug 20, 2010 at 14:11:21 -0400:
> >> I wish you wouldn't change the subject line so often.
> >
> > Why not?  It has proper References: and In-Reply-To:.  Should be enough
> > for threading to work, no?
> 
> Not with Gmail - changes in subjects are treated as a new
> conversation.  -- justin

<snip/>

Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Aug 22, 2010 at 11:14 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Fri, Aug 20, 2010 at 14:11:21 -0400:
>> I wish you wouldn't change the subject line so often.
>
> Why not?  It has proper References: and In-Reply-To:.  Should be enough
> for threading to work, no?

Not with Gmail - changes in subjects are treated as a new
conversation.  -- justin

Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Fri, Aug 20, 2010 at 14:11:21 -0400:
> I wish you wouldn't change the subject line so often.

Why not?  It has proper References: and In-Reply-To:.  Should be enough
for threading to work, no?

Re: Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Greg Stein <gs...@gmail.com>.
I wish you wouldn't change the subject line so often. Bert and I
responded to the original email.

On Fri, Aug 20, 2010 at 13:45, Julian Foad <ju...@wandisco.com> wrote:
> On Fri, 2010-08-20, Greg Stein wrote:
>> On Fri, Aug 20, 2010 at 10:31,  <ju...@apache.org> wrote:
>> > +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27 2010
>> > @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
>> >         /* ### TODO: Either upgrade to single-DB format here, or quit
>> >          * at format 18 and ask the user to run the external script
>> >          * 'tools/dev/wc-ng/bump-to-19.py'. */
>>
>> When you first checked in the script, I assumed you were doing that
>> for rapid dev/test. There is no way that I would ever support an
>> external script to perform this upgrade.
>
> Wasn't sure yet how it's going to work out.  The script is to get us
> going while we figure out how to do the 'proper' 1.6-to-1.7 upgrade.  Of
> course that won't require an external script.  This script is just for
> us devs to upgrade our format-18 WCs to format-19.
>
> It sounds like you are saying this incremental step must be implemented
> in line.  Is that because the sequence of incremental steps as
> implemented in svn_wc__upgrade_sdb() needs to be the same sequence that
> is used by the final 1.6-to-1.7 upgrade?
>
> I was thinking we might want to implement the final 1.6-to-1.7 upgrade
> as a direct migration from scattered entries files into a single DB.
> That would be potentially be considerably faster and less susceptible to
> losing information along the way due to the complexities of multiple
> intermediate states.  (Such as what we can't represent accurately until
> NODE_DATA, for example.)  If the DB access functions can be made
> sufficiently agnostic of DB location, that should be possible.
>
> On the other hand, there may be reasons of complexity why we should not
> attempt to write a bypass, and there may be reasons of testability.  I'm
> not sure about that.  If so, then of course we'll implement this step as
> an in-line auto-upgrade step and expect it to be called as part of the
> final 1.6-to-1.7 upgrade sequence.
>
> What are your thoughts?
>
> - Julian
>
>
>
>

Upgrade from 1.6 must use the same incremental steps? [was: svn commit: r987526 - ...]

Posted by Julian Foad <ju...@wandisco.com>.
On Fri, 2010-08-20, Greg Stein wrote: 
> On Fri, Aug 20, 2010 at 10:31,  <ju...@apache.org> wrote:
> > +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27 2010
> > @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
> >         /* ### TODO: Either upgrade to single-DB format here, or quit
> >          * at format 18 and ask the user to run the external script
> >          * 'tools/dev/wc-ng/bump-to-19.py'. */
> 
> When you first checked in the script, I assumed you were doing that
> for rapid dev/test. There is no way that I would ever support an
> external script to perform this upgrade.

Wasn't sure yet how it's going to work out.  The script is to get us
going while we figure out how to do the 'proper' 1.6-to-1.7 upgrade.  Of
course that won't require an external script.  This script is just for
us devs to upgrade our format-18 WCs to format-19.

It sounds like you are saying this incremental step must be implemented
in line.  Is that because the sequence of incremental steps as
implemented in svn_wc__upgrade_sdb() needs to be the same sequence that
is used by the final 1.6-to-1.7 upgrade?

I was thinking we might want to implement the final 1.6-to-1.7 upgrade
as a direct migration from scattered entries files into a single DB.
That would be potentially be considerably faster and less susceptible to
losing information along the way due to the complexities of multiple
intermediate states.  (Such as what we can't represent accurately until
NODE_DATA, for example.)  If the DB access functions can be made
sufficiently agnostic of DB location, that should be possible.

On the other hand, there may be reasons of complexity why we should not
attempt to write a bypass, and there may be reasons of testability.  I'm
not sure about that.  If so, then of course we'll implement this step as
an in-line auto-upgrade step and expect it to be called as part of the
final 1.6-to-1.7 upgrade sequence.

What are your thoughts?

- Julian



Re: svn commit: r987526 - /subversion/trunk/subversion/libsvn_wc/upgrade.c

Posted by Greg Stein <gs...@gmail.com>.
On Fri, Aug 20, 2010 at 14:01, Bert Huijben <be...@vmoo.com> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: vrijdag 20 augustus 2010 9:55
>> To: dev@subversion.apache.org
>> Subject: Re: svn commit: r987526 -
>> /subversion/trunk/subversion/libsvn_wc/upgrade.c
>>
>> On Fri, Aug 20, 2010 at 10:31,  <ju...@apache.org> wrote:
>> >...
>> > +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27
>> 2010
>> > @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
>> >         /* ### TODO: Either upgrade to single-DB format here, or quit
>> >          * at format 18 and ask the user to run the external script
>> >          * 'tools/dev/wc-ng/bump-to-19.py'. */
>>
>> When you first checked in the script, I assumed you were doing that
>> for rapid dev/test. There is no way that I would ever support an
>> external script to perform this upgrade.
>
> I wouldn't have an issue with using a python script this if it is only used
> for upgrades from formats 12 to 18 to single-db. The upgrade from entries
> (read: 1.6.x and below) must be in c of course. But keeping the multi-db
> read code working for all the intermediate multi-db formats might provide
> too much overhead.
>
> We are not going to provide long-time support for these dev only
> intermediate formats anyway.

Agreed.

We're really looking at the upgrade_to_wcng() function in upgrade.c.
The other mid-term upgrades work for us, the developers, and also
establish a pattern for future upgrades.

Cheers,
-g

RE: svn commit: r987526 - /subversion/trunk/subversion/libsvn_wc/upgrade.c

Posted by Bert Huijben <be...@vmoo.com>.

> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: vrijdag 20 augustus 2010 9:55
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r987526 -
> /subversion/trunk/subversion/libsvn_wc/upgrade.c
> 
> On Fri, Aug 20, 2010 at 10:31,  <ju...@apache.org> wrote:
> >...
> > +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27
> 2010
> > @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
> >         /* ### TODO: Either upgrade to single-DB format here, or quit
> >          * at format 18 and ask the user to run the external script
> >          * 'tools/dev/wc-ng/bump-to-19.py'. */
> 
> When you first checked in the script, I assumed you were doing that
> for rapid dev/test. There is no way that I would ever support an
> external script to perform this upgrade.

I wouldn't have an issue with using a python script this if it is only used
for upgrades from formats 12 to 18 to single-db. The upgrade from entries
(read: 1.6.x and below) must be in c of course. But keeping the multi-db
read code working for all the intermediate multi-db formats might provide
too much overhead.

We are not going to provide long-time support for these dev only
intermediate formats anyway.

	Bert

Re: svn commit: r987526 - /subversion/trunk/subversion/libsvn_wc/upgrade.c

Posted by Greg Stein <gs...@gmail.com>.
On Fri, Aug 20, 2010 at 10:31,  <ju...@apache.org> wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/upgrade.c Fri Aug 20 14:31:27 2010
> @@ -1420,9 +1420,7 @@ svn_wc__upgrade_sdb(int *result_format,
>         /* ### TODO: Either upgrade to single-DB format here, or quit
>          * at format 18 and ask the user to run the external script
>          * 'tools/dev/wc-ng/bump-to-19.py'. */

When you first checked in the script, I assumed you were doing that
for rapid dev/test. There is no way that I would ever support an
external script to perform this upgrade.

Cheers,
-g