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

Re: Problem with JavaHL merge in latest trunk

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2007-08-24 00:44:54 CEST

On Aug 22, 2007, at 7:21 PM, Mark Phippard wrote:

> On 8/22/07, Daniel Rall <dlr@finemaltcoding.com> wrote:
>>
>> On Aug 22, 2007, at 8:07 AM, Mark Phippard wrote:
>>
>>> In the merge client I am doing, we have an option to merge "All
>>> eligible revisions" which is essentially svn merge -g". There is
>>> not
>>> specific merge signature in JavaHL for doing this. Dan told us to
>>> pass null's for the start and end revision to get this kind of
>>> merge,
>>> and that has always worked.
>>>
>>> We recently updated the JavaHL binaries and noticed we now get this
>>> error message:
>>>
>>> Bogus revision information given
>>>
>>> I looked in the code and it looks like it comes from this in
>>> merge.c:line 2098
>>>
>>> ENSURE_VALID_REVISION_KINDS(initial_revision1->kind,
>>> initial_revision2->kind);
>>>
>>> According to blame, this line of code was added here:
>>>
>>> --------------
>>> cmpilato 25933 Aug 2, 2007 1:42 PM
>>>
>>> Teach svn_client_merge_peg3() to transform its peg-rev-using input
>>> into fixed locations so that the helper functions it shares with
>>> svn_client_merge3() (which doesn't do peg-rev-ish stuff) don't all
>>> have to manage two different input formats. This (almost
>>> incredibly)
>>> passes 'make check', reduces logical complexity, provides a net loss
>>> of 130 lines of code, and (best of all) seems, I think, to actually
>>> correct some theoretical problems in the merge implementation.
>>> ---------------
>>>
>>> What does the -g option do when it is used from the command line?
>>> Should we just pass 0:HEAD for the revisions? It seems like there a
>>> number of possible ways to approach this so I am throwing it to the
>>> list.
>>
>> It looks like the command-line passes svn_opt_revision_unspecified.
>> I suggested trying the same from Java using new Revision
>> (RevisionKind.unspecified). Mark is going to try this out.
>
> This appears to result in the same error.
>
> This appears to be the method we wind up using in this scenario. I
> cannot remember why we used this one instead of the newer one.
>
> /**
> * Merge changes from two paths into a new local path.
> * @param path path or url
> * @param pegRevision revision to interpret path
> * @param revision1 first revision
> * @param revision2 second revision
> * @param localPath target local path
> * @param force overwrite local changes
> * @param recurse traverse into subdirectories
> * @param ignoreAncestry ignore if files are not related
> * @param dryRun do not change anything
> * @throws ClientException
> * @since 1.2
> */
> void merge(String path, Revision pegRevision, Revision revision1,
> Revision revision2, String localPath, boolean force,
> boolean recurse, boolean ignoreAncestry, boolean
> dryRun)
> throws ClientException;

I've added an XFAIL'ing JavaHL test for this in r26277.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 24 00:35:28 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.