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...
[snip]
>
> 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.
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. I hope my explanation is clear. Pl. let me know otherwise.
> 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")
Actually you got it wrong-side-up. 'svn status' is limited to the combined output and options provided by 'svnmerge integrated', 'svnmerge avail' and 'svnmerge hidden' (see below for 'svnmerge hidden' sub-proposal).
I agree about the disconnected and connected modes.
> 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".
No, No, No! That was not what I had in mind. What I had in mind was....
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.
(Internally, 'svn status' would use action_integrated(), action_avail() and action_hidden() ... we could even invoke command line svnmerge, but this might cause a slow-down.)
>
>> 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.
cool.
>
>> 2) Should the status also list the blocked revisions?
>
> Why not.
Okay. Now that we have come to this, I have another proposal in mind...
'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.
We would anyway have to implement action_hidden() for purposes of 'svn status', so why not expose it to the end-user?
>
>> 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).
cool. deal!
Regards,
Madan.
Received on Wed Apr 12 14:22:44 2006