You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Madan U S <ma...@collab.net> on 2006/04/12 11:30:28 UTC
[svnmerge][proposal] svnmerge log/status
I raised this sometime back. Anyways, am posting again to get feedback. I want to implement a 'svnmerge status/log' feature.
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
Question, comments?
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'.
2) Should the status also list the blocked revisions?
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.
Regards,
Madan.
Re: [svnmerge][proposal] svnmerge log/status
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 12 Apr 2006, Madan S. wrote:
> On Wed, 12 Apr 2006 17:17:59 +0530, Giovanni Bajo <ra...@develer.com> wrote:
>
> > Madan U S <ma...@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
RE: [svnmerge][proposal] svnmerge log/status
Posted by Madan U S <ma...@collab.net>.
On Wed, 12 Apr 2006 17:17:59 +0530, Giovanni Bajo <ra...@develer.com> wrote:
> Madan U S <ma...@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.
Re: [svnmerge][proposal] svnmerge log/status
Posted by Giovanni Bajo <ra...@develer.com>.
Madan U S <ma...@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