controversial issues in the tracker
From: Markus Schaber <m.schaber_at_codesys.com>
Date: Fri, 20 Jun 2014 09:09:44 +0000
Hi,
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
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
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
|
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.