On Wed, 12 Apr 2006, Madan S. wrote:
> On Wed, 12 Apr 2006 17:17:59 +0530, Giovanni Bajo <rasky@develer.com> wrote:
>
> > Madan U S <madan@collab.net> wrote:
> >
> >> On 'svnmerge status' in a working copy, the user would see something
> >> like the following...
...
> > I'm lagging behind in the "svnmerge integrated" thread (sorry Daniel!),
No sweat, Giovanni. I sent an update out yesterday which might be
helpful -- just skip to that if you want to read up on 'integrated'.
> > but I still have to understand if this is duplicate functionality with
> > "svnmerge integrated", and if not why.
Focusing on Madan's description of what 'status' would do (rather than
how it's implemented), he's proposing a single command which combines
the 'avail' and 'integrated' functions, and adds new output for "merge
source" and "blocked" info. This seems like a reasonable, if somewhat
redundant, enhancement which offers (1) convenience and (2) additional
information about blocked revisions. Madan's example (slightly
tweaked):
Source: http://svn.collab.net/repos/svn/branches/bogus-branch/contrib/client-side
Integrated: 1-345,678,1234
Available: 377,1454
Blocked: 378
> svn status internally uses the action_avail(), action_integrated()
> and action_blocked() (which can be used to support a 'svnmerge
> blocked' to list only the blocked revision on a given head) to
> provide the comprehensive merge status of a wc directory wrt to all
> heads it is tracked against. ...
This implementation would not be as efficient nor performant as one
which combined the guts of those functions. Refactoring could make
this possible without altering the command-line interface or API.
> > I'd like the default version being a disconnected operation (thus, no
> > list of "available revisions"). We could then have a -U/--show-updates
> > option (that mimics "svn status -U")
...
> I agree about the disconnected and connected modes.
Since 'avail' requires repository access, as does 'integrated' (as
currently implemented), 'status' does not strike me as very useful
without respository access.
...
> svnmerge avail [-u/--show-updates]
> svnmerge integrated [-u/--show-updates]
> svnmerge hidden [-u/--show-updates] (See sub-proposal for hidden below)
>
> The above work against a single head for a given wc dir, and... svn
> status [-u/--show-updates] will show all the info provided by the
> above three subcommands, for all the heads available.
...
> >> 1) Should we call it log or status? I would prefer to call this 'svn
> >> status', which is much more of what the output is, than log - which
> >> could also be confused with 'svn log'.
> >
> > I'd rather call it "status". I would like a "svnmerge log" which does a
> > different thing, that is the equivalent of calling "svn log" for all the
> > merges done in the branch.
...
Ditto, +1 on 'status'.
> >> 2) Should the status also list the blocked revisions?
> >
> > Why not.
>
> Okay.
Agreed, +1.
> 'svnmerge hidden' sub-proposal:
> ------------------------------------------------
> Let us implement 'svnmerge hidden [-u/--show-updates]'. This would
> list all the blocked revisions for the given wc dir, against a given
> head.
The name 'hidden' does not describe the behavior of a command used to
show the set of blocked revisions. 'blocked' is accurate, but could
be confused with 'block' (the verb). 'show-blocked' is more verbose,
but also accurate.
> We would anyway have to implement action_hidden() for purposes of
> 'svn status', so why not expose it to the end-user?
This is completely reasonable functionality. AFAICT, there's
currently no way for svnmerge.py itself to show blocked revisions --
one must currently use 'svn propget' (and possibly 'svn proplist') to
discover the set of blocked revisions. I'd like to see this
functionality implemented first, and accompanied by some test cases.
> >> 3) How do I go about submitting patches for this...
See my above comment on the "show blocked revisions" functionality.
> >> a) Should I file an issue somewhere and start working?
> >> b) Should I submit multiple (3 or 4) small patches or one
> >> monolithic patch? In the former approach, the functionality
> >> would be exposed in the last commit only. Till then, the
> >> patches would look mostly unrelated.
> >
> > I prefer small commits, if they make sense on their own. Adding a
> > function
> > without a caller is pointless, but factoring things out can be done as
> > separate commits (explaining that it's done to make way to the new
> > feature).
The key here being "if they make sense on their own". :)
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Thu Apr 13 18:52:13 2006