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

RE: Files deleted from local working copy on update don't go to recycle bin?

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Mon, 7 Oct 2013 21:53:37 +0000

> Here's the scenario:
> Someone deletes a file from the repository by accident, and then commits.
> I happen to be working on the file in question in my working copy. I update my
> working copy in preparation to commit, and the file that was deleted from the
> repository also gets removed from my working copy .... apparently along with
> my work, which seems to be now lost.
> I would expect that file to get marked as conflicted, or at the very least, be
> moved to the recycle bin, but it seems that Tortoise (or the underlying
> subversion client?) simply zaps the file in to oblivion.
> Is this a bug? is this the intended behavior? (hope not!)

The definitely should be a tree conflict... local changes, incoming delete.

Yes, it certainly is. I just tested it... I get a tree conflict on the file.

If I edit the conflict.

However, an perhaps this is what you did. If I "accept the working copy state" it is put in as an add of the file. However, if I "revert" at that point, the file is removed.

This does seem wrong to me. I would expect the same as if I just revert an added file.

However, it does show a conflict when the update is a delete and the local file is edited. Perhaps you did a revert after keeping local file as resolved?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-07 23:53:43 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.