subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Schaber <>
Subject controversial issues in the tracker
Date Fri, 20 Jun 2014 09:09:44 GMT

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

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: | Web: | CODESYS store:
CODESYS forum:

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten
HRB 6186 | Tax ID No.: DE 167014915

View raw message