Mike Crowe wrote:
> 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.
I haven't finished my first coffee yet, so treat this idea with proper care:
how about going through all working copies on a machine and backing up the
diffs? Point is, that once a change in in the repository (which is backed up)
it doesn't have to be backed up in any other way. Until then, it should
suffice to back up the diff only.
BTW: can I produce a patch with 'svn diff' that also covers new files and
differences in binary files? Something like a complete diff between a fresh
checkout and the current state of the workingcopy?
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 25 08:22:52 2004