[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Need API and subcommand to list eligible revisions to merge

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-06-09 00:28:22 CEST

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]').

  * 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.


> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.