Augie Fackler wrote on Fri, 21 Nov 2008 at 15:34 -0600:
> On Nov 21, 2008, at 3:13 PM, Daniel Shahaf wrote:
> > > without syncing it using an old version and then asking for a repo
> > > reset. The former approach, while more complex, *seems* a bit more
> > > satisfactory. That said, until I actually find time to write code
> > > for this, I'm just a whiner ;).
> > >
> >
> > There presumably are other tools (not just svnsync) affected by this.
> > The former approach requires fixing all of them individually, while the
> > latter requires fixing the repository once, and after that everything
> > works (without any further changes).
>
> Valid, but I also can't think of what those tools might be.
>
Anything that edits props over libsvn_ra or lower layers. (You get the
value in CRLF, run an editor that preserves the EOL style, and *boom*
when you send the value back.)
> > > > However, I also added another new check -- for filesystem paths
> > > > being in UTF-8 -- a few weeks ago. It would be harder to fix,
> > > > since the corruptions it detects are in the immutable historical
> > > > data. (Does any dumpfile manipulator support re-encoding paths
> > > > already? If not, it or svnsync could be taught to do that.)
> > > >
> > > > Opinions?
> > >
> > > Could we write a tool similar to svnsync that produced a dumpfile
> > > instead which could be post-processed as needed to get it to load,
> > > bypassing the "invalid rev" problems?
> > >
> >
> > This could work (in the sense that all the needed information is
> > there), but it's some work to do so. (I recall lgo suggesting some
> > generalisations in this direction a few months ago.)
>
> Maybe that's the Right choice then. Saying "Fix your logs" is bound (in my
> opinion) to be a bad option (given the existence and common use of hosting
> sites like Google Code).
>
Possibly. The Easy choice, though, is to disable the validity checking
during the sync; it's a one-line change :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-22 11:19:02 CET