[bug] backwards compatibility APIs in 1.2 aren't really

In 1.2, a bunch of the APIs adopted a peg_revision argument and the
implementations of the backwards-compatibility code for the 1.1. APIs
just call the new versions like so:

svn_client_cat( stream, path, revision, context, pool )
{
     return svn_client_cat2( stream, path, revision, revision,
context, pool );
}

[It is not possible to produce a script with the 1.2 client that will
reproduce the error since this is at the API level so I'll just list
the appropriate pseudo-steps.]

1. create a repository
2. Add a file to trunk, let's call it test.c (r1)
3. Create a branch in branches/broken (r2)
4. Modify test.c in the branch (r3)
5. Set up and call to svn_client_cat() like so:
     svn_opt_revision rev = { svn_opt_revision_number, { 1 } };
     svn_client_cat( stream, ./test.c, &rev, ctx, pool )

You'll get an error like:

svn: File not found: revision 1, path '/branches/broken/test.c'

What you need to pass in the compatibility wrapper is
svn_opt_unspecified for the peg_revision argument to svn_client_cat2().

Note that you can reproduce the behavior by doing:

svn cat -r 1 test.c@1

but in this case, that is the correct behavior since that's what you
explicitly told it. However, it mimics what "svn cat -r 1 test.c"
would do if it were calling the svn_client_cat() function, not
svn_client_cat2().

In addition, the 1.2 svn log *command* appears to have this bug too.

svn log -r 1 test.c

svn: File not found: revision 1, path '/branches/broken/test.c'

If you do, "svn log -r 1:BASE test.c" then it works.

Per the issue tracker guidelines, I'm posting this here first but
it's pretty clear that it's a bug. :-)

stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 18:24:59 2005