[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Andreas Schildbach <andreas_at_schildbach.de>
Date: 2005-09-23 16:36:53 CEST

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?


Received on Sat Sep 24 00:36:53 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.