Recovering text-base

[Mike Crowe <ma...@mcrowe.com>]

A downside with moving to Subversion for us is the pristine copies in
.svn/text-base. I know this subject has been discussed to death and I don't
wish to fan the flames there. :)

It turns out that the backup tape space and time used by these files is
more important to us than the disk space. We've considered excluding the
.svn/text-base files from the backup. This would be fine if there was an
easy way to recreate them after restoring the backup. I couldn't find such
a way mentioned in the list archives :(

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?

TIA

-- 
Mike Crowe

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Recovering text-base

[Ulrich Eckhardt <ec...@satorlaser.com>]

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

Re: Recovering text-base

[Mike Crowe <ma...@mcrowe.com>]

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

RE: Recovering text-base

[Dale Worley <dw...@pingtel.com>]

    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?

Looking at .svn/entries, it doesn't look like it would be difficult to write
a program using any of the popular scripting languages that would do the job
well enough -- it lists all the files in the parent directory, the revisions
that were checked out, the repository URL for the directory, the timestamp
on the text-base file, etc.

    From: Ben Collins-Sussman [mailto:sussman@collab.net]

    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.

The svn_load_dirs.pl script should be able to help you with this.  But make
sure that the working copy you check out is at least as old as the working
copy that the restored files were from, otherwise you could automatically
reverse some changes.

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Recovering text-base

[Ben Collins-Sussman <su...@collab.net>]

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?
>

Nope, no such feature exists.  It would be nice, though, if a working 
copy could "heal" itself and re-fetch missing text-bases.

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.

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org