Eiren Smith wrote on Fri, 18 Jun 2010 at 23:50 -0000:
> On Jun 18, 2010, at 2:53 PM, Daniel Shahaf wrote:
> > Eiren Smith wrote on Fri, 18 Jun 2010 at 10:01 -0400:
> > > On Jun 18, 2010, at 3:07 AM, Daniel Shahaf wrote:
> > > > Eiren Smith wrote on Thu, 17 Jun 2010 at 23:24 -0000:
> > > > > Any ideas about how to handle this since I can't mimic the changes to
> > > > > the
> > > > > binary files modified in the missing revs?
> > > > > 
> > > > 
> > > > Patch svnadmin to skip those particular files (hard-code them) when
> > > > parsing a dumpfile?
> > > > 
> > > 
> > > Sorry, I don't understand. Could you expand on that?
> > > 
> > 
> > IIRC, you were suggested to dump the repository (in parts) in order to
> > recover it.  Normally, if you just load these dumpfiles, it will error
> > at some point due to the missing revisions (which weren't dumped).  So
> > I suggested to recompile svnadmin with a one-off patch that changes the
> > 'svnadmin load' logic to ignore anything in the dumpfiles that touches
> > one of the files touched in those seven revisions.
> > 
> > Essentially, look up what paths were touched in those seven revisions,
> > and then patch load.c so that, when it parses from the dumpfile an entry
> > concerning one of those files, the entry gets ignored (dropped on the
> > floor) and will not be forwarded to the FS layer as normal (with the aim
> > of making a commit to the repository-being-loaded-into).
> > 
> > Clearer?
> 
> Clear. Thanks, Daniel.
> 
> If I wind up going that route, I'll do also check revision numbers so I only
> start ignoring those files at the point where I'm missing revision files that
> include modifications to them, leaving previous revision history for them
> intact.
> 
> I might also do some fake revisions (to some unrelated dummy files, I suppose)
> to keep my revision numbers from shifting.
> 

I'd just do a propset on those same files...

Daniel
(btw, if you need help getting that patch done, feel free to ask)

> /eiren

Reply via email to