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

controversial issues in the tracker

From: Markus Schaber <m.schaber_at_codesys.com>
Date: Fri, 20 Jun 2014 09:09:44 +0000


While querying the issue tracker for bite-sized issues, I found the following ones which seem to be controversial.

Maybe we should try to come to a consensus with each of them, either agreeing on a way of implementing them, or closing them as "won't fix".

* 4162 make svn status fix timestamp mismatches in meta-data

The controversial issue here is whether it is a good idea to have "svn status" modify the meta data - until now, it intentionally only has a read-only lock on the working copy, and changing that may have compatibility side effects.

Currently, correcting the metadata for files with updated timestamps (but unmodified content) is only available as a side-effect of other commands (update, cleanup, etc.) which all have other side-effects.

Thus, alternative solutions may be to pass an option to status which explicitly allows modification of the meta data, or create a command (or option to svn cleanup) which only fixes the timestamps without other side effects.

My personal suggestion is to add a flag to svn status.

* 2491 Add --dry-run flag to "svn update" client command

There already was a patch submitted by Arwin Arni 2011 and discussed on the list, but it was not applied due to objections.

The first controversial issue was of conceptual nature: This functionality somehow duplicates the semantics of "svn status -u" - on the other hand, "svn status -u" is known to not exactly give the desired semantics in some cases - especially, it can only tell about the existence of incoming changes, but not whether they're actually produce a conflict.

The second issue was more of an implementation issue - the patch spreads a lot of if()-branches in the code. Some developers would have preferred cleaner code by creating a separate editor driver. However, this will result in a bunch of duplicate code, which needs to be kept in sync (or the "--dry-run" mode will not match what the real update will perform. There is already a precedence for merge --dry-run.

See also the lengthy discussion at http://svn.haxx.se/dev/archive-2011-03/index.shtml#63

My personal opinion is that it is an useful feature, so we should try to agree on a way of implementing it. On the other hand, given that the provided patch does not cover some corner cases, it may actually not be "bite-sized". :-)

4154 svn add foo foo complains

This issue suggests removing duplicates in the argument list of "svn add". The example was the command line
 svn add f* *o
which lead to errors because the file "foo" was matched twice.

The discussion showed that there is no consensus on the correct behavior:

Problems were that this could easily paper over typos in the filenames, and the consistency between commands ("svn revert" currently doesn't error out on duplicate targets, while "svn cat" should not eliminate duplicates, as that will change semantics).

As there is an easy workaround of using "--force", my personal suggestion is to set this issue to "won't fix".

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2014-06-20 11:10:17 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.