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

Re: Bug: deleting a non-version-controlled copy deletes a version-controlled copy

From: Arp Laht <arp.laht_at_id-balti.ee>
Date: Wed, 11 Aug 2010 10:41:53 +0300


Thanks for the tip! Eclipse is indeed involved, and if you know
of such things occurring with Eclipse, then this must be it!

It didn't occur to me that a build script could possibly go
and merrily copy over a hidden folder, but it's something I've not excluded.

Just to be sure, I'll check if what is occurring truly is what you describe,
and presuming it's so, many thanks for suggesting a solution. :)

Best regards,

Kurt Pruenner wrote:
> On 10.08.10 13:51, Arp Laht wrote:
>> If a build script has introduced copies of ".java" files from "src"
>> into the "build" directory tree (e.g. "Main.java" has got copied from
>> "src/mobile/Main.java" to "build/mobile/Main.java") then, if I examine
>> the "build" directory's content with a TortoiseSVN-enabled instance
>> of Windows Explorer, the following can be seen:
>> 1) TortoiseSVN shows these files in the "build" directory,
>> (of which another copy in the "src" directory really is version-controlled)
>> to be likewise version-controlled. It displays them with a green "in sync"
>> icon, and offers a context menu with SVN operation for them.
>> 2) If I should mistakenly use the TortoiseSVN "Delete" command
>> on such a file, what gets actually deleted from the repository server,
>> is the corresponding file from the "src" directory, which definitely
>> should not happen.
> You wouldn't happen to be using Eclipse or some other Java IDE that
> randomly copies stuff from your source tree to your build directory?
> Because if it copies the hidden .svn folders that store the metadata for
> a versioned folder from src to build you need to prevent it from doing
> that...
> With Eclipse you'd have to either define an exception rule somewhere or
> (probably easier) install a SVN client add-on for Eclipse (like
> subclipse), as that of course also has to prevent the build process from
> mucking with the .svn folders - search the list archives for more
> discussion of this problem.
> Long story short: No, it's not a bug (in (T)SVN, anyway), but it'll go
> away in 1.7 anyway when subversion moves from an .svn folder in each
> versioned directory to a single metadata folder in the working copy root.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-08-11 09:43:35 CEST

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

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