You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2013/03/27 17:18:48 UTC
Fold the merge_automatic API into the existing merge_peg API
Brane told me that while updating the JavaHL API he noticed that the new svn_client_merge_automatic() is Yet Another Merge API, and would prefer make the existing JavaHL merge API encompass that functionality rather than add yet another variant. So I said if let's see if we can apply that idea to the libsvn_client API.
Idea: 'automatic' merge is (in a high level logical sense) most similar to a subset of the 'pegged' merge. So make 'merge_peg' do the automatic merge (like calling the automatic merge API) if the params are suitable. The intention is that this should be easier for Subversion client developers to understand and for them to DTRT.
API differences between pegged and automatic merge:
Pegged merge Automatic merge
The 'find'API: Single merge_peg call does Separate'find' and 'do' calls.
the whole process. Result of 'find' tells what we found,
used for 'svn mergeinfo' graph.
Source: revision ranges X:Y[,X:Y...] revision range 0:Y
on branch URL@PEG on branch URL@PEG
Target: optional non-WC tgt for 'find'
If mergeinfo: skip already-merged revs (same)
record the merge
No mergeinfo: don't skip revs error out
don't record
Options differ: allow_mixed_rev allow_mixed_rev
allow_local_mods
allow_switched_subtrees
ignore_mergeinfo
At that level, it looks close enough to be feasible to embed 'automatic' merge inside 'pegged'. I'm looking closer now.
Any thoughts?
- Julian
--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote on 2013-04-01:
> TODO: Decide whether to keep or make private or delete the dedicated
> 'automatic merge' APIs.
The issues are:
* Do we want the API to be a special case of pegged merge, or a
dedicated API? (I don't want to clutter the API by having both
forms.) Using the pegged merge API makes a lot of sense, so
that seems to be the winner.
* What API should we use to access the 'svn mergeinfo' information?
The best option would seem to be a dedicated API, something like
the current 'find_automatic_merge' but less fussy.
PROPOSAL
* Make the 'automatic merge' APIs private, leaving svn_merge_peg5(
rev-range=null) as the public entry point.
* Deprecate svn_client_merge_reintegrate().
* For getting a mergeinfo graph, combine the 'find_automatic_merge'
API with the two getters (svn_client_automatic_merge_is_reintegrate_like(),
svn_client_automatic_merge_get_locations()) and return that
information directly. Rename to 'get merge history summary' or
something like that.
DISCUSSION
The 'automatic merge' performs a merge of 'all changes up to rX' from
the given source branch to the given target branch. There are currently
two ways of representing this in the libsvn_client API:
* Use the 'pegged merge' API with a null revision range.
* Use the dedicated 'automatic merge' APIs.
Differences:
- The 'automatic merge' API is split into 'find' and 'do' parts.
The rationale was so the caller can provide better feedback on
what's happening and potentially ask the user to confirm, for
better user awareness, to try to minimize user error. That isn't
essential, and that isn't the only way of providing feedback, and
the same could be done to the pegged merge API if we wanted, so
this should be neither pro nor con.
- With svn_client_merge_peg5(), passing 'ignore_mergeinfo' returns
an error. With the dedicated API there's no such option, as use
of mergeinfo is necessary.
- The flags for allowing the target WC to have mixed revs, switched
subtrees etc. are a bit different, but not in important ways --
the automatic merge API has more flags than necessary.
Review of merge APIs new or changed in 1.8:
svn_client_find_automatic_merge()
svn_client_find_automatic_merge_no_wc()
svn_client_do_automatic_merge()
svn_client_automatic_merge_is_reintegrate_like()
svn_client_automatic_merge_get_locations()
- See the proposal above.
svn_client_merge5()
- The two meanings of the old 'ignore ancestry' are now controlled by separate 'ignore_mergeinfo' and 'diff_ignore_ancestry' flags. I think this is fine.
svn_client_merge_peg5()
- The two meanings of the old 'ignore ancestry' are now separated. 'automatic merge' behaviour is now available, by passing in a null revision range. I think this is fine.
svn_client_mergeinfo_log2()
- This has just grown a revision range input. I think this is fine except the interpretation of 'unspecified' revisions could be cleaner.
I'll make this happen as proposed above, ASAP, unless I receive other suggestions in the meantime.
- Julian
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> On 28.03.2013 22:07, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 28.03.2013 21:38, Julian Foad wrote:
>>>> I like the focused API, but I also see how the automatic merge can be
>>>> considered to fill in a bit of missing functionality that merge_peg
>>>> ought to provide.
[...]
>>> I like it. Apparently the encapsulation is even simpler than I expected.
>>
>> Heads up: that patch is broken. merge_automatic_tests.py 7 though 14 all
>> fail. However, it's most likely broken in a rather trivial way so I expect
>> the corrected version will still be simple.
It was indeed a simple goof.
>>> For JavaHL, a simple overload of ISVNClient.merge can provide the
>>> "focused" interface without inventing yet another type of merge API.
>>> Even better, passing null for the revision ranges in the existing
>>> merge-peg overload can be made to yield the same effect, without
>>> affecting the API signature at all. (Currently IIUC passing a null
>>> ranges array will cause an error.)
>>
>> Making the C API accept NULL for the revision-ranges array argument
>> would be a totally sensible extension. I'll do that.
>
> I was thinking of the JavaHL API, but you're right -- the C API could
> benefit from the same simplification.
OK, I've got that working and I'm happy with it. Committed in 1463250. Any further review or changes can come later.
TODO: Decide whether to keep or make private or delete the dedicated 'automatic merge' APIs.
This reduces the verbosity of 'svn merge --verbose' for an automatic merge. We can consider putting some verbosity back in in another way. One option is to add some new notifications for the notifier callback, although I don't like that. I don't think this is important, so will leave it as it is unless we come up with a good suggestion.
- Julian
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Branko Čibej <br...@wandisco.com>.
On 28.03.2013 22:07, Julian Foad wrote:
> Branko Čibej wrote:
>
>> On 28.03.2013 21:38, Julian Foad wrote:
>>> I like the focused API, but I also see how the automatic merge can be
>>> considered to fill in a bit of missing functionality that merge_peg ought to
>>> provide.
>>>
>>> Perhaps we can have both. Teach merge_peg to DTRT in this case, and still
>>> have the focused API available for when a client knows it wants an automatic
>>> merge. Is there sufficient merit in that to outweigh the overhead of having to
>>> test two similar but different entry points?
>>>
>>> The attached patch moves the decision to call the 'automatic merge'
>>> API from 'svn' into 'svn_merge_peg5()'. I have run some merge
>>> tests and tree conflict tests, but not the whole test suite yet. Here is the
>>> log msg.
>>>
>>> [[[
>>> Teach svn_client_merge_peg5() to do an automatic merge, and let 'svn merge'
>>> rely on that instead of calling the dedicated automatic merge APIs.
>>>
>>> TODO: Decide whether to keep or make private the 'automatic merge' APIs.
>>> TODO: This reduces the verbosity of 'svn merge --verbose'. Consider
>>> doing something about it, perhaps by adding some new notifications for the
>>> notifier callback?
>>>
>>> * subversion/include/svn_client.h,
>>> subversion/libsvn_client/merge.c
>>> (svn_client_merge_peg5): Do an automatic merge if no revision range
>>> specified.
>>>
>>> * subversion/svn/merge-cmd.c
>>> (automatic_merge): Delete.
>>> (run_merge): Don't take special action to handle an automatic merge, let
>>> the pegged merge code path handle it.
>>> ]]]
>>>
>>> Thoughts?
>> I like it. Apparently the encapsulation is even simpler than I expected.
> Heads up: that patch is broken. merge_automatic_tests.py 7 though 14 all fail. However, it's most likely broken in a rather trivial way so I expect the corrected version will still be simple.
>
>> For JavaHL, a simple overload of ISVNClient.merge can provide the
>> "focused" interface without inventing yet another type of merge API.
>> Even better, passing null for the revision ranges in the existing
>> merge-peg overload can be made to yield the same effect, without
>> affecting the API signature at all. (Currently IIUC passing a null
>> ranges array will cause an error.)
> Making the C API accept NULL for the revision-ranges array argument would be a totally sensible extension. I'll do that.
I was thinking of the JavaHL API, but you're right -- the C API could
benefit from the same simplification.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> On 28.03.2013 21:38, Julian Foad wrote:
>> I like the focused API, but I also see how the automatic merge can be
>> considered to fill in a bit of missing functionality that merge_peg ought to
>> provide.
>>
>> Perhaps we can have both. Teach merge_peg to DTRT in this case, and still
>> have the focused API available for when a client knows it wants an automatic
>> merge. Is there sufficient merit in that to outweigh the overhead of having to
>> test two similar but different entry points?
>>
>> The attached patch moves the decision to call the 'automatic merge'
>> API from 'svn' into 'svn_merge_peg5()'. I have run some merge
>> tests and tree conflict tests, but not the whole test suite yet. Here is the
>> log msg.
>>
>> [[[
>> Teach svn_client_merge_peg5() to do an automatic merge, and let 'svn merge'
>> rely on that instead of calling the dedicated automatic merge APIs.
>>
>> TODO: Decide whether to keep or make private the 'automatic merge' APIs.
>> TODO: This reduces the verbosity of 'svn merge --verbose'. Consider
>> doing something about it, perhaps by adding some new notifications for the
>> notifier callback?
>>
>> * subversion/include/svn_client.h,
>> subversion/libsvn_client/merge.c
>> (svn_client_merge_peg5): Do an automatic merge if no revision range
>> specified.
>>
>> * subversion/svn/merge-cmd.c
>> (automatic_merge): Delete.
>> (run_merge): Don't take special action to handle an automatic merge, let
>> the pegged merge code path handle it.
>> ]]]
>>
>> Thoughts?
>
> I like it. Apparently the encapsulation is even simpler than I expected.
Heads up: that patch is broken. merge_automatic_tests.py 7 though 14 all fail. However, it's most likely broken in a rather trivial way so I expect the corrected version will still be simple.
> For JavaHL, a simple overload of ISVNClient.merge can provide the
> "focused" interface without inventing yet another type of merge API.
> Even better, passing null for the revision ranges in the existing
> merge-peg overload can be made to yield the same effect, without
> affecting the API signature at all. (Currently IIUC passing a null
> ranges array will cause an error.)
Making the C API accept NULL for the revision-ranges array argument would be a totally sensible extension. I'll do that.
- Julian
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Branko Čibej <br...@wandisco.com>.
On 28.03.2013 21:38, Julian Foad wrote:
> Now with a patch for discussion.
>
> (More below...)
>
> Julian Foad wrote:
>>> Brane told me that while updating the JavaHL API he noticed that the new
>>> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
>>> the existing JavaHL merge API encompass that functionality rather than add
>>> yet another variant. So I said if let's see if we can apply that idea to the
>>> libsvn_client API.
>>>
>>> Idea: 'automatic' merge is (in a high level logical sense) most similar to
>>> a subset of the 'pegged' merge. So make 'merge_peg' do the automatic merge
>>> (like calling the automatic merge API) if the params are suitable. The
>>> intention is that this should be easier for Subversion client developers to
>>> understand and for them to DTRT.
>>>
>>> API differences between pegged and automatic merge:
>>>
>>> Pegged merge Automatic merge
>>>
>>> The 'find'API: Single merge_peg call does Separate'find' and 'do'..
>>> the whole process. Result of 'find' ... used
>>> used for 'svn mergeinfo' graph.
>>>
>>> Source: Revision ranges X:Y[,X:Y...] Revision range 0:Y
>>> on branch URL@PEG on branch URL@PEG
>>>
>>> Target: optional non-WC tgt for 'find'
>>>
>>> If mergeinfo: skip already-merged revs (same)
>>> record the merge
>>>
>>> No mergeinfo: don't skip revs error out
>>> don't record
>>>
>>> Options differ: allow_mixed_rev allow_mixed_rev
>>> allow_local_mods
>>> allow_switched_subtrees
>>> ignore_mergeinfo
>>>
>>> At that level, it looks close enough to be feasible to embed
>>> 'automatic' merge inside 'pegged'. I'm looking closer now.
>>>
>>> Any thoughts?
> Branko Čibej wrote:
>> This is pretty much the same conclusion I came to earlier today. I looks
>> like the easiest thing to do would be to make the _automatic_ APIs
>> private within libsvn_client, move the selection logic to
>> svn_client_merge_pegX, and simplify the client implementation.
>>
>> The only trouble with that is, as you say, that "svn mergeinfo" relies
>> on having the automatic_find API available. I think this could be solved
>> in several ways:
>>
>> 1. by splitting the merge-peg into two, as the current automatic-merge; or,
>> 2. by making only the "do" phase of the automatic merge private, and
>> wile leaving the "find" phase public -- but renaming it to something
>> more in line with merginfo discovery; or,
>> 3. somehow exposing the "find" phase through one of the existing (or
>> revised) svn_client_mergeinfo_* APIs.
>>
>> I'm kind of leaning towards #3, but don't have a sense of how
>> complicated that would be.
> Mark Phippard wrote:
>> There are obviously some benefits for having less API, especially when
>> it comes time to rev it for something. That said, as a caller of the
>> API, it seems nice that the separate "automatic merge" API can provide
>> a more focused and simpler interface. For example, the interface does
>> not need to expose things like a revision range, which should not
>> apply when doing this kind of merge, but obviously is needed when
>> doing a cherry-pick merge.
>>
>> Looking through a long list of API is hard sometime, but it is also
>> hard when you want to do something like merge everything in BranchX
>> and the interface requires passing a bunch of parameters that do not
>> directly apply.
> I like the focused API, but I also see how the automatic merge can be considered to fill in a bit of missing functionality that merge_peg ought to provide.
>
> Perhaps we can have both. Teach merge_peg to DTRT in this case, and still have the focused API available for when a client knows it wants an automatic merge. Is there sufficient merit in that to outweigh the overhead of having to test two similar but different entry points?
>
> The attached patch moves the decision to call the 'automatic merge' API from 'svn' into 'svn_merge_peg5()'. I have run some merge tests and tree conflict tests, but not the whole test suite yet. Here is the log msg.
>
> [[[
> Teach svn_client_merge_peg5() to do an automatic merge, and let 'svn merge'
> rely on that instead of calling the dedicated automatic merge APIs.
>
> TODO: Decide whether to keep or make private the 'automatic merge' APIs.
> TODO: This reduces the verbosity of 'svn merge --verbose'. Consider
> doing something about it, perhaps by adding some new notifications for the
> notifier callback?
>
> * subversion/include/svn_client.h,
> subversion/libsvn_client/merge.c
> (svn_client_merge_peg5): Do an automatic merge if no revision range
> specified.
>
> * subversion/svn/merge-cmd.c
> (automatic_merge): Delete.
> (run_merge): Don't take special action to handle an automatic merge, let
> the pegged merge code path handle it.
> ]]]
>
> Thoughts?
I like it. Apparently the encapsulation is even simpler than I expected.
For JavaHL, a simple overload of ISVNClient.merge can provide the
"focused" interface without inventing yet another type of merge API.
Even better, passing null for the revision ranges in the existing
merge-peg overload can be made to yield the same effect, without
affecting the API signature at all. (Currently IIUC passing a null
ranges array will cause an error.)
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Julian Foad <ju...@btopenworld.com>.
Now with a patch for discussion.
(More below...)
Julian Foad wrote:
>> Brane told me that while updating the JavaHL API he noticed that the new
>> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
>> the existing JavaHL merge API encompass that functionality rather than add
>> yet another variant. So I said if let's see if we can apply that idea to the
>> libsvn_client API.
>>
>> Idea: 'automatic' merge is (in a high level logical sense) most similar to
>> a subset of the 'pegged' merge. So make 'merge_peg' do the automatic merge
>> (like calling the automatic merge API) if the params are suitable. The
>> intention is that this should be easier for Subversion client developers to
>> understand and for them to DTRT.
>>
>> API differences between pegged and automatic merge:
>>
>> Pegged merge Automatic merge
>>
>> The 'find'API: Single merge_peg call does Separate'find' and 'do'..
>> the whole process. Result of 'find' ... used
>> used for 'svn mergeinfo' graph.
>>
>> Source: Revision ranges X:Y[,X:Y...] Revision range 0:Y
>> on branch URL@PEG on branch URL@PEG
>>
>> Target: optional non-WC tgt for 'find'
>>
>> If mergeinfo: skip already-merged revs (same)
>> record the merge
>>
>> No mergeinfo: don't skip revs error out
>> don't record
>>
>> Options differ: allow_mixed_rev allow_mixed_rev
>> allow_local_mods
>> allow_switched_subtrees
>> ignore_mergeinfo
>>
>> At that level, it looks close enough to be feasible to embed
>> 'automatic' merge inside 'pegged'. I'm looking closer now.
>>
>> Any thoughts?
Branko Čibej wrote:
> This is pretty much the same conclusion I came to earlier today. I looks
> like the easiest thing to do would be to make the _automatic_ APIs
> private within libsvn_client, move the selection logic to
> svn_client_merge_pegX, and simplify the client implementation.
>
> The only trouble with that is, as you say, that "svn mergeinfo" relies
> on having the automatic_find API available. I think this could be solved
> in several ways:
>
> 1. by splitting the merge-peg into two, as the current automatic-merge; or,
> 2. by making only the "do" phase of the automatic merge private, and
> wile leaving the "find" phase public -- but renaming it to something
> more in line with merginfo discovery; or,
> 3. somehow exposing the "find" phase through one of the existing (or
> revised) svn_client_mergeinfo_* APIs.
>
> I'm kind of leaning towards #3, but don't have a sense of how
> complicated that would be.
Mark Phippard wrote:
> There are obviously some benefits for having less API, especially when
> it comes time to rev it for something. That said, as a caller of the
> API, it seems nice that the separate "automatic merge" API can provide
> a more focused and simpler interface. For example, the interface does
> not need to expose things like a revision range, which should not
> apply when doing this kind of merge, but obviously is needed when
> doing a cherry-pick merge.
>
> Looking through a long list of API is hard sometime, but it is also
> hard when you want to do something like merge everything in BranchX
> and the interface requires passing a bunch of parameters that do not
> directly apply.
I like the focused API, but I also see how the automatic merge can be considered to fill in a bit of missing functionality that merge_peg ought to provide.
Perhaps we can have both. Teach merge_peg to DTRT in this case, and still have the focused API available for when a client knows it wants an automatic merge. Is there sufficient merit in that to outweigh the overhead of having to test two similar but different entry points?
The attached patch moves the decision to call the 'automatic merge' API from 'svn' into 'svn_merge_peg5()'. I have run some merge tests and tree conflict tests, but not the whole test suite yet. Here is the log msg.
[[[
Teach svn_client_merge_peg5() to do an automatic merge, and let 'svn merge'
rely on that instead of calling the dedicated automatic merge APIs.
TODO: Decide whether to keep or make private the 'automatic merge' APIs.
TODO: This reduces the verbosity of 'svn merge --verbose'. Consider
doing something about it, perhaps by adding some new notifications for the
notifier callback?
* subversion/include/svn_client.h,
subversion/libsvn_client/merge.c
(svn_client_merge_peg5): Do an automatic merge if no revision range
specified.
* subversion/svn/merge-cmd.c
(automatic_merge): Delete.
(run_merge): Don't take special action to handle an automatic merge, let
the pegged merge code path handle it.
]]]
Thoughts?
- Julian
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 27, 2013 at 12:18 PM, Julian Foad
<ju...@btopenworld.com> wrote:
> Brane told me that while updating the JavaHL API he noticed that the new svn_client_merge_automatic() is Yet Another Merge API, and would prefer make the existing JavaHL merge API encompass that functionality rather than add yet another variant. So I said if let's see if we can apply that idea to the libsvn_client API.
>
>
> Idea: 'automatic' merge is (in a high level logical sense) most similar to a subset of the 'pegged' merge. So make 'merge_peg' do the automatic merge (like calling the automatic merge API) if the params are suitable. The intention is that this should be easier for Subversion client developers to understand and for them to DTRT.
>
> API differences between pegged and automatic merge:
>
> Pegged merge Automatic merge
>
> The 'find'API: Single merge_peg call does Separate'find' and 'do' calls.
> the whole process. Result of 'find' tells what we found,
> used for 'svn mergeinfo' graph.
>
> Source: revision ranges X:Y[,X:Y...] revision range 0:Y
> on branch URL@PEG on branch URL@PEG
>
> Target: optional non-WC tgt for 'find'
>
> If mergeinfo: skip already-merged revs (same)
> record the merge
>
> No mergeinfo: don't skip revs error out
> don't record
>
> Options differ: allow_mixed_rev allow_mixed_rev
> allow_local_mods
> allow_switched_subtrees
> ignore_mergeinfo
>
> At that level, it looks close enough to be feasible to embed 'automatic' merge inside 'pegged'. I'm looking closer now.
>
> Any thoughts?
There are obviously some benefits for having less API, especially when
it comes time to rev it for something. That said, as a caller of the
API, it seems nice that the separate "automatic merge" API can provide
a more focused and simpler interface. For example, the interface does
not need to expose things like a revision range, which should not
apply when doing this kind of merge, but obviously is needed when
doing a cherry-pick merge.
Looking through a long list of API is hard sometime, but it is also
hard when you want to do something like merge everything in BranchX
and the interface requires passing a bunch of parameters that do not
directly apply.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Fold the merge_automatic API into the existing merge_peg API
Posted by Branko Čibej <br...@wandisco.com>.
On 27.03.2013 17:18, Julian Foad wrote:
> Brane told me that while updating the JavaHL API he noticed that the new svn_client_merge_automatic() is Yet Another Merge API, and would prefer make the existing JavaHL merge API encompass that functionality rather than add yet another variant. So I said if let's see if we can apply that idea to the libsvn_client API.
>
>
> Idea: 'automatic' merge is (in a high level logical sense) most similar to a subset of the 'pegged' merge. So make 'merge_peg' do the automatic merge (like calling the automatic merge API) if the params are suitable. The intention is that this should be easier for Subversion client developers to understand and for them to DTRT.
>
> API differences between pegged and automatic merge:
>
> Pegged merge Automatic merge
>
> The 'find'API: Single merge_peg call does Separate'find' and 'do' calls.
> the whole process. Result of 'find' tells what we found,
> used for 'svn mergeinfo' graph.
>
> Source: revision ranges X:Y[,X:Y...] revision range 0:Y
> on branch URL@PEG on branch URL@PEG
>
> Target: optional non-WC tgt for 'find'
>
> If mergeinfo: skip already-merged revs (same)
> record the merge
>
> No mergeinfo: don't skip revs error out
> don't record
>
> Options differ: allow_mixed_rev allow_mixed_rev
> allow_local_mods
> allow_switched_subtrees
> ignore_mergeinfo
>
> At that level, it looks close enough to be feasible to embed 'automatic' merge inside 'pegged'. I'm looking closer now.
>
> Any thoughts?
This is pretty much the same conclusion I came to earlier today. I looks
like the easiest thing to do would be to make the _automatic_ APIs
private within libsvn_client, move the selection logic to
svn_client_merge_pegX, and simplify the client implementation.
The only trouble with that is, as you say, that "svn mergeinfo" relies
on having the automatic_find API available. I think this could be solved
in several ways:
1. by splitting the merge-peg into two, as the current automatic-merge; or,
2. by making only the "do" phase of the automatic merge private, and
wile leaving the "find" phase public -- but renaming it to something
more in line with merginfo discovery; or,
3. somehow exposing the "find" phase through one of the existing (or
revised) svn_client_mergeinfo_* APIs.
I'm kind of leaning towards #3, but don't have a sense of how
complicated that would be.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com