It's not really about how much hassle it is, but rather who has the hassle.
Do we want the users of subversion to have the hassle of manually
synchronizing hundreds of working copies each time a repository has to be
recovered, or do we want the developers to have the one-time hassle of
writing code to automate the process?
Agreed, ideally this would never happen! But realistically, we have
power-outages that corrupt hard drives, hackers who delete files, inept
sysops who screw things up, and the possible *gasp* bug in a program
somewhere that results in a corrupt repository.
It seems to me that if subversion is to be widely accepted as a useful tool,
it would lean towards reducing the workload of the users and admins. After
all, that's why we use a version control too: so we don't have to manually
mess with different versions of a bunch of files.
It's pretty well understood that when everything is down (as when a
repository is recently restored) that there is a lot of pressure on the
sysadmins to get it back up. This pressure can lead to mistakes, especially
when there are a lot of manual steps, and a lot of mental grunting to figure
out how to restore a usable system. Automation, my friends!
(For the record, I think subversion is an awesome tool. And I haven't looked
at a single line of source code myself. And I'm not complaining. My comments
are only drawing attention to a detail that might need attention at some
point.)
Good day!
--- Eric
> How often do you need to restore a backup? Seems that this is an
> extremely rare situation. And there's a relatively simple
> fix: check out
> a new working copy. You can do a simple diff to compare to
> your old wc,
> and move any changes since your last commit. Yeah, it's a pain if
> there's hundreds of working copies--but for the frequency of
> this event,
> surely much less than the pain of implementing something that
> would take
> an awful lot of thought and testing to work out all the issues--when
> that effort should be used towards reducing the need for restoring a
> repository in the first place... And the pain really isn't
> any more than
> resolving any other conflict.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 14 22:51:15 2003