On 03.06.2005, at 09:41, Ph. Marek wrote:
> On Friday 03 June 2005 08:58, Robin Pellatt wrote:
>
>> Correct me if I'm wrong, but as far as I'm aware the .svn directory
>> contains no information about my edits, only a pristine copy of each
>> file that was checked out, and information related to that, therefore
>> all the information needed to do recreate these directories is in the
>> repository (On further perusal of the docs, there may be other info
>> such
>> as when I've schedule a new file for addition, but I can live with
>> losing that).
>
> But there's also stored *which revision you checked out*.
Yes, that's the issue I see. For the sake of an example:
You have a working copy of your project's trunk at revision 10, and
you've made local edits. Now you corrupt your .svn directories somehow,
and decide to use this hypothetical "svn recover" command. What
revision does it check out? If you don't supply a revision to the
command, presumably it checks out HEAD, which, let's say, has by now
been bumped up to 20 by other developers' commits. So now you have
working copy files that are based on 10 but due to the newly-rewritten
.svn directories, Subversion thinks they're based on 20! If you look at
a diff at this point, you'll see that if you commit, not only will it
make the edits you deliberately made, but it will also *undo* all the
changes between 10 and 20. And I don't think we should give the user
the opportunity to so easily shoot himself in the foot.
So, you might say the solution is that when you run the command, you
must specify the revision to which the working copy was last updated:
"svn recover -r 10" perhaps. But how do we know that it was revision
10? The "svn info" command cannot be relied upon, since it requires
intact .svn directories, which we've said we don't have. And the book
mentions over and over how the revision number is unimportant, and that
users needn't concern themselves with it, so I don't think the user
will have it in his head. At the moment, I have 14 working copies of
various projects. I'm sure I don't know what revision each is at.
What about our perennial favorite, the mixed-revision working copy?
Because of the way Subversion works it practically guarantees that a
working copy has mixed revisions, even if that's not what the user
intended. And in the face of that, an "svn recover" command can't
possibly recreate it accurately, unless the user were to somehow
specify the revision of every object in the working copy, and I'm
practically positive the user doesn't remember that.
So I would say that the .svn directories really are quite important,
and messing them up really is a bad idea. Yes, it's possible for you to
mess them up, but I'm not sure how Subversion would prevent you from
doing so. It's also possible to have a field day in your operating
system directories, deleting libraries and configuration files, but
then you can't be surprised when the OS doesn't work anymore and you
have to reinstall it. In the same way, I think you shouldn't be
surprised that destroying a working copy's internals means you have to
start over with a new working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 11:50:02 2005