Daniel Rall <email@example.com> wrote on 10/26/2005 01:52:28 PM:
> On Mon, 24 Oct 2005, Mark Phippard wrote:
> > Marc Sherman <firstname.lastname@example.org> 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
> > > changing your version numbering to be based on the subversion
> > > you're linked against. It would make the relationship between
> > > clearer.
> > The problem is how do we do this without passing ourselves off as a
> > version?
> Indeed. The best we can do is clearly document what versions of
> 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.
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.
Anyway, if I load a pre JavaHL 1.2 library then the JavaHL adapter is not
available which causes Subclipse to switch to JavaSVN.
I intend to do the same thing with 1.3. I will probably call the new
method to get the Admin directory and if it tosses an exception not allow
the adapter to be available.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Thu Oct 27 04:03:47 2005