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

Sorry I haven't been paying attention to this thread, but I was (am?) a
Perforce guru for a few years.

When you obliterate a file in Perforce, it does, in fact, do a really
good job of getting rid of all traces. It doesn't even make any log
entries that anything was obliterated. It truly is a massively
destructive operation, which I never used. Philosophically, my job as an
SCM guy is to save history, not destroy it.

When a file is obliterated, any working copies basically become flat,
unversioned files. As if you've put a new file in your work area but
haven't added it to the database yet.

Perforce working copies, technically, don't treat anything as anything.
The big fundamental difference between Perforce and SVN, as alluded to
below, is that everything is server side. You client has no real
intrinsic knowledge about the state of things on the server. As an
example, if you sync files in perforce to a folder then use a shell
command to delete it, the whole system gets rather confused. The server
thinks you still have the files, even though they are gone locally. The
'client' has no clue what's happened because it doesn't keep that kind
of info around. In fact, as far as I know, any sync of Perforce files
does not pull over any extra files or information, you only get the
source code (or whatever) itself.

Keeping all this in mind:

"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."

The working copy is not smart and has no idea what's going on. The
server knows that it has synced or checked out a working copy, but the
working copy itself is still just a flat file sitting in your
filesystem. It doesn't claim, nor does it have the facilities to claim,
that it is anything else but that.

I'm not sure I understand the original question, though. I was wondering
if the user-specific files are in SVN by mistake? It seems like it would
be a mess, and some cleverly formulate .svnignore directives would be a
good idea...?

-Matt

-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]On
Behalf Of kfogel@collab.net
Sent: Friday, September 23, 2005 11:57 AM
To: David James
Cc: dev@subversion.tigris.org; Max Bowsher; nick vajberg
Subject: Re: Feature request:: Unversioning files (svn rm --keep-in-wc)

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
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. 
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org