You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2010/06/30 19:12:34 UTC
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
I completely disagree with this.
Didn't I just get done describing the intent here? We allow the
upgrade to continue. If there is an impact on work queue items, then
they must be upgraded, too.
Clients are not expected to back up to previous revisions and run "svn
cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>From then on, we can/should/will perform an upgrade with a non-empty
work queue. Every single auto-upgrade in the past has operated in this
fashion, and we will continue to do so from 1.7 onwards.
Please revert. This is contrary to the design that I explained just yesterday.
-g
On Wed, Jun 30, 2010 at 06:21, <ph...@apache.org> wrote:
> Author: philip
> Date: Wed Jun 30 10:21:31 2010
> New Revision: 959257
>
> URL: http://svn.apache.org/viewvc?rev=959257&view=rev
> Log:
> * subversion/libsvn_wc/wc_db_pdh.c
> (svn_wc__db_pdh_create_wcroot): Don't auto-upgrade if there are
> outstanding workqueue items.
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>
> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c?rev=959257&r1=959256&r2=959257&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c Wed Jun 30 10:21:31 2010
> @@ -299,16 +299,30 @@ svn_wc__db_pdh_create_wcroot(svn_wc__db_
> format);
> }
>
> + /* Verify that no work items exists. If they do, then our integrity is
> + suspect and, thus, we cannot use this database. */
> + if (format >= SVN_WC__HAS_WORK_QUEUE
> + && (enforce_empty_wq || (format < SVN_WC__VERSION && auto_upgrade)))
> + {
> + svn_error_t *err = verify_no_work(sdb);
> + if (err)
> + {
> + /* Special message for attempts to upgrade a 1.7-dev wc with
> + outstanding workqueue items. */
> + if (err->apr_err == SVN_ERR_WC_CLEANUP_REQUIRED
> + && format < SVN_WC__VERSION && auto_upgrade)
> + err = svn_error_quick_wrap(err, _("Cleanup with an older 1.7 "
> + "client before upgrading with "
> + "this client"));
> + return svn_error_return(err);
> + }
> + }
> +
> /* Auto-upgrade the SDB if possible. */
> if (format < SVN_WC__VERSION && auto_upgrade)
> SVN_ERR(svn_wc__upgrade_sdb(&format, wcroot_abspath, sdb, format,
> scratch_pool));
>
> - /* Verify that no work items exists. If they do, then our integrity is
> - suspect and, thus, we cannot use this database. */
> - if (format >= SVN_WC__HAS_WORK_QUEUE && enforce_empty_wq)
> - SVN_ERR(verify_no_work(sdb));
> -
> *wcroot = apr_palloc(result_pool, sizeof(**wcroot));
>
> (*wcroot)->abspath = wcroot_abspath;
>
>
>
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jul 1, 2010 at 11:41, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> Dood. Re-read my email. I said interim wq items do not have to be supported.
>> Only 1.7 [release] items.
>
> So when do we autoupgrade?
>
> 1.7-dev to 1.7-dev
>
> I disabled the autoupgrade with a workqueue as it might
> break. Developers have to run cleanup with an older client. I'm not
> quite sure if you object to this or not.
It would be nice to auto-upgrade, but sure... devs can deal with this
pain. Not worried here.
It would be even nicer to fail only if *certain* items are discovered,
rather than "any" item.
> 1.7-dev to 1.7.x
>
> When 1.7.x is released the problems with old 1.7-dev workqueues still
> exist, so it doesn't seem sensible to suddenly enable autoupgrade
> unconditionally. Developers will probably still have to run cleanup
> with an older client.
Same as above.
> 1.7.x to 1.7.x
>
> The format doesn't change during a release, so we don't have to
> autoupgrade.
Right.
> 1.7-dev to 1.8-dev
>
> The 1.7-dev workqueue problems haven't gone away, and we are still
> dealing with developer working copies.
Right. Same as before. "1.7-dev with wq... would be nice to
auto-upgrade, but failing is okay".
> 1.7.x to 1.8-dev
>
> Here we could autoupgrade if we can exclude problem 1.7-dev
> workqueues. I suppose we could scan the workqueue, or perhaps we could
> bump the format shortly before 1.7.x and autoupgrade from that version
> onwards.
This is the case that I'm concerned about, and tried to clarify in my
earlier email. Once 1.7 is released, then auto-upgrades may need to
inspect/rewrite the workqueue. Hopefully, they can ignore it (much
like we ignored stale "log" files during previous auto-upgrades).
We can do format bumps or rename workqueue OP_* values to separate
-dev from -release items.
Cheers,
-g
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> Dood. Re-read my email. I said interim wq items do not have to be supported.
> Only 1.7 [release] items.
So when do we autoupgrade?
1.7-dev to 1.7-dev
I disabled the autoupgrade with a workqueue as it might
break. Developers have to run cleanup with an older client. I'm not
quite sure if you object to this or not.
1.7-dev to 1.7.x
When 1.7.x is released the problems with old 1.7-dev workqueues still
exist, so it doesn't seem sensible to suddenly enable autoupgrade
unconditionally. Developers will probably still have to run cleanup
with an older client.
1.7.x to 1.7.x
The format doesn't change during a release, so we don't have to
autoupgrade.
1.7-dev to 1.8-dev
The 1.7-dev workqueue problems haven't gone away, and we are still
dealing with developer working copies.
1.7.x to 1.8-dev
Here we could autoupgrade if we can exclude problem 1.7-dev
workqueues. I suppose we could scan the workqueue, or perhaps we could
bump the format shortly before 1.7.x and autoupgrade from that version
onwards.
--
Philip
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Greg Stein <gs...@gmail.com>.
Dood. Re-read my email. I said interim wq items do not have to be supported.
Only 1.7 [release] items.
On Jul 1, 2010 5:08 AM, "Philip Martin" <ph...@wandisco.com> wrote:
Greg Stein <gs...@gmail.com> writes:
> On Wed, Jun 30, 2010 at 13:55, Philip Martin <philip.martin...
I realise that. You seemed to be accusing me of ignoring you, and I
was pointing out that I didn't ignore you it's just that I don't agree
with you. Sorry if it came across the wrong way.
>>> We allow the
>>> upgrade to continue. If there is an impact on work queue items, then
>>> they ...
For devs it's better not to autoupgrade. Then they can revert to the
version that generated the workqueue and use that. If we autoupgrade
they have no usable version.
> BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>
>>> Clients are not exp...
I don't see the difference. At some point you have to write the code
to do it.
> The process that I
> encoded in the db-opening logic was to support THAT purpose.
>
>> not code t...
But your plan is that at release we should be capable of handling that
old workqueue item? This is a workqueue item only ever produced by a
dev version. I'd argue that these pre-1.7 dev workqueues don't need
to be supported long-term. You realise that the XML parser in log.c
would have to be retained, probably including bits that have already
been deleted? And that parser would never be used by people upgrading
from 1.6, since they have to cleanup first.
>> When we upgrade and run the
>> workqueue it will probably fail because the .svn/text-base no lo...
After we release 1.7 it's different. We can choose to autoupgrade, or
we can treat it like 1.6 and say that an upgrade step is required.
It's hard to predict the future. If 1.8 uses a totally different
backend for the wc then while we would support upgrading from a 1.7 wc
we might not support running 1.7 workqueues.
>> That's just one example. I don't know exactly which workqueue items
>> break. SVN_WC__LOG_CP_A...
I'd argue that's unneccesary, it's a maintenance burden we don't need.
Is there a regression test? Does it still work? However it's trivial
compared to supporting an XML parser that's not otherwise required.
> Another approach is to rename the work item in the OP_FOO symbols.
> Stale items become obvious w...
I still disagree. Having made the decision to introduce an upgrade
step for 1.6-to-1.7 we should take full advantage of that. The
intermediate pre-1.7 workqueues do not need to be supported. Then we
can throw out all the log parsing code.
--
Philip
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> On Wed, Jun 30, 2010 at 13:55, Philip Martin <ph...@wandisco.com> wrote:
>> Greg Stein <gs...@gmail.com> writes:
>>
>>> I completely disagree with this.
>>>
>>> Didn't I just get done describing the intent here?
>>
>> You didn't respond to my questions in the last thread.
>
> Gee. I'm sorry. I have a life. I don't have time to respond to
> everything RIGHT NOW. Maybe I needed to think about it? Maybe I'm
> traveling. Maybe I just want to sit back and play Mass Effect 2 for a
> while.
I realise that. You seemed to be accusing me of ignoring you, and I
was pointing out that I didn't ignore you it's just that I don't agree
with you. Sorry if it came across the wrong way.
>>> We allow the
>>> upgrade to continue. If there is an impact on work queue items, then
>>> they must be upgraded, too.
>>
>> We don't generally support running old workqueues with newer code, so
>> why is uprade so different? Take this recent commit:
>>
>> http://svn.apache.org/viewvc?rev=959374&view=rev
>>
>> it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
>> log actions we effectively broke any workqueue that included them.
>> Nobody has written any code to migrate those workqueues.
>
> Yup. And because that would only affect devs, and when the workqueue
> code throws an error saying "dunno what 'delete-lock' means", then
> that dev has an easy way to fix themselves. It is an obvious failure
> mode.
>
> I don't care about breaking devs. The interim formats before 1.7 is
> released can enforce a cleanup first. But even that is a pain. I'd
> rather just see something fail in an obvious way and let the dev fix
> it up.
For devs it's better not to autoupgrade. Then they can revert to the
version that generated the workqueue and use that. If we autoupgrade
they have no usable version.
> BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>
>>> Clients are not expected to back up to previous revisions and run "svn
>>> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>>>From then on, we can/should/will perform an upgrade with a non-empty
>>> work queue. Every single auto-upgrade in the past has operated in this
>>> fashion, and we will continue to do so from 1.7 onwards.
>>>
>>> Please revert. This is contrary to the design that I explained just
>>> yesterday.
>>
>> Why is it so important to support this? It doesn't affect many people
>> but writing the code to upgrade log items is a big effort. And it's
>
> We don't have to upgrade today's workqueue items. We simply have to
> have a policy to upgrade them once 1.7 is released.
I don't see the difference. At some point you have to write the code
to do it.
> The process that I
> encoded in the db-opening logic was to support THAT purpose.
>
>> not code that will get used by anyone other than people running dev
>> code. It will be poorly tested and a maintenance burden. How long do
>> we keep it? How far back in wcng history do we support?
>>
>> Take this workqueue item:
>>
>> 13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
>> dest=".svn/text-base/f.svn-base"
>> name=".svn/svn-ZIxV3z"/>
>> )
>>
>> It will break the working copy on upgrade because the wrong text-base
>> will get copied into the pristine store.
>
> Right. Let it break.
>
> At 1.7 release time, the above style of wq item could be hard to
> upgrade, so we could make it more semantic-based. "install TEMP into
> pristine store as CHECKSUM". That would be much more resilient to
> changes in the working copy format.
But your plan is that at release we should be capable of handling that
old workqueue item? This is a workqueue item only ever produced by a
dev version. I'd argue that these pre-1.7 dev workqueues don't need
to be supported long-term. You realise that the XML parser in log.c
would have to be retained, probably including bits that have already
been deleted? And that parser would never be used by people upgrading
from 1.6, since they have to cleanup first.
>> When we upgrade and run the
>> workqueue it will probably fail because the .svn/text-base no longer
>> exists. How will the user handle that? Isn't it better to get an
>> error saying "cleanup first"?
>
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
>
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.
After we release 1.7 it's different. We can choose to autoupgrade, or
we can treat it like 1.6 and say that an upgrade step is required.
It's hard to predict the future. If 1.8 uses a totally different
backend for the wc then while we would support upgrading from a 1.7 wc
we might not support running 1.7 workqueues.
>> That's just one example. I don't know exactly which workqueue items
>> break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
>> ones that are no longer in log.c that break, as well as non-loggy
>> ones.
>
> Yup. And you'll also note Bert's latest change to the postcommit
> workqueue item. Before fetching the "no_unlock" parameter from the
> stored skel, he first checked whether it exists. If that portion of
> the skel does not exist (stale item!), then it just assumes
> no_unlock=TRUE.
I'd argue that's unneccesary, it's a maintenance burden we don't need.
Is there a regression test? Does it still work? However it's trivial
compared to supporting an XML parser that's not otherwise required.
> Another approach is to rename the work item in the OP_FOO symbols.
> Stale items become obvious when the new code cannot run them.
>
> I hope that clarifies things, and explains why this change should be
> reverted. I understand your desire to avoid upgrading stale work
> items. We don't have to do that *today*, but we need to plan for it in
> the future, and organize our code/process for that.
I still disagree. Having made the decision to introduce an upgrade
step for 1.6-to-1.7 we should take full advantage of that. The
intermediate pre-1.7 workqueues do not need to be supported. Then we
can throw out all the log parsing code.
--
Philip
RE: auto-upgrade of working copy
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
We haven't done this so far, but there's the option of allowing svn 1.8 to
write into 1.7 wc's (thus making 'svn upgrade' an optional-to-run command)
--- just as we do on the server (repos) end.
Bolstridge, Andrew wrote on Thu, 1 Jul 2010 at 11:23 -0000:
> > -----Original Message-----
> > From: Alan Barrett [mailto:apb@cequrux.com]
> > Sent: Thursday, July 01, 2010 8:26 AM
> > To: dev@subversion.apache.org
> > Subject: auto-upgrade of working copy
> >
> [snip]
> > The auto-upgrade has always bothered me. I'd much prefer to have a
> > command line action (e.g. "svn upgrade") to upgrade the working copy,
> > and for the default behaviour to be that the client prints an error
> > message suggesting that the user should run "svn upgrade".
> >
> > Many people use different clients in the same working copy (e.g. a
> > command line client and a GUI client), and it's a pain if one client
> > decides to upgrade the working copy to a format that the other client
> > doesn't support.
> >
>
> Can I second this - a little while back TortoiseSVN was upgraded to svn
> 1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working
> copies could not be used by Ankh in Visual Studio, or if you wanted to
> use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at
> AnkhSVN did issue a new version, but only after a few weeks.
>
> Next time, I would manage a rollout of 1.7 clients now, waiting until
> all clients we use had been upgraded before blindly upgrading as soon as
> the new version was available. That's probably the best system to use,
> and an auto-upgrade would be preferable. If the release notes gave a big
> warning reminder about this, that might be the best means of managing WC
> upgrades.
>
>
RE: auto-upgrade of working copy
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Alan Barrett [mailto:apb@cequrux.com]
> Sent: Thursday, July 01, 2010 8:26 AM
> To: dev@subversion.apache.org
> Subject: auto-upgrade of working copy
>
[snip]
> The auto-upgrade has always bothered me. I'd much prefer to have a
> command line action (e.g. "svn upgrade") to upgrade the working copy,
> and for the default behaviour to be that the client prints an error
> message suggesting that the user should run "svn upgrade".
>
> Many people use different clients in the same working copy (e.g. a
> command line client and a GUI client), and it's a pain if one client
> decides to upgrade the working copy to a format that the other client
> doesn't support.
>
Can I second this - a little while back TortoiseSVN was upgraded to svn
1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working
copies could not be used by Ankh in Visual Studio, or if you wanted to
use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at
AnkhSVN did issue a new version, but only after a few weeks.
Next time, I would manage a rollout of 1.7 clients now, waiting until
all clients we use had been upgraded before blindly upgrading as soon as
the new version was available. That's probably the best system to use,
and an auto-upgrade would be preferable. If the release notes gave a big
warning reminder about this, that might be the best means of managing WC
upgrades.
Re: auto-upgrade of working copy
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Thu, 1 Jul 2010 at 12:33 -0000:
> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).
Including devs around the time of WC format bumps. :-)
Re: auto-upgrade of working copy
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Thu, 1 Jul 2010 at 13:45 -0400:
> Due to the way TSVN is integrated into Windows you can only have one
> version installed. So this scenario really cannot happen, other than
> doing a complete uninstall of 1.6 and reinstalling 1.5.
Then let's assume that they either do a complete reinstall as you say, or
use some other client. (My point wasn't specific to TSVN.)
Re: auto-upgrade of working copy
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 1, 2010 at 1:24 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> I would guess a good percentage of those users, likely the majority,
>> use no other SVN client.
>
> There is the "I have TSVN 1.5 and want to try TSVN 1.6 without
> irreversibly breaking all my working copies" scenario.
>
> (I would guess not everyone who uses TSVN is going to create a test
> repository, populate it, and checkout it just in order to play with
> a new TSVN version; or maybe they have other reasons for wanting to play
> with the new version on their everyday WC)
Due to the way TSVN is integrated into Windows you can only have one
version installed. So this scenario really cannot happen, other than
doing a complete uninstall of 1.6 and reinstalling 1.5.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: auto-upgrade of working copy
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Thu, 1 Jul 2010 at 10:38 -0400:
> On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling <st...@elego.de> wrote:
>
> >> We are only ever going to hear the complaints. That does not mean
> >> they speak for the majority of users.
> >
> > Oh, I didn't mean to imply that I'd expect people to write in
> > out of the blue, asking for the feature to be kept.
> >
> > I meant to say that I cannot recall any user ever requesting
> > that auto-upgrades be kept during a discussion about whether
> > or not auto-upgrades should be happening or not.
> >
> > Is there anyone? If so, speak up, now is your chance :)
>
> Well TortoiseSVN, as an example, has been downloaded over 22 million times:
>
> http://sourceforge.net/top/topalltime.php?type=downloads
>
> I would guess a good percentage of those users, likely the majority,
> use no other SVN client.
There is the "I have TSVN 1.5 and want to try TSVN 1.6 without
irreversibly breaking all my working copies" scenario.
Daniel
(I would guess not everyone who uses TSVN is going to create a test
repository, populate it, and checkout it just in order to play with
a new TSVN version; or maybe they have other reasons for wanting to play
with the new version on their everyday WC)
Re: auto-upgrade of working copy
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 01, 2010 at 05:00:13PM -0400, Greg Stein wrote:
> Yup. I have dozens of working copies. The auto-upgrade is an awesome
> and useful feature. I don't have to worry about the fact that
> Subversion has changed something in its metadata. Why the heck should
> I care?
>
> The manual upgrade process is the odd-man-out here. As I mentioned
> earlier, we decided on that with *reluctance* because of the manual
> intervention that it will impose upon people. That we are monkeying
> with something so strongly, that we couldn't make it invisible to the
> user.
>
> "Easy" should be the prevailing case, and that means auto-upgrade.
>
Fair enough, we can default to auto-upgrade.
> Config options? Bleah. I dislike increasing the conceptual burden on
> our users ("hunh? should I set this? what is the impact? why do I need
> it? is this a good idea? am I gonna break something?").
Let's at least provide a config flag to disable it so users who really
don't want it can turn it off. If turned off, we provide an informative
prompt that asks the user if proceeding with the upgrade is fine and
warns about implications with multi-client use.
Then, when the day of server-side configuration finally comes, admins
can turn auto-upgrade off for all their users if they know that users will
(maybe just temporarily) be using multiple clients in incompatible versions.
I think this would make things a lot easier for users in environments
where tortoise, cli clients and various eclipse plugins all touch the
same working copies.
For this group of users, auto-upgrade is really annoying, especially
if people managing the client installations don't upgrade all svn clients
consistently.
Actually, the problem is not so much in the upgrade itself (people
eventually realise what happened and get new WCs), but poor user
interfaces.
E.g. eclipse simply 'disconnects' unreadable working copies.
They're just gone. They disappear from the workspace after a CLI client
or tortoise upgraded them. This is highly confusing, so if we required
all svn clients using 1.7 and above to pass in a callback for prompting
users about the upgrade if the config says to do so, the user will at
least have been prompted and will know what has happened.
This make most sense with server-side configuration of course.
But that's already on the long-term road map.
Stefan
Re: auto-upgrade of working copy
Posted by Greg Stein <gs...@gmail.com>.
Yup. I have dozens of working copies. The auto-upgrade is an awesome
and useful feature. I don't have to worry about the fact that
Subversion has changed something in its metadata. Why the heck should
I care?
The manual upgrade process is the odd-man-out here. As I mentioned
earlier, we decided on that with *reluctance* because of the manual
intervention that it will impose upon people. That we are monkeying
with something so strongly, that we couldn't make it invisible to the
user.
"Easy" should be the prevailing case, and that means auto-upgrade.
Config options? Bleah. I dislike increasing the conceptual burden on
our users ("hunh? should I set this? what is the impact? why do I need
it? is this a good idea? am I gonna break something?").
Cheers,
-g
On Thu, Jul 1, 2010 at 11:20, Bob Jenkins <rj...@collab.net> wrote:
> I think the question you'd get a better response on would be do they use
> multiple clients on a single working copy. That's really the only
> scenario where they are likely to not want to upgrade the working copy.
> Not to say there aren't other edge cases, but this change would seem to
> mainly play to this group. The others are just having to take an action
> they want 90+% of the time.
>
> Bob Jenkins
>
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Thursday, July 01, 2010 10:48 AM
> To: Mark Phippard; dev@subversion.apache.org
> Subject: RE: auto-upgrade of working copy
>
> tortoise is a GUI and it could present a simple "Ok to upgrade your
> working copy" dialog.
>
> Perhaps an email on the user list to do an informal poll?
>
> BOb
>
>
RE: auto-upgrade of working copy
Posted by Bob Jenkins <rj...@collab.net>.
I think the question you'd get a better response on would be do they use
multiple clients on a single working copy. That's really the only
scenario where they are likely to not want to upgrade the working copy.
Not to say there aren't other edge cases, but this change would seem to
mainly play to this group. The others are just having to take an action
they want 90+% of the time.
Bob Jenkins
-----Original Message-----
From: Bob Archer [mailto:Bob.Archer@amsi.com]
Sent: Thursday, July 01, 2010 10:48 AM
To: Mark Phippard; dev@subversion.apache.org
Subject: RE: auto-upgrade of working copy
tortoise is a GUI and it could present a simple "Ok to upgrade your
working copy" dialog.
Perhaps an email on the user list to do an informal poll?
BOb
RE: auto-upgrade of working copy
Posted by Bob Archer <Bo...@amsi.com>.
> >> We are only ever going to hear the complaints. That does not
> mean
> >> they speak for the majority of users.
> >
> > Oh, I didn't mean to imply that I'd expect people to write in
> > out of the blue, asking for the feature to be kept.
> >
> > I meant to say that I cannot recall any user ever requesting
> > that auto-upgrades be kept during a discussion about whether
> > or not auto-upgrades should be happening or not.
> >
> > Is there anyone? If so, speak up, now is your chance :)
>
> Well TortoiseSVN, as an example, has been downloaded over 22
> million times:
>
> http://sourceforge.net/top/topalltime.php?type=downloads
>
> I would guess a good percentage of those users, likely the
> majority,
> use no other SVN client. In the Eclipse world we certainly have a
> decent number of users that do not know what a command line is or
> use
> any other client (probably not a majority of users though).
>
> I think anyone that basically just uses one client enjoys the fact
> that they do not have to think about this aspect of Subversion. We
> will soon enough learn if having to take a specific upgrade step
> introduces any usability problems for these users.
>
> As I said though, I still think the explicit upgrade makes sense.
> It
> might cause some pain though.
>
tortoise is a GUI and it could present a simple "Ok to upgrade your working copy" dialog.
Perhaps an email on the user list to do an informal poll?
BOb
Re: auto-upgrade of working copy
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling <st...@elego.de> wrote:
>> We are only ever going to hear the complaints. That does not mean
>> they speak for the majority of users.
>
> Oh, I didn't mean to imply that I'd expect people to write in
> out of the blue, asking for the feature to be kept.
>
> I meant to say that I cannot recall any user ever requesting
> that auto-upgrades be kept during a discussion about whether
> or not auto-upgrades should be happening or not.
>
> Is there anyone? If so, speak up, now is your chance :)
Well TortoiseSVN, as an example, has been downloaded over 22 million times:
http://sourceforge.net/top/topalltime.php?type=downloads
I would guess a good percentage of those users, likely the majority,
use no other SVN client. In the Eclipse world we certainly have a
decent number of users that do not know what a command line is or use
any other client (probably not a majority of users though).
I think anyone that basically just uses one client enjoys the fact
that they do not have to think about this aspect of Subversion. We
will soon enough learn if having to take a specific upgrade step
introduces any usability problems for these users.
As I said though, I still think the explicit upgrade makes sense. It
might cause some pain though.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: auto-upgrade of working copy
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 01, 2010 at 10:19:08AM -0400, Mark Phippard wrote:
> On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
> >> The auto-upgrade has always bothered me. I'd much prefer to have a
> >> command line action (e.g. "svn upgrade") to upgrade the working copy,
> >> and for the default behaviour to be that the client prints an error
> >> message suggesting that the user should run "svn upgrade".
> >
> > I have repeatedly heard similar complaints and would therefore prefer
> > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> > starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> > feature to be kept.
>
> I am not against having an svn upgrade, but it seems worth noting why
> would anyone bother to report that they want you to keep a feature
> they already have? If users are happy with auto-upgraded working
> copies, which is all we ever gave them, why would they feel the need
> to post requests to keep the feature?
>
> We are only ever going to hear the complaints. That does not mean
> they speak for the majority of users.
Oh, I didn't mean to imply that I'd expect people to write in
out of the blue, asking for the feature to be kept.
I meant to say that I cannot recall any user ever requesting
that auto-upgrades be kept during a discussion about whether
or not auto-upgrades should be happening or not.
Is there anyone? If so, speak up, now is your chance :)
Stefan
Re: auto-upgrade of working copy
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 01, 2010 at 10:19:08AM -0400, Mark Phippard wrote:
> On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
> >> The auto-upgrade has always bothered me. I'd much prefer to have a
> >> command line action (e.g. "svn upgrade") to upgrade the working copy,
> >> and for the default behaviour to be that the client prints an error
> >> message suggesting that the user should run "svn upgrade".
> >
> > I have repeatedly heard similar complaints and would therefore prefer
> > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> > starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> > feature to be kept.
>
> I am not against having an svn upgrade, but it seems worth noting why
> would anyone bother to report that they want you to keep a feature
> they already have? If users are happy with auto-upgraded working
> copies, which is all we ever gave them, why would they feel the need
> to post requests to keep the feature?
>
> We are only ever going to hear the complaints. That does not mean
> they speak for the majority of users.
Oh, I didn't mean to imply that I'd expect people to write in
out of the blue, asking for the feature to be kept.
I meant to say that I cannot recall any user ever requesting
that auto-upgrades be kept during a discussion about whether
or not auto-upgrades should be happening or not.
Is there anyone? If so, speak up, now is your chance :)
Stefan
Re: auto-upgrade of working copy
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
>> The auto-upgrade has always bothered me. I'd much prefer to have a
>> command line action (e.g. "svn upgrade") to upgrade the working copy,
>> and for the default behaviour to be that the client prints an error
>> message suggesting that the user should run "svn upgrade".
>
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> feature to be kept.
I am not against having an svn upgrade, but it seems worth noting why
would anyone bother to report that they want you to keep a feature
they already have? If users are happy with auto-upgraded working
copies, which is all we ever gave them, why would they feel the need
to post requests to keep the feature?
We are only ever going to hear the complaints. That does not mean
they speak for the majority of users.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: auto-upgrade of working copy
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: donderdag 1 juli 2010 11:34
> To: Alan Barrett
> Cc: dev@subversion.apache.org
> Subject: Re: auto-upgrade of working copy
>
> On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> > On Wed, 30 Jun 2010, Greg Stein wrote:
> > > Nope. Users cannot generally downgrade their client to run a
> cleanup.
> > > Historically, we have always auto-upgraded the working copies, even
> > > with stale logs in them.
> > >
> > > The 1.7 upgrade process is too invasive and time-consuming, so we
> > > decided to have a manual process ('svn upgrade'). But moving
> forward,
> > > the intent is to continue an auto-upgrade mechanism even with stale
> > > workqueues.
> >
> > The auto-upgrade has always bothered me. I'd much prefer to have a
> > command line action (e.g. "svn upgrade") to upgrade the working copy,
> > and for the default behaviour to be that the client prints an error
> > message suggesting that the user should run "svn upgrade".
>
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-
> upgrade
> feature to be kept.
>
> The CLI client can print an error. GUI clients can show a window
> prompting
> the user whether to run an upgrade or bail out.
Hmm... and how does a client that is build/designed against 1.5, but now
linked against 1.8 handle this?
It doesn't know how to call svn_client_upgrade() as that is only introduced
in 1.7.
Possible fix: Maybe we should also enable upgrading from older variants of
svn_client_cleanup().
Older clients know how to call that function.
> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).
>
> We could also add a configuration option to ~/.subversion/config that
> causes working copies to always be auto-upgraded, defaulting to 'off'.
And how does libsvn_wc (and especially the deprecated functions that don't
receive a wc_ctx) decide which config file it should use? Not all functions
receive the configuration that is read by svn and then posted in the
svn_client_ctx_t.
Bert
RE: auto-upgrade of working copy
Posted by Bob Archer <Bo...@amsi.com>.
> I have repeatedly heard similar complaints and would therefore
> prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working
> copies
> starting with 1.7. And I have never heard anyone asking for the
> auto-upgrade
> feature to be kept.
>
> The CLI client can print an error. GUI clients can show a window
> prompting
> the user whether to run an upgrade or bail out.
>
> This does not harm people using a single client much, but helps
> users
> who use several clients simultaneously a lot (they don't have to
> get
> fresh WCs to continue getting work done).
>
> We could also add a configuration option to ~/.subversion/config
> that
> causes working copies to always be auto-upgraded, defaulting to
> 'off'.
>
I know this isn't a democracy, but if you are looking for votes this does seem like a more reasonable way to handle it. Especially in keeping with the goal of "not changing your data unless you tell it to" meme.
BOb
Re: auto-upgrade of working copy
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> On Wed, 30 Jun 2010, Greg Stein wrote:
> > Nope. Users cannot generally downgrade their client to run a cleanup.
> > Historically, we have always auto-upgraded the working copies, even
> > with stale logs in them.
> >
> > The 1.7 upgrade process is too invasive and time-consuming, so we
> > decided to have a manual process ('svn upgrade'). But moving forward,
> > the intent is to continue an auto-upgrade mechanism even with stale
> > workqueues.
>
> The auto-upgrade has always bothered me. I'd much prefer to have a
> command line action (e.g. "svn upgrade") to upgrade the working copy,
> and for the default behaviour to be that the client prints an error
> message suggesting that the user should run "svn upgrade".
I have repeatedly heard similar complaints and would therefore prefer
an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
starting with 1.7. And I have never heard anyone asking for the auto-upgrade
feature to be kept.
The CLI client can print an error. GUI clients can show a window prompting
the user whether to run an upgrade or bail out.
This does not harm people using a single client much, but helps users
who use several clients simultaneously a lot (they don't have to get
fresh WCs to continue getting work done).
We could also add a configuration option to ~/.subversion/config that
causes working copies to always be auto-upgraded, defaulting to 'off'.
Stefan
auto-upgrade of working copy
Posted by Alan Barrett <ap...@cequrux.com>.
On Wed, 30 Jun 2010, Greg Stein wrote:
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
>
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.
The auto-upgrade has always bothered me. I'd much prefer to have a
command line action (e.g. "svn upgrade") to upgrade the working copy,
and for the default behaviour to be that the client prints an error
message suggesting that the user should run "svn upgrade".
Many people use different clients in the same working copy (e.g. a
command line client and a GUI client), and it's a pain if one client
decides to upgrade the working copy to a format that the other client
doesn't support. This gets even worse when working copies are shared by
multiple users (which happens a lot more often than I would like).
--apb (Alan Barrett)
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> On Wed, Jun 30, 2010 at 13:55, Philip Martin <ph...@wandisco.com> wrote:
>> Greg Stein <gs...@gmail.com> writes:
>>
>>> I completely disagree with this.
>>>
>>> Didn't I just get done describing the intent here?
>>
>> You didn't respond to my questions in the last thread.
>
> Gee. I'm sorry. I have a life. I don't have time to respond to
> everything RIGHT NOW. Maybe I needed to think about it? Maybe I'm
> traveling. Maybe I just want to sit back and play Mass Effect 2 for a
> while.
I realise that. You seemed to be accusing me of ignoring you, and I
was pointing out that I didn't ignore you it's just that I don't agree
with you. Sorry if it came across the wrong way.
>>> We allow the
>>> upgrade to continue. If there is an impact on work queue items, then
>>> they must be upgraded, too.
>>
>> We don't generally support running old workqueues with newer code, so
>> why is uprade so different? Take this recent commit:
>>
>> http://svn.apache.org/viewvc?rev=959374&view=rev
>>
>> it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
>> log actions we effectively broke any workqueue that included them.
>> Nobody has written any code to migrate those workqueues.
>
> Yup. And because that would only affect devs, and when the workqueue
> code throws an error saying "dunno what 'delete-lock' means", then
> that dev has an easy way to fix themselves. It is an obvious failure
> mode.
>
> I don't care about breaking devs. The interim formats before 1.7 is
> released can enforce a cleanup first. But even that is a pain. I'd
> rather just see something fail in an obvious way and let the dev fix
> it up.
For devs it's better not to autoupgrade. Then they can revert to the
version that generated the workqueue and use that. If we autoupgrade
they have no usable version.
> BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>
>>> Clients are not expected to back up to previous revisions and run "svn
>>> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>>>>From then on, we can/should/will perform an upgrade with a non-empty
>>> work queue. Every single auto-upgrade in the past has operated in this
>>> fashion, and we will continue to do so from 1.7 onwards.
>>>
>>> Please revert. This is contrary to the design that I explained just
>>> yesterday.
>>
>> Why is it so important to support this? It doesn't affect many people
>> but writing the code to upgrade log items is a big effort. And it's
>
> We don't have to upgrade today's workqueue items. We simply have to
> have a policy to upgrade them once 1.7 is released.
I don't see the difference. At some point you have to write the code
to do it.
> The process that I
> encoded in the db-opening logic was to support THAT purpose.
>
>> not code that will get used by anyone other than people running dev
>> code. It will be poorly tested and a maintenance burden. How long do
>> we keep it? How far back in wcng history do we support?
>>
>> Take this workqueue item:
>>
>> 13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
>> dest=".svn/text-base/f.svn-base"
>> name=".svn/svn-ZIxV3z"/>
>> )
>>
>> It will break the working copy on upgrade because the wrong text-base
>> will get copied into the pristine store.
>
> Right. Let it break.
>
> At 1.7 release time, the above style of wq item could be hard to
> upgrade, so we could make it more semantic-based. "install TEMP into
> pristine store as CHECKSUM". That would be much more resilient to
> changes in the working copy format.
But your plan is that at release we should be capable of handling that
old workqueue item? This is a workqueue item only ever produced by a
dev version. I'd argue that these pre-1.7 dev workqueues don't need
to be supported long-term. You realise that the XML parser in log.c
would have to be retained, probably including bits that have already
been deleted? And that parser would never be used by people upgrading
from 1.6, since they have to cleanup first.
>> When we upgrade and run the
>> workqueue it will probably fail because the .svn/text-base no longer
>> exists. How will the user handle that? Isn't it better to get an
>> error saying "cleanup first"?
>
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
>
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.
After we release 1.7 it's different. We can choose to autoupgrade, or
we can treat it like 1.6 and say that an upgrade step is required.
It's hard to predict the future. If 1.8 uses a totally different
backend for the wc then while we would support upgrading from a 1.7 wc
we might not support running 1.7 workqueues.
>> That's just one example. I don't know exactly which workqueue items
>> break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
>> ones that are no longer in log.c that break, as well as non-loggy
>> ones.
>
> Yup. And you'll also note Bert's latest change to the postcommit
> workqueue item. Before fetching the "no_unlock" parameter from the
> stored skel, he first checked whether it exists. If that portion of
> the skel does not exist (stale item!), then it just assumes
> no_unlock=TRUE.
I'd argue that's unneccesary, it's a maintenance burden we don't need.
Is there a regression test? Does it still work? However it's trivial
compared to supporting an XML parser that's not otherwise required.
> Another approach is to rename the work item in the OP_FOO symbols.
> Stale items become obvious when the new code cannot run them.
>
> I hope that clarifies things, and explains why this change should be
> reverted. I understand your desire to avoid upgrading stale work
> items. We don't have to do that *today*, but we need to plan for it in
> the future, and organize our code/process for that.
I still disagree. Having made the decision to introduce an upgrade
step for 1.6-to-1.7 we should take full advantage of that. The
intermediate pre-1.7 workqueues do not need to be supported. Then we
can throw out all the log parsing code.
--
Philip
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jun 30, 2010 at 13:55, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> I completely disagree with this.
>>
>> Didn't I just get done describing the intent here?
>
> You didn't respond to my questions in the last thread.
Gee. I'm sorry. I have a life. I don't have time to respond to
everything RIGHT NOW. Maybe I needed to think about it? Maybe I'm
traveling. Maybe I just want to sit back and play Mass Effect 2 for a
while.
>> We allow the
>> upgrade to continue. If there is an impact on work queue items, then
>> they must be upgraded, too.
>
> We don't generally support running old workqueues with newer code, so
> why is uprade so different? Take this recent commit:
>
> http://svn.apache.org/viewvc?rev=959374&view=rev
>
> it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
> log actions we effectively broke any workqueue that included them.
> Nobody has written any code to migrate those workqueues.
Yup. And because that would only affect devs, and when the workqueue
code throws an error saying "dunno what 'delete-lock' means", then
that dev has an easy way to fix themselves. It is an obvious failure
mode.
I don't care about breaking devs. The interim formats before 1.7 is
released can enforce a cleanup first. But even that is a pain. I'd
rather just see something fail in an obvious way and let the dev fix
it up.
BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>> Clients are not expected to back up to previous revisions and run "svn
>> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>>>From then on, we can/should/will perform an upgrade with a non-empty
>> work queue. Every single auto-upgrade in the past has operated in this
>> fashion, and we will continue to do so from 1.7 onwards.
>>
>> Please revert. This is contrary to the design that I explained just
>> yesterday.
>
> Why is it so important to support this? It doesn't affect many people
> but writing the code to upgrade log items is a big effort. And it's
We don't have to upgrade today's workqueue items. We simply have to
have a policy to upgrade them once 1.7 is released. The process that I
encoded in the db-opening logic was to support THAT purpose.
> not code that will get used by anyone other than people running dev
> code. It will be poorly tested and a maintenance burden. How long do
> we keep it? How far back in wcng history do we support?
>
> Take this workqueue item:
>
> 13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
> dest=".svn/text-base/f.svn-base"
> name=".svn/svn-ZIxV3z"/>
> )
>
> It will break the working copy on upgrade because the wrong text-base
> will get copied into the pristine store.
Right. Let it break.
At 1.7 release time, the above style of wq item could be hard to
upgrade, so we could make it more semantic-based. "install TEMP into
pristine store as CHECKSUM". That would be much more resilient to
changes in the working copy format.
> When we upgrade and run the
> workqueue it will probably fail because the .svn/text-base no longer
> exists. How will the user handle that? Isn't it better to get an
> error saying "cleanup first"?
Nope. Users cannot generally downgrade their client to run a cleanup.
Historically, we have always auto-upgraded the working copies, even
with stale logs in them.
The 1.7 upgrade process is too invasive and time-consuming, so we
decided to have a manual process ('svn upgrade'). But moving forward,
the intent is to continue an auto-upgrade mechanism even with stale
workqueues.
> That's just one example. I don't know exactly which workqueue items
> break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
> ones that are no longer in log.c that break, as well as non-loggy
> ones.
Yup. And you'll also note Bert's latest change to the postcommit
workqueue item. Before fetching the "no_unlock" parameter from the
stored skel, he first checked whether it exists. If that portion of
the skel does not exist (stale item!), then it just assumes
no_unlock=TRUE.
Another approach is to rename the work item in the OP_FOO symbols.
Stale items become obvious when the new code cannot run them.
I hope that clarifies things, and explains why this change should be
reverted. I understand your desire to avoid upgrading stale work
items. We don't have to do that *today*, but we need to plan for it in
the future, and organize our code/process for that.
Cheers,
-g
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jun 30, 2010 at 13:55, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> I completely disagree with this.
>>
>> Didn't I just get done describing the intent here?
>
> You didn't respond to my questions in the last thread.
Gee. I'm sorry. I have a life. I don't have time to respond to
everything RIGHT NOW. Maybe I needed to think about it? Maybe I'm
traveling. Maybe I just want to sit back and play Mass Effect 2 for a
while.
>> We allow the
>> upgrade to continue. If there is an impact on work queue items, then
>> they must be upgraded, too.
>
> We don't generally support running old workqueues with newer code, so
> why is uprade so different? Take this recent commit:
>
> http://svn.apache.org/viewvc?rev=959374&view=rev
>
> it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
> log actions we effectively broke any workqueue that included them.
> Nobody has written any code to migrate those workqueues.
Yup. And because that would only affect devs, and when the workqueue
code throws an error saying "dunno what 'delete-lock' means", then
that dev has an easy way to fix themselves. It is an obvious failure
mode.
I don't care about breaking devs. The interim formats before 1.7 is
released can enforce a cleanup first. But even that is a pain. I'd
rather just see something fail in an obvious way and let the dev fix
it up.
BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>> Clients are not expected to back up to previous revisions and run "svn
>> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>>From then on, we can/should/will perform an upgrade with a non-empty
>> work queue. Every single auto-upgrade in the past has operated in this
>> fashion, and we will continue to do so from 1.7 onwards.
>>
>> Please revert. This is contrary to the design that I explained just
>> yesterday.
>
> Why is it so important to support this? It doesn't affect many people
> but writing the code to upgrade log items is a big effort. And it's
We don't have to upgrade today's workqueue items. We simply have to
have a policy to upgrade them once 1.7 is released. The process that I
encoded in the db-opening logic was to support THAT purpose.
> not code that will get used by anyone other than people running dev
> code. It will be poorly tested and a maintenance burden. How long do
> we keep it? How far back in wcng history do we support?
>
> Take this workqueue item:
>
> 13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
> dest=".svn/text-base/f.svn-base"
> name=".svn/svn-ZIxV3z"/>
> )
>
> It will break the working copy on upgrade because the wrong text-base
> will get copied into the pristine store.
Right. Let it break.
At 1.7 release time, the above style of wq item could be hard to
upgrade, so we could make it more semantic-based. "install TEMP into
pristine store as CHECKSUM". That would be much more resilient to
changes in the working copy format.
> When we upgrade and run the
> workqueue it will probably fail because the .svn/text-base no longer
> exists. How will the user handle that? Isn't it better to get an
> error saying "cleanup first"?
Nope. Users cannot generally downgrade their client to run a cleanup.
Historically, we have always auto-upgraded the working copies, even
with stale logs in them.
The 1.7 upgrade process is too invasive and time-consuming, so we
decided to have a manual process ('svn upgrade'). But moving forward,
the intent is to continue an auto-upgrade mechanism even with stale
workqueues.
> That's just one example. I don't know exactly which workqueue items
> break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
> ones that are no longer in log.c that break, as well as non-loggy
> ones.
Yup. And you'll also note Bert's latest change to the postcommit
workqueue item. Before fetching the "no_unlock" parameter from the
stored skel, he first checked whether it exists. If that portion of
the skel does not exist (stale item!), then it just assumes
no_unlock=TRUE.
Another approach is to rename the work item in the OP_FOO symbols.
Stale items become obvious when the new code cannot run them.
I hope that clarifies things, and explains why this change should be
reverted. I understand your desire to avoid upgrading stale work
items. We don't have to do that *today*, but we need to plan for it in
the future, and organize our code/process for that.
Cheers,
-g
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> I completely disagree with this.
>
> Didn't I just get done describing the intent here?
You didn't respond to my questions in the last thread.
> We allow the
> upgrade to continue. If there is an impact on work queue items, then
> they must be upgraded, too.
We don't generally support running old workqueues with newer code, so
why is uprade so different? Take this recent commit:
http://svn.apache.org/viewvc?rev=959374&view=rev
it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
log actions we effectively broke any workqueue that included them.
Nobody has written any code to migrate those workqueues.
> Clients are not expected to back up to previous revisions and run "svn
> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>>From then on, we can/should/will perform an upgrade with a non-empty
> work queue. Every single auto-upgrade in the past has operated in this
> fashion, and we will continue to do so from 1.7 onwards.
>
> Please revert. This is contrary to the design that I explained just
> yesterday.
Why is it so important to support this? It doesn't affect many people
but writing the code to upgrade log items is a big effort. And it's
not code that will get used by anyone other than people running dev
code. It will be poorly tested and a maintenance burden. How long do
we keep it? How far back in wcng history do we support?
Take this workqueue item:
13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
dest=".svn/text-base/f.svn-base"
name=".svn/svn-ZIxV3z"/>
)
It will break the working copy on upgrade because the wrong text-base
will get copied into the pristine store. When we upgrade and run the
workqueue it will probably fail because the .svn/text-base no longer
exists. How will the user handle that? Isn't it better to get an
error saying "cleanup first"?
That's just one example. I don't know exactly which workqueue items
break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
ones that are no longer in log.c that break, as well as non-loggy
ones.
--
Philip
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> I completely disagree with this.
>
> Didn't I just get done describing the intent here?
You didn't respond to my questions in the last thread.
> We allow the
> upgrade to continue. If there is an impact on work queue items, then
> they must be upgraded, too.
We don't generally support running old workqueues with newer code, so
why is uprade so different? Take this recent commit:
http://svn.apache.org/viewvc?rev=959374&view=rev
it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
log actions we effectively broke any workqueue that included them.
Nobody has written any code to migrate those workqueues.
> Clients are not expected to back up to previous revisions and run "svn
> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
>>From then on, we can/should/will perform an upgrade with a non-empty
> work queue. Every single auto-upgrade in the past has operated in this
> fashion, and we will continue to do so from 1.7 onwards.
>
> Please revert. This is contrary to the design that I explained just
> yesterday.
Why is it so important to support this? It doesn't affect many people
but writing the code to upgrade log items is a big effort. And it's
not code that will get used by anyone other than people running dev
code. It will be poorly tested and a maintenance burden. How long do
we keep it? How far back in wcng history do we support?
Take this workqueue item:
13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 <mv
dest=".svn/text-base/f.svn-base"
name=".svn/svn-ZIxV3z"/>
)
It will break the working copy on upgrade because the wrong text-base
will get copied into the pristine store. When we upgrade and run the
workqueue it will probably fail because the .svn/text-base no longer
exists. How will the user handle that? Isn't it better to get an
error saying "cleanup first"?
That's just one example. I don't know exactly which workqueue items
break. SVN_WC__LOG_CP_AND_TRANSLATE probably breaks. There could be
ones that are no longer in log.c that break, as well as non-loggy
ones.
--
Philip