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

AW: rc1 is DOA. What now?

From: Markus Schaber <m.schaber_at_3s-software.com>
Date: Wed, 24 Aug 2011 08:46:17 +0200

Hi,

Von: Markus Schaber [mailto:m.schaber_at_3s-software.com]
> Von: Branko ─îibej [mailto:brane_at_xbc.nu]
> > I wonder if it even makes sense to fix this case for upgrade. After
> > all, we could just tell users to unlock files before upgrading their
> > working copies.
>
> This would be rather unfortunate for our users - it would force working
> copy upgrade to be an online operation (because the workflow includes locks,
> so our software would have to do an unlock-upgrade-relock cycle.)

To support this unlocking, it would additionally force our software to carry both SVN 1.6 and SVN 1.7 libraries at the same time.

A similar problem appears for most other users. All of them who update their software instead of installing the new version in parallel have the problem that they cannot unlock the working copies any more. This affects TortoiseSVN, AnkhSVN, VisualSVN, Subclipse, Subversive, or most users using the normal upgrade mechanism of their linux distro (very few of them ship both releases in parallel on a upgrade).

> Currently, this are only a few beta users, so we could live with that,
> however.

Just some more information about one of our use-case: Our CoDeSys IDE allows storing the project source archive on the PLC device. Now some service engineer needs to diagnose or fix some software on some customers PLC "in the field". She connects to the PLC, downloads the project archive (which includes the SVN working copy) to her Notebook, and now suddenly needs to "svn upgrade" to be able to continue working[1]. However, due to security reasons (StuxNet & co), she does not have connectivity to their svn repository at that site, so an offline working copy upgrade must be possible.

I admit that this is a rare use case (and currently only affects the few users of our first beta), but rather annoying (and expensive, a stopped PLC can cost millions) if it happens in production, say for svn 1.7 to 1.8 conversion.

However, it seems that Bert already forward-ported the patch to SharpSVN (Thanks!), so for us, it is a non-issue at the moment. I just wanted to illustrate some of the maybe more exotic, but real world usecases that most developers sitting at the desk in their office will never dream of.[2]

Best regards

Markus Schaber

[1] We still offer the workaround to disable svn support in that situation, but that means that structural modifications (additions, deletes, renames, moves, copies) are not synchronized to the working copy any more.

[2] I was such a clueless developer some time ago. If you ever want to change your view of software development, change your job to some company which also develops software, but in a completely different field, for completely different customers. You can re-use most of your skills, but have to apply them in an entirely changed world.
___________________________
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2011-08-24 08:47:25 CEST

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