On Wed, 26 Oct 2005, Mark Phippard wrote:
> Daniel Rall <dlr@finemaltcoding.com> wrote on 10/26/2005 01:52:28 PM:
>
> > On Mon, 24 Oct 2005, Mark Phippard wrote:
> >
> > > Marc Sherman <msherman@projectile.ca> wrote on 10/24/2005 03:51:01 PM:
> > ...
> > > > One more thing: Since recent versions of Subclipse have been tied to
>
> > > > specific versions of Subversion, I'd like to suggest that you
> consider
> > > > changing your version numbering to be based on the subversion
> version
> > > > you're linked against. It would make the relationship between
> versions
> > > > clearer.
> > >
> > > The problem is how do we do this without passing ourselves off as a
> "1.3"
> > > version?
> >
> > Indeed. The best we can do is clearly document what versions of
> Subversion
> > have been tested against, and have the software refuse to start against
> > versions of Subversion known _not_ to work.
>
> We can't really refuse to start because we have JavaSVN which will always
> work in some manner.
Sure. I was referring to JavaHL and the command-line, per comments about
testing being done against certain versions of Subversion.
JavaSVN might not always be available, but more importantly, it also might
not always work. Examples: no ra_local, WC format changes it doesn't
understand (JavaSVN 0.9.2 against a SVN 1.3 WC will produce this), etc.
> What I did in the most recent release is I added some intelligence to the
> loading of the JavaHL adapter to make sure I have a library with the valid
> version. Ideally, JavaHL would have a method added to return its version.
...
I like this suggestion. Can you send a patch to the Java portion of JavaHL
over on dev@subversion, and I'll see what needs to be done to the JNI gunk?
Received on Thu Oct 27 06:54:44 2005