>> But there's also stored *which revision you checked out*.
Hmm, I see what you mean now, this may be the killer blow to my
proposal. In my particular case of corruption, I could guarantee that
there have been no checkins since then, so I know my corrupted working
copy is still at HEAD, but I can see this is not necessarily the case.
I've also recently discovered that with WinMerge, it's not only easy to
compare directories, but also to copy files from one to the other (just
right click on a file marked as different, and select 'copy...'), so I
guess my recovery recipe would now be:
1. Move the corrupted working copy somewhere safe
2. Do a clean checkout
3. Use a good directory compare/merge tool like WinMerge to repair the
changes, keeping in mind there may be new edits to the files you have
edited.
Oh look, that's what I said in my original post. Ahem...
> So I would say that the .svn directories really are quite important, and
> messing them up really is a bad idea.
Then scattering them all over my project files is also a bad idea!!
> It's also possible to have a field day in your operating system
> directories, deleting libraries and configuration files
But this is exactly why all that stuff is nicely tucked away in its own
directory, preferably on another partition. Windows doesn't scatter
registry information all over my daily work.
Yeah, I know, I said I wasn't going to go there, let's leave that one then.
Alright, thanks for the comments guys, at least it has increased my
understanding of how subversion works, and if it has done the same for
one or two other people then it's been worth having the discussion.
Cheers,
Robin.
Ryan Schmidt wrote:
> 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.
>
>
>
--
mirocs OHG
Development, Services and Trade
Am Krež
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 16:35:01 2005