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

Re: Porting Subversion to EBCDIC

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-02-12 17:03:50 CET

> In that case, perhaps /branches/ebcdic/* and /tags/ebcdic/* make the most
> sense?

That is basically what I originally suggested. It would wind up looking
like this:



At some point the bulk of the ebcdic code might make its way to trunk, and
then maybe we would need to make branches labelled "os400" for the
specifics of that port. I think there are some elements of the port that
might not ever make sense on trunk. For example, there are a couple of APR
functions that IBM changed the signature of or doesn't fully support, and
then there is the whole mod_dav_svn area, where I think IBM is doing a lot
of stuff that is more specific to what they did with Apache on OS/400 than
to EBCDIC. For example, they convert all of the incoming headers to
EBCDIC, and if it contains UTF-8 they have some bizarre conversion/escaping
they do to represent it in EBCDIC. In my opinion, there is no reason they
couldn't have just left this information in UTF-8 and only converted to
EBCDIC when dealing with CGI programs. However, there is nothing we can do
about this.

For now, as long as there is an ebcdic branch, we can just condition that
code approriately in the branch, but if the branch code moves to trunk and
this code doesn't, we could start a new set of branches for OS/400 that
contains just that code. Anyway, we can make those decisions when you see
the code. You guys will probably think of ways we can better isolate these
issues anyway.



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 Sat Feb 12 17:05:16 2005

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.