[svnmerge][proposal] svnmerge log/status

[Madan U S]

On Wed, 12 Apr 2006 17:17:59 +0530, Giovanni Bajo <rasky at develer.com> wrote:

> Madan U S <madan at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/svnmerge/attachments/20060412/f7949300/attachment.htm