Madan U S <madan@collab.net> wrote:
> On 'svnmerge status' in a working copy, the user would see something like
> the following...
>
> svnmerge status for
> http://svn.collab.net/repos/svn/trunk/contrib/client-side:
>
> head : http://svn.collab.net/repos/svn/branches/1.2.x/contrib/client-side
> Integrated : 1-345,678,1234
> Available : 377,1454
>
> head : http://svn.collab.net/repos/svn/branches/1.3.x/contrib/client-side
> Integrated : 346-376,679-1233,1235
> Available : 378,1455
I'm lagging behind in the "svnmerge integrated" thread (sorry Daniel!), but
I still have to understand if this is duplicate functionality with "svnmerge
integrated", and if not why.
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") which would require server connection and show
also the available revisions. If we do this, we could make "svnmerge avail"
become an alias for "svnmerge status -U".
> Areas I need help:
> 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.
> 2) Should the status also list the blocked revisions?
Why not.
> 3) How do I go about submitting patches for this...
> 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).
Many thanks!
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 12 13:56:33 2006