*Caveat:* I have just registered to the mailing list, being motivated by
a strange error using Subversion. I have reviewed the list archive and
the bug tracker and have not found anything relating to this. Apologies
if this has already been covered.
*Symptom:* I have a project that I develop using Eclipse, equipped with
Subclipse and JavaSVN. I also use the command line tool to perform some
operation on the local copy. I was working away on a file, submitting
regular checkins as work progressed. During this work, the file was
structured correctly, since it was compiled regularly and succesful
tests were passing. After a while, I had problem with Subclipse and
Subversion. It appeared that something was wrong with the local copy.
Since I had checked in everything, I simply deleted the local copy and
checked out a fresh one again. I found out that some of the files had
been corrupted for a number of revisions in the repository. Those files
were correct at time of check in but going back a number of revisions,
it appears that the diffs were applied at the wrong place. As diffs were
applied wrongly in successive versions, the file grew more and more
mangled to the point where it is quite indecipherable.
*Assumption:* I am assuming that the local copy of the latest version
was corrupt, and that SVN or JavaSVN were sending diffs against a bad
working copy. I am concluding that it is probably not a problem with
Subclipse, but since I used both SVN and Subclipse, I can not pin point
which one of the two tools is the culprit. Hence, difficulty in raising
a bug report.
*Questions:*
1. Is it common practice to use both SVN and JavaSVN on a local copy?
Should it be avoided or is it acceptable?
2. Is this a problem that has been encountered before? If so, what
component is responsible for it?
3. Are there practices that have been developed to side step such issues?
*Environment:*
- Linux 2.6.9
- Subversion 1.1.3
- Eclipse 3.1.0
- Subclipse 0.9.27
- JavaSVN (not sure of version)
Thanks,
JP
Received on Thu Apr 14 02:57:02 2005