svnlgo@mobsol.be wrote on 09/19/2006 10:02:58 AM:
> > I'd say right now there are no plans or timeline for doing that. It
> > doesn't mean it will not happen, but it will not happen soon. This is
> > partly dependent on what JavaSVN does. Once they have 1.4 support and
we
> > have it rolled into our 1.1.x releases we will likely eventually
backport
> > some of the changes and do a new 1.0.x release and that would then
likely
> > get 1.4 too.
>
> Thanks for the info Mark.
>
> You are aware that this effectively links the release plans of Eclipse
and
> Subversion together? If we want to upgrade Subversion to 1.4, we have to
> upgrade Eclipse to 3.2, if we want to upgrade Eclipse to 3.2, we have to
> upgrade Subversion to 1.4. JavaSVN is by design following new Subversion
> upgrades by atleast a month, further complicating the matter (as you
indicate).
We are just doing the best we can with the resources we have. The problem
is that this Subversion 1.4 working copy change cuts both ways. If I put
out a new release a lot of people are going to get it via automatic
updates. That process does not notify them of the working copy change and
they may have reasons to not want that, or at least not be surprised by
it. And JavaSVN not supporting 1.4 complicates this even further. It is
all just a big mess that I do not need.
On Linux and OS X, the binaries are not provided by us anyway, so users
are free to install the version they want. On Windows, getting the 1.4
binaries is very easy to do for someone that wants them.
I will definitely not do a 1.4 release for 1.0.x without JavaSVN.
> At home I always use the latest version of both, including milestone
releases,
> but at work we're definitely not capable to follow such an upgrade plan.
>
> Subversion 1.5 will most likely change in the working copy format again,
which
> means we'll have to go through the same upgrade 'nightmare' again.
Perhaps, although 1.0 - 1.3 all had the same format.
> > To roll your own 1.0.x distribution I would recommend installing the
> > Subversion binaries and adding the bin folder to your PATH. The
JavaHL
> > DLL is also available for download so you would just get that and copy
it
> > to the bin folder.
> >
> > Then just delete all of the DLL's in the JavaHL plugin folder. Then
when
> > you start Eclipse it will find them in your PATH.
>
> Just wondering, why this recommendation? We host an update site
internally so my
> current plan was to create a new unofficial 1.0.4 release with all the
dll's and
> javahl jar upgraded.
Because how many people do you think do what you are doing? If you are
setup to do that, then by all means do so. All you need to update is that
Win32 fragment.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Sep 19 16:09:01 2006