Philip Martin <philip@codematters.co.uk> wrote on 06/14/2005 07:30:43 PM:
> pburba@tigris.org writes:
>
> > Author: pburba
> > Date: Fri Jun 10 14:35:27 2005
> > New Revision: 15023
> >
> > Modified:
> > branches/ebcdic/trunk/subversion/svnlook/main.c
> >
> > Log:
> > Fix bug preventing svnlook against a transaction.
> >
> > * subversion/svnlook/main.c
> > (get_ctxt_baton): Convert opt_state->txn to utf8 before storing in
baton.
> >
> > Modified: branches/ebcdic/trunk/subversion/svnlook/main.c
> > Url: http://svn.collab.
> net/viewcvs/svn/branches/ebcdic/trunk/subversion/svnlook/main.c?
> rev=15023&p1=branches/ebcdic/trunk/subversion/svnlook/main.
> c&p2=branches/ebcdic/trunk/subversion/svnlook/main.c&r1=15022&r2=15023
> >
>
==============================================================================
> > --- branches/ebcdic/trunk/subversion/svnlook/main.c (original)
> > +++ branches/ebcdic/trunk/subversion/svnlook/main.c Fri Jun 10
> 14:35:27 2005
> > @@ -1722,7 +1722,11 @@
> > baton->full_paths = opt_state->full_paths;
> > baton->is_revision = opt_state->txn ? FALSE : TRUE;
> > baton->rev_id = opt_state->rev;
> > +#if !APR_CHARSET_EBCDIC
> > baton->txn_name = apr_pstrdup (pool, opt_state->txn);
> > +#else
> > + SVN_ERR (svn_utf_cstring_to_utf8 (&baton->txn_name,
> opt_state->txn, pool));
> > +#endif
> > if (baton->txn_name)
> > SVN_ERR (svn_fs_open_txn (&(baton->txn), baton->fs,
> > baton->txn_name, pool));
>
> That's a bug on the trunk isn't it? The txn from the program's
> argument list is getting passed to svn_fs_open_txn and yet it has
> native encoding, not UTF-8.
>
Hi Philip,
I'm not sure it's really a bug:
(pardon me for spelling this out so simplistically, I assure you it's for
my own benefit :-)
Looking at create_txn_dir in fs_fs.c, transaction directories always have
this format:
"<txndir>/<rev>-<uniquifier>.txn" where <uniquifier> is some number
between 1 and 99999 inclusive.
When specifying a target transaction on the command line, only the
"<rev>-<uniquifier>" portion is used. On non-ebcdic platforms this
string, even when natively encoded, is always* a subset of utf-8, so no
conversion is required. Only on an ebcdic platform is this ever* going to
be an issue. As a side note, most of the work we've done on the ebcdic
port is dealing with this type of "ascii assumption".
*OK, that's a bit absolutist, there might be something out there that
encodes '0' - '9' and '-' as something other than '\x30' - '\x39' and
'\x2D', but one port at a time.
>
> It should probably be converted in main().
>
You're right, looking at main, I see other command line arguments are
converted from native encoding to utf-8, so this conversion rightly
belongs there too. I had no compelling reason to make it in
get_ctxt_baton...I'll fix that.
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 15 21:13:51 2005