Re: Lost History of a file by just changing it and committing

Mark Phippard wrote:

> No. The Replacing means that an svn delete and svn add were done locally
> prior to the commit. Severing the history.

Ok, this explains why the history is not present any more.

> You do not say how you put the new JAR into place.

Via drag'n'drop drop from a directory displayed in Nautilus (Gnome file
manager). I did not change this behaviour over the last approx. 10
library releases.

> This was a bug in Eclipse 2.x. When you dragged and dropped a file into
> the workspace from your file system, Eclipse would fire the MoveDeleteHook
> causing the original file to be processed as a delete. This was fixed in
> Eclipse 3.x, maybe they have a regression?

I am using Eclipse 3.1 + WTP 0.7, and did not change that setup for
about 2 months (since the release of WTP).

>> But now the file is still marked as changed/dirty,
>
> It is not likely to be a Subclipse/Subversion bug.

This part of the issue is still unclear. Even if Subclipse is doing a
replace instead of a "content modification", the file should not be
marked as dirty afterwards? How could that happen?

Regards,

Andreas
Received on Sat Sep 24 00:36:53 2005