On Thu, Jun 28, 2012 at 5:45 AM, Branko Čibej <branko.cibej_at_wandisco.com> wrote:
> On 28.06.2012 05:24, Hyrum K Wright wrote:
>> On Wed, Jun 27, 2012 at 9:13 PM, Branko Čibej <branko.cibej_at_wandisco.com> wrote:
>>> On 28.06.2012 01:32, Greg Stein wrote:
>>>> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>>>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>>>>>> On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote:
>>>>> ...
>>>>>> I would prefer to by default keep working copy upgrades manual from now on.
>>>>> +1, let's please keep it an explicit action by the user.
>>>> Not sure about that. The user will type 'svn move' and not get the
>>>> benefits. All the docs will say it *should* work, but it doesn't.
>>> Not to mention feature-invariant updates, such as the new MD5 index. if
>>> you don't have it, nothing breaks except your patience. :)
>>>
>>> Realistically, we've "taught" users and especially packagers to expect
>>> silent updates (and have said loudly enough that 1.7/WC-NG is an
>>> exception). I think we should just keep on doing that.
>> Agreed, and I'm against the auto-update as well.
>
> Impedance mismatch? "Just keep on doing that" refers to automatic,
> silent WC updates. :)
>
> I cited the MD5 index as a case where you definitely want the update to
> be automatic.
Why should this be automatic? Just because users will definitely want
(the benifit of) this index, doesn't mean it should be applied
automatically at the next (write) action of some 1.8 client. (besides,
I'm not even sure if this index is "definitely useful": IIUC it came
about after Michael implemented
dont-download-existing-pristines-with-old-md5sending-servers, so at
least only 1.8 clients benifit from it. (unless that index is also
useful for other use cases??))
What if adding this index takes a significant amount of time? Maybe
the user has 2 million nodes in his working copy. I can imagine that
it may take several minutes for this index to be created. I'd not want
this to be automatic, behind my back, when I apply a simple 'propset'
or something like that.
> Now ... do we want to come up with a WC versioning scheme that allows
> partially automatic updates (e.g., for changes that are
> backward-compatible, such as adding a new index) but requiring manual
> intervention for incompatible changes? Maybe. Doing this would certainly
> make the code a lot more complex, not just the update part but also the
> requirement for newer versions to support (and emulate all the quirks
> of) older WC(-NG) formats.
>
> I'd want to think very, very carefully about doing this, maintaining
> such compatibility is likely to be quite tricky.
That's an interesting line of thought. But in that case, adding the
index (through some automatic upgrade) could also be backported to
1.7. Still, it might be a problem if the auto-upgrade is not fast
enough.
IMHO, to have automatic upgrade, we need at least:
1. It has to be fast, and O(1) (unless we can guarantee that it will
still be fast for working copies of a couple million nodes).
2. There needs to be a way to downgrade, to mitigate the problem of
accidental upgrades. Like the change-svn-wc-format.py script [1],
which could downgrade from 1.6 back to 1.5 and back to 1.4.
If the upgrade is manual, having no way to downgrade is still an
annoyance, but it's not a disaster (after all, the user manually
decided to upgrade, so he better be prepared for it).
Most svn users I talked to (my colleagues mostly) are very happy with
the non-auto-upgrade of 1.7, and they see it as a real improvement. It
makes the entire process less scary.
With auto-upgrade, the following often happens (happened):
- User has 3 svn clients: a commandline client, a GUI tool, and some
plugin in his IDE. These all have their own release cycles, so not all
of them may release 1.8 support at the same time.
- Somehow one of the three tools got upgraded to version 1.8 (maybe
even without much thought of the user ... maybe one of those software
packages is auto-updated, or it nags the users every time at startup
that a newer version is available, "please click here" etc ...).
- He touches his working copy with the upgraded tool: working copy is upgraded.
- Later, he fires up his IDE, and boom, "working copy format not
supported, please upgrade your client" - "WTF? What happened?" -
search the net - "Need to upgrade all clients ... #@$#%! svn ..." -
search the net some more - "@#$%@#$%! I can't upgrade my IDE plugin
because it's not release yet" - drink coffee and try to calm down -
search the net some more to find a way to downgrade - if there is no
(easily found) downgrade path: "@$%@#$$%#%#!!!! I HATE SVN, I should
have switched to git long ago." (random blurb in frustration)
- Even if this ends well, the user will have easily lost half a day,
when maybe he urgently needs to do something under a deadline.
So, if working copy formats are backward-incompatible, I would really
like to keep it a manual upgrade choice :-).
[1] http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py
--
Johan
Received on 2012-06-28 11:17:56 CEST