notes/feedback/wandisco-round-tables-2011

   1 During February 2011, WANdisco twice held a one-day conference that included
   2 a Subversion "round table" feedback session.  Attendees were mainly on the
   3 technical side - project admins and sys admins - and some were customers.
   4
   5 The points below were raised in those discussions.
   6
   7 The purpose of this report is to record feedback from the users, so the
   8 replies given by committers at the time are not reported.  Some discussion
   9 points are omitted because I forgot to record them or because they did not
  10 seem relevant to being reported here.  I apologize for any mistakes I may
  11 have made in understanding or reporting the feedback.  Editorial comments
  12 are marked with '[...]'.
  13
  14
  15 * Do we have a standard repo that people can use to reproduce bugs against?
  16
  17   [The questioner felt that would make it easier for them to report bugs.]
  18
  19
  20 * Can we comment on branching and merging: why svn throws so many apparently
  21   trivial conflicts?
  22
  23
  24 * Can we split mrg-tracking phase from mrg application phase (like ClearCase
  25   does)?  That would reduce user frustration because at least they'd see
  26   progress.  Separating these two phases could potentially give users more
  27   flexibility in tackling a large merge.
  28
  29   Going further: in a merge dry run, could we cache the mrg-tracking phase
  30   result so that a subsequent real merge doesn't need to re-calculate it?
  31
  32
  33 * Changelists - does anyone use them?  Are they good enough?  They
  34   don't support overlapped changes (multiple changelists for different
  35   changes in the same file).
  36
  37
  38 * Branch management tools: Do we plan to support commands for marking a
  39   branch as "end of life" (like deleted, except still visible in branch
  40   listings) and "locked" as in a code-freeze?  These can be done by
  41   pre-commit hooks but would be very useful as client-side commands.
  42
  43
  44 * Merge info.
  45
  46   There are mergeinfo conflicts when merging a branch (presumably
  47   when merging in both directions).  Any improvements in this?
  48
  49   Does WCNG make mergeinfo a first-class citizen?
  50
  51   These users delete all mergeinfo on trunk after merging to a branch.
  52   Enables bi-directional merging.  They never need to merge *from*
  53   trunk.  [Did I get that right?  I didn't properly understand this
  54   scenario.]
  55
  56   These users delete mergeinfo relating to a branch when they delete the
  57   branch.  It seems that mergeinfo is obsolete.  Two of the attendees
  58   do.  [Did I get this right?]
  59
  60
  61 * Verbose mode for svn commands.  To help with diagnosing and reporting
  62   bugs, could we give more detailed diagnostic output, like e.g.  "ssh -vv"
  63   does?  [I think the questioner was imagining debug output at the level of
  64   the RA commands that we issue, or similar.]
  65
  66
  67 * Gnome keyring.  It's flaky: to get password into it first time doesn't
  68   always work.
  69
  70   [Others agree.  Perhaps not Subversion's fault - it seems to be like this
  71   with other software too.]
  72
  73
  74 * Merge dry run bug: A prop conflict invokes the interactive resolver, but
  75   shouldn't.
  76
  77   [This had already been fixed in trunk.  It has now been proposed for
  78   back-port.]
  79
  80
  81 * Merge: can we improve user experience by having a multi-phase option?
  82   That is, one in which svn stops after each "hard" bit (a history segment
  83   that involves one or more conflicts, perhaps) and lets the user sort it
  84   out (perhaps resolving and committing the result).  The user can then
  85   resume the merge from that point later.  Advantages in perceived
  86   usability: the user is involved and seeing progress and so more likely to
  87   be sympathetic to the delays, as well as improved chance of success.
  88
  89
  90 * Off-line commits - what exactly is intended?
  91
  92   [We indicated that the main options we're envisaging are better
  93   described as "shelving" (putting a change aside, like a patch file, to
  94   work on something else) and "checkpoint" (save the current state and
  95   carry on from there).]
  96
  97   What about the AccuRev "Keep" command?  That saves changes that are local
  98   to this WC, but saves them in the repo.  They go away when the WC is
  99   deleted.
 100
 101   Why use shelving rather than another WC?
 102
 103   [Answer: Because some people have very big WCs.]
 104
 105   My users have big WCs and would love shelving.  Is there currently any
 106   better (faster) way to check out a new WC to work in?
 107
 108   [Answer: Copy an existing one and then run 'revert' and/or 'switch'.]
 109
 110
 111 * Cancellation often doesn't work, at least not quickly.  It would be good
 112   to test it.
 113
 114
 115 * We use GitSvn.  It downloads a complete repo quicker than a trunk
 116   checkout, and then have most of Git's strengths - off-line commits,
 117   hunk-based commits, fast history access.  As a user, once you've tried it
 118   you won't want to go back to plain Svn.
 119
 120
 121 * You mentioned several times that you'd like feedback from the user
 122   community.  How should we go about giving this feedback to the Subversion
 123   team?  Can we have some tracker where we can vote for issues?
 124
 125   [We explained about dev@ etc.]
 126
 127
 128 * Would TortoiseSVN do 3-way merges?  It often seems to do 2-way merges.
 129
 130   [Tortoise does do 3-way merges when it can, but Svn doesn't always give it
 131   all three file-version references.]
 132
 133
 134 * Could TortoiseSVN warn before upgrading a WC to 1.7?  Otherwise users will
 135   not realize their other clients need to be upgraded at the same time.
 136
 137   [Seems like we should, both in TortoiseSVN and command-line client.]
 138
 139
 140 * The Svn warning given when a WC is too new confuses users and they ask
 141   their admin.  If it could simply read "You need a newer client" instead of
 142   "This client is too old", that would help.
 143
 144