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

Re: Feature request:: Unversioning files (svn rm --keep-in-wc)

From: <kfogel_at_collab.net>
Date: 2005-09-23 20:56:39 CEST

David James <james82@gmail.com> writes:
> How does Perforce do it, then? If my WC says that I own a file named
> "subpoena_details.txt" which was created in rev 34, but my repo says
> that "subpoena_details.txt" doesn't exist at any revision, I think
> it's safe to assume that "subpoena_details.txt" has been obliterated.

Well, I can't answer that question until I know exactly what Perforce
does.

First, in Perforce, working copy state lives on the server, right?
Which means if the server gets subpoena'd, you're out of luck :-).

But leaving that question aside, it may be that Perforce working
copies simply choose to treat this situation as a non-error:

   The working copy contains a versioned file, claiming to be at a
   certain revision from a certain repository, but that repository
   denies that such a file exists at that revision and path.

Subversion working copies could also choose to treat this as a
non-error, but then certain classes of genuine errors become
undetectable. For a trivial example: if I were to edit my .svn
entries file to claim that a file is under version control when it
really isn't, today we can -- correctly -- detect that as corruption,
but with the proposed change, we could not.

Is what I am saying clearer now?

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 22:03:48 2005

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

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