[Svnmerge] block/unblock: first implementation and questions

[Giovanni Bajo]

Hello,

I implemented a first version of the block/unblock feature, available on my
SVN repository as always. I found a couple of gotchas I would like to
discuss:

- Should we allow recording as 'blocked' a revision which is phantom, or
already integrated? My feeling is no: I'd rather "svnmerge block" purges the
revision list specified by the user and only mark as blocked those revisions
which are really available.

- If "-r revs" is not specified, what is the default for "svnmerge
[un]block"? I'd say that the default for block is to block all the available
revisions, and for unblock to unblock all the previously blocked revisions
(but please see also next question).

- We are missing a way to list the blocked revisions. Options are:
   1) Introducing a new command, "svnmerge blocklist".
   2) Introducing a new option for "block" or "unblock" which means "do
nothing, just shows me the revisions".
   3) Show the list if one specifies "svnmerge block" with no arguments.
   4) Show the list if one specifies "svnmerge unblock" with no arguments.
My votes for the above options are, respectively, +1, -1, -0, +0. A new
command is the cleanest way, and very direct and easy for the user. Adding
an option looks wrong to me because it seriously affects the semantic of
"block"/"unblock", so much that they don't do anymore what they are supposed
to do. As for option 3/4 I prefer option 4 as it adheres to the common
workflow (e.g. first query the list, then remove a block; I don't see other
uses of querying the list if not to subsequently remove a block). Also,
"blocking everything left" is probably a common operation, while "unblocking
everything" should not be so common (and can still be done with "svnmerge
unblock -r1:HEAD").

- If the user explicitally asks to "svnmerge merge" a revision which is
blocked, what should svnmerge do? There are several options:
  1) If we agree that this should not be allowed, then we could:
     a) abort merge operation if a blocked revision is specified
     b) ignore the blocked revision (with a warning maybe) and do the other
merges (optionally notifying the user).
  2) If we agree that this should be done, then we could automatically
unblock the revision and optionally notify the user about it.
My feeling is that the default should be option 1b. Option 1a sounds a
little too hard, since we allow to specify ranges such as -r 100-200, and
"svnmerge merge" ignores those which are not available for merging. I also
don't see much value in an option for 2, since one can simply unblock all
the revisions with a simple command. Comments?

- What if the user asks to block/unblock revisions which do not exist / are
already (un)blocked / are already merged, so that the command ends up doing
nothing? Should we notify this with an error message (so that the process
exit code is != 0), or should it be just a normal report, or a special
report visible also in non-verbose mode?

Thanks,
-- 
Giovanni Bajo