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

Problem with JavaHL merge in latest trunk

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-08-22 17:07:29 CEST

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 22 17:05:07 2007

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