> Hmm. Maybe we need to start over then.
> This is your first and only install of Subclipse?
No, I used previous versions of Subclipse before. I had been using
1.1.6 and 1.1.7 and then upgraded to 1.1.8 through the update site.
After that, the error came up. I deactivated the Subclipse plugin and
tried to reinstall it using the update site, but due to some Eclipse
bug, I wasn't able to. So I deleted my Eclipse install (which was
3.2.1, upgraded from a previous install of 3.2) and redownloaded
Eclipse. I also moved my workplace and had Eclipse initialize a new
one. Then I installed Subclipse 1.1.8 through the update site, which
worked fine that time.
I then imported my projects using the Eclipse import wizard from my
old workplace. Upon committing, the error showed up again, so I
checked the Subclipse configuration and noticed that it was
complaining about missing JavaHL binaries. I switched to JavaSVN, but
the error did not go away. I guess Subclipse was using JavaSVN as a
As I wrote earlier this problem only seems to come up with legacy
projects. Newly created or checked out projects work fine.
> Are you using any other Subversion clients, such as the command
> line? If
> so, please state the clients used and their versions.
I don't, but I do have the svn command line client installed. I
upgraded it to the latest 1.4 release yesterday. I haven't used the
command line client at all though. I thought Subclipse may need it,
but now realize that with JavaSVN, this is not the case.
> These projects with problems, how were they checked out? Which
The projects where created using Subclipse 1.1.6 and 1.1.7. They were
not actually checked out - I created empty repositories on the server
and then shared my Eclipse projects using Team -> Share project.
> The original problem you described would be what would happen if
> used a
> Subversion 1.4 client of some sort (which would give the WC the new
> format) and then tried to access it via JavaSVN from Subclipse
I didn't do that. After upgrading to 1.1.8, I did not revert to a
previous release. I only reinstalled 1.1.8.
> If you are only using Subclipse, then it sounds like there has to
> be some
> kind of JavaSVN bug present.
I know you don't like this, but as I said my problem seems to
resemble what Jerry described. Now I don't know much about subversion
and it's meta information, but it seems that maybe Subclipse isn't
updating the present .svn files for me. If you want, I can send you
some sample .svn files to have a look at.
If there's anything you need me to do so that we can nail this
problem down, I'm happy to do it. It's the least I can do. I think
you guys are providing a great service here, I wouldn't have expected
to get so much help and friendliness. Thanks again for that.
>> I'm using svn+ssh:// on a Linux server.
> That could still have the problem. I think the problem should be
> reasonably repeatable with different clients. As I understand it, the
> problem is that on certain versions if Linux the device /dev/random
> is used to get a random number depends on some sort of entropy,
> such as
> hardware interrupts from keyboard/mouse activity. If you are on a
> headless server, you do not have any entropy and random number
> is slow. The alternative is to use /dev/urandom which generates
> numbers using a different technique that is not "cryptographically
> random". For SVN needs, this is fine. To fix the problem you have to
> ./configure APR to use it and then rebuild APR. The Subversion users@
> archives would have a lot of messages related to this. Search for
> "urandom" and "entropy" for messages.
Hmm. I'll look into this once my projects commit fine again, but am I
wrong in assuming that for svn+ssh, I don't even need Apache, and
thus, I don't need APR? As I understand it, APR is only being used by
subversion when accessing it through Apache?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Nov 11 19:56:29 2006