Ben,
Thanks for the response. This answers one of my questions. If you
have any other input on the other questions, I would love to hear it.
In addition, I have a new question:
.svn\text-base directory seems to have a replica of the files that are
being version controlled. This means an overhead of at least 2X on
the file system.
I'm not sure I understand why this replica exists. I am curious if we
can tweak the code to remove this need so we don't have to pay the 2X
overhead on an embedded filesystem -- and still allow subversion to do
the majority of its job. What features would we be limiting ourselves
to if we took this path?
Thanks,
Davis
On Fri, 25 Feb 2005 12:30:18 -0600, Ben Collins-Sussman
<sussman@collab.net> wrote:
>
> On Feb 25, 2005, at 11:48 AM, Davis Ford wrote:
>
> > a) How portable is the SVN command line client code to other
> > architectures (e.g. PPC, ARM)?
> >
>
> All of Subversion's portability comes from APR, the Apache Portable
> Runtime library. If APR builds an an OS, then Subversion will work
> there (as well as apache httpd!)
>
> Last I heard, APR runs on QNX and WinCE. Don't know about other
> embedded OSes. You'd have to ask on dev@apr.apache.org.
>
> My recommendation is that you would want to access the server via
> svn://, since that's a protocol which is "built in" to the core SVN
> libraries, and uses APR network api. If you wanted to access via
> http://, then you'd have an extra dependency: the neon library, which
> provides HTTP client functionality to the svn. Neon may not be as
> portable as APR.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 25 20:18:20 2005