[Svnmerge] block/unblock: first implementation and questions

Archie Cobbs archie at dellroad.org
Fri Sep 30 06:58:29 PDT 2005


Giovanni Bajo wrote:
> - 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.

Agreed.

> - 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").

Alternately: wouldn't you want to view the blocked revisions in log
entry or diff form sometimes? That suggests letting e.g. "svnmerge avail"
show you the block list. Then "block" and "unblock" can, with no flags,
by default block or unblock all revisions.

I guess you'd need something like this:

   svnmerge avail -b  - show me blocked revisions as well the usual stuff
   svnmerge avail -B  - show me ONLY blocked revisions

> - 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?

I prefer to force the user to manually unblock the revision before
letting them merge it, i.e., 1a... it preserves orthogonality.

Kindof like someone trying to open your car door when the car is locked.
Would you expect your car to assume that person knew what they were
doing and automatically unlock itself with a warning message? :-)

> - 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?

I think we should just ignore irrelevant revisions. E.g., it's handy
to be able to say "svnmerge block -r 1000-2000" as shorthand for what
you really meant, e.g., "-r 1021,1045,1433,1434,1598,1889,1932".

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com



More information about the Svnmerge mailing list