On 23 Sep 2005 13:56:39 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> 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 :-).
Perforce keeps state information about working copies on the server.
This makes it easy for them to fix the state information in one shot,
when you run the "obliterate" command. This solution wouldn't work for
Subversion, though.
> 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 this type of corruption common? If your WC claims to contain
non-existent files, it seems harmless to ignore this incorrect
information, and treat the non-existent file as an unversioned file.
Can you think of a use case where this fix would lead to problems?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
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:21:14 2005