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

Re: OS deletes and repo commits

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: 2006-11-15 13:25:45 CET

On Wednesday 15 November 2006 12:22, Alan McDonald wrote:
> When a user deletes a file via the operating system file delete, the svn
> database is not informed of this deletion. If the user uses the
> TortoiseSVN|Delete option, the svn database IS synch'd with this deletion.

Nope. The file is removed from the working copy and the WC's metadata file the
file for deletion. The delete operation inside the SVN database (or, in
svn-speak, inside the repository) only happens once you commit.

> Is there a way for a user to update their svn database (of their working
> copy) of the state of the files in their file system with their working
> copy without doing a commit or update?

Wait: "update the svn database" means writing to it which only happens in a
commit (or a server-side operation, but let's leave those out for now). Now,
the question then boils down to "Is there a way to commit without doing a
commit?" which obviously makes no sense.

I think instead of the database/repository you mean the metadata of the
workingcopy. You question the is if there is a way to mark the file for
deletion just from the fact that it has already vanished from the
workingcopy.

There isn't really a way for that. However, there is a feature in TSVN that
when you commit a folder, it offers all missing file, too. From that dialog,
you can directly file the already missing file for deletion.

> I have a particular issue with people swapping between detailed view and
> thumbnail view in their file system. It seems that this process deletes
> thumbnails (when switching to details) and if they do not commit these
> deletions before switching back and re-creating the thumbs.db files, there
> is an annoying error in trying to add a file to the repo which already
> exists. My auto update then commit script does not bring the repo version
> othe thumbs.db file back to the working copy because the working copy
> database thinks it's already present, when it's not, but DOES think that
> the newly created thumbs.db file is a new addition instead of an update of
> an existing file. I thought at first it was a case problem but the OS
> (WinXP) always uses teh same case Thumbs.db for the file.

Don't version those files, as others already said. You can even tell
Subversion that it should always ignore these files and disallow them even
stronger via a pre-commit hook.

Uli

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************

Diese E-Mail und jede mit dieser E-Mail versandte Datei ist vertraulich und ausschließlich für die Nutzung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger dieser E-Mail sein, informieren Sie bitte den Absender. Jeder unbefugte Zugriff oder unbefugte Weiterleitung, die Fertigung einer Kopie oder sonstige in diesem Zusammenhang stehende Handlung ist untersagt.

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please be so kind to inform the sender. Any other unauthorised access, unauthorised forwarding, copying or other action in this connection at all, is prohibited.
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 13:27:17 2006

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

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