On Nov 24, 2004, at 9:36 AM, Mike Crowe wrote:
>> So, is there an automated way of resurrecting the text-base files should
>> they go missing without losing any pending changes or accidentally
>> reverting checked in changes?
On Wed, Nov 24, 2004 at 10:39:59AM -0600, Ben Collins-Sussman wrote:
> Nope, no such feature exists. It would be nice, though, if a working
> copy could "heal" itself and re-fetch missing text-bases.
As a CVS user I expected a simple "svn up" to repair things. I'm not
particularly worried that issuing a "svn diff" gives an error as long as it
is clear how to fix it.
Is it a particularly hard thing to do? Should I submit a feature request
for it? It can only help to improve the resilience of subversion. The
text-base files could go missing for other reasons too (umm, filesystem
corruption?)
> I have to ask, though: why are you backing up working copies? By
> definition, they're meant to be scratch areas, "temporary" workspaces.
> It's the repository that really needs to be backed up.
People are likely to keep changes in their checkouts for a number of days
before checking them in. These changes need to be backed up.
> Maybe you can just have your backup software skip over .svn/ dirs
> completely. If a crash happens, don't bother to restore working copies
> unless a user tells you that there was a specific patch-in-progress that
> needs to be recovered. In that case, you restore the broken
> working-copy, have the user checkout a new working-copy, then manually
> copy the edited files into the new working-copy.
I'd feel as if I'd not done my job of providing reliable IT infrastructure
in that case :)
Determining which files had been modified is also difficult if the
text-base has gone missing. I know that I would need to remind myself.
--
Mike Crowe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 24 19:10:12 2004