On Thu, 07 Jun 2007, Mark Phippard wrote:
> There is a need for an API, and likely a subcommand, to list eligible
> revisions to merge. In a GUI client, when a user intends to
> cherry-pick some revisions, we will want to give them a select screen
> to select the revisions they need. It makes sense that this list of
> revisions should only contain the ones eligible to merge. Likewise,
> it makes sense that a command line user, or script, might want this
> same information.
Currently, you can calculate this information by running 'log' on a
merge source, then running 'svn_client_get_mergeinfo()' on your WC
path (the merge target), and subtracting any revisions from
'get_mergeinfo' from the set returned by 'log'.
While this isn't all that complicated, baking up an API that provides
this functionality seems pretty reasonable to me for a number of
reasons (e.g. IDE integration, merge UIs, SCM automation, etc.).
In notes/merge-tracking.txt, we have this task listed as:
* Provide a libsvn_client API capable of listing "all unmerged
revisions". Client tools will use this to allow the user to select
the revisions to merge (e.g. a la 'svn merge --show-available [URL]').
(kamesh)
* Always recurse (in case child merge info differs), but support the
--depth option.
* Need new RA call.
...
> Let me describe what I think I would like in Subclipse and JavaHL.
...
> void logMessages(String url, Revision pegRevision,
> Revision revisionStart,
> Revision revisionEnd, boolean stopOnCopy,
> boolean discoverPath, boolean includeMergedRevisions,
> long limit, LogMessageCallback callback,
> boolean showEligibleOnly, String mergeTarget)
>
> Basically, it adds a boolean that says to only show the eligible
> revisions, and a String to give the local path you are merging into.
> Internally, the API would use the mergeinfo property to filter the
> values returned from the API to only include revisions eligible to be
> merged.
In the C API, I could see this being implemented via a
svn_log_message_receiver2_t which filtered out revisions from the
merge info.
We could provide a similar LogMessageCallback without changing the
void logMessages(...) signature. Something like:
public EligableForMerge implements LogMessageCallback
{
public EligableForMerge(String mergeTarget);
}
What do you think?
> I think it makes sense that a command line user would want similar
> information. So as a strawman proposal, I am suggesting that we add
> option(s) to svn log. Off the top of my head:
>
> svn log --show-eligible-from=@repos/trunk "."
I think some mention of the word "merge" would need to appear
alongside "eligible". Else, the question "eligible for what?"
After some thought, I like the idea of tacking this onto 'log', since
it already produces the type of output you want. Alternately (or
additionally), tacking it onto 'info' might also make sense, but I
think you'd end up running 'log' most of the time anyways...
> So this command could only be run against a working copy. And you
> would need to use the --show-eligible-from option to provide the URL
> it is going to use to retrieve the log messages. A WC is needed to
> obtain the mergeinfo property from. Other options like -r, --limit,
> -g etc. could all be used as well.
+1
> An alternative would be to create a new subcommand, but given that the
> output ought to be the same as svn log, it makes sense to me to add an
> option to the existing command.
I greatly prefer using 'log' for this to adding a new subcommand.
- application/pgp-signature attachment: stored
Received on Sat Jun 9 00:28:48 2007