sun has an issue about a java deltav client library (submitted by rational). public review is
beginning of december.
http://www.jcp.org/en/jsr/detail?id=147
here they state "api calls provide a single workspace interface" whether you access the server, or
the client (working copy).
personally i still prefer a working copy beeing a standard repository, which can be replicated or
cloned or populated with some "subdata" from the main repository (instead of the .svn nightmare).
this would solve replication, proxy, distribution, more complex scenarios of
rollout/freeze/propagation in a more flexible way, and would be terrible on networked storage (no
support for db on nfs, e.g.) ;)
--- Steve Dwire <sdwire@pcsigroup.com> wrote:
> Couple of points here...
>
> 1) If we're only interested in retrieving the latest version of data
> from a subversion repository, we DON'T EVEN NEED A SUBVERSION CLIENT AT
> ALL. All we need is a simple http client, as long as we limit ourselves
> to one protocol, and the protocol we choose is http/WebDAV. Just use
> Java's existing http classes. (but see my conclusion below for a partial
> retraction...)
>
> 2) If we're interested in synchronizing the repository with our working
> copy, then there's a LOT of client-side work to be done. With a JDBC
> driver, its sole purpose is to retrieve data or affect server-side
> changes, with a Java-based client API. Because the Java API is part of
> the problem definition, it makes perfect sense for a native Java driver
> to replace a JNI wrapper. With SVN, the end goal on the client side is
> not access via Java API, but synchronization of a file-system-based
> physical working copy using a (reasonably) stable set of rules.
>
> The question is not only, "What's the best way for Java programs to
> access Subversion?" If that were the only question to answer, then
> certainly a native Java library is the best answer. In this case,
> there's another related question -- "In what language should all of the
> file-system manipulation for the working copy be implemented?"
>
> I see only three possible categories of answers:
>
> 1) Java - but this makes the API available ONLY to Java developers
> 2) Non-Java (current) - Java developers must use JNI
> 3) Both - I hate to imagine the headaches trying to match the two
> implementations quirk-for-quirk. Eventually one of them will outpace the
> other, and we'd have a segmented community like CVS vs. CVSNT.
>
> (My personal) conclusion:
>
> There may be some significant value in developing a native Java
> READ-ONLY client API to support the svn: protocol, and that may very
> well be an interesting and worthwhile addition (or separate but related
> project). I think we'd be asking for problems, though, if we were to
> begin a native Java implementation of the full Subversion client API to
> be maintained in parallel with the C-based one.
>
> S_E_D
>
>
> -----Original Message-----
> From: treaves@silverfields.com [mailto:treaves@silverfields.com]
> Sent: Wednesday, October 22, 2003 8:54 AM
> To: dev@subversion.tigris.org
> Subject: Re: Developing Java Client?
>
> I wouldn't just listen to the people that have responded so far saying
> that perhaps you should reconsider. The current Java API's that rely on
> JNI are bad - as compared to what a native Java version would be.
> Period.
> Let the self-righteous rebuttal start!
>
> There are so many problems with any JNI version of anything that it
> aught
> to be self-evident. But apparently it is not. So let me ask: how well
> is that JNI Java port going to work on my handheld using a J2ME JVM? It
> won't. Where as I will grant that not too many people will be
> interested
> in accessing a Subversion repository on their cell phone or Palm, there
> will be times when it would be handy.
>
> There were similar questions asked when the native JDBC drivers where
> written for just about any database you care to mention: 'We already
> have
> CLI versions, why not simply use them and make JNI interfaces?' IBM did
> this with DB2, and it was a disaster. They finally have come out with
> native drivers.
>
> And what about new platforms? The Subversion code should compile with
> little modification on just about any platform, but not really. It
> takes
> time to port and test. With native Java drivers, as long as there is a
> JVM, it'll run.
>
> There is nothing wrong with using JNI, where JNI is the only option.
> Some
> of the new stuff in JDK 1.4 with the NIO even makes it better. But a
> native Java version will always be faster, easier to debug, and in the
> long run, easier to maintain. Look at PostgreSQL. There native JDBC
> drivers are some of the best around, and are no longer second class to
> the
> CLI stuff.
>
> So if someone really wants to write a native Java version, we should all
> support that, and help out. In the long run it WILL happen, and it WILL
> supplant the JNI version. Don't believe me? Point to one JNI interface
> that still survives after the introduction of a native interface.
>
>
>
>
> > OK OK ... you convinced me ... I wont do it. *surrenders* It was only
> an
> > idea. *shrug*
> >
> > In fact the general hostile reactions I have been getting on this list
> > to even suggestions doesn't make me want to contribute at all..
> >
> > Best of luck.
> >
> > -- Kraythe
> >
> >
> > "Ben Collins-Sussman" <sussman@collab.net> wrote in message
> > news:m34qy22mj7.fsf@kepler.ch.collab.net...
> >> "Robert Simmons" <derisor@arcor.de> writes:
> >>
> >> > Yes but where is the design and architecture documentation? ;-) Im
> >> not terribly confidently expecting it to exist but it would be
> >> convenient. Reading code to figure out architecture is very slow and
> >> tedious and most people simply wont bother. If it comes down to
> >> having no hints other than the code base, I may not bother. I want
> >> to write a library, not learn to write C all over again.
> >>
> >> Read the entire Subversion book, especially chapter 7. That explains
> >> a lot of architecture. There's also a very old, very general design
> >> document sitting here, which gives a good overview:
> >>
> >>
> http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=259
> >>
> >> By the way, there is no "one protocol" for Subversion. The access to
> >> the repository is an abstract API, so anyone is free to write a
> custom
> >> protocol. At the moment, we have a stateful custom protocol which
> >> talks to an 'svnserve' server, and a WebDAV/DeltaV variant protocol
> >> that speaks to an Apache server. And and there's a 'no-network'
> >> protocol for accessing a repository directly. Which will you
> >> reimplement in pure Java? All of them?
> >>
> --snip--
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 12:23:00 2003