Augie Fackler wrote on Fri, 21 Nov 2008 at 09:26 -0600:
> On Nov 21, 2008, at 2:36 AM, Daniel Shahaf wrote:
> > Neels J. Hofmeyr wrote on Fri, 21 Nov 2008 at 02:58 +0100:
> > > I figure a sync from one repos to another may produce this situation: The
> > > one server contains inconsistent line endings, of old. The other server
> > > now
> > > checks incoming data for consistency and refuses to receive.
> > >
> >
> > We should document a way of getting out of this "My repository is invalid"
> > situation. It's been reported a few times already (including in the svn
> > and svnbook repositories) and we haven't even branched 1.6.x yet.
>
> +1 - For now, as far as I can tell the way out is to use an old svnsync if you
> actually want a local copy of the repository.
>
Yes (assuming the dest repos is file://; the server does the validity
checks, not svnsync itself), it works very well.
> > > So, I guess svnsync should automatically correct inconsistent line-ending
> > > styles (check each svn:log revprop, if found inconsistent, send a
> > > consistent
> > > version to the other side, or something like that -- might get complex).
> > >
> > > I have no time to work on this now, so if you feel inclined to look around
> > > yourself or have others to do that for you, this list will gladly be of
> > > assistance.
> > >
> > > Alternatively, the source repository could be fixed to not contain any
> > > inconsistent line endings.
> >
> > For the svn:log props, I like the latter approach: we could post a script
> > that converts them to LF and UTF-8. Then the repos conforms to our API
> > and the problem is handled once and for all.
>
> That actually feels wrong to me - I can't, for example, easily go fix svn:log
> properties on Google Code
"svn propedit" doesn't work for you?
> 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).
> > 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.)
Daniel
> > Daniel
> >
> > > First, though, to be sure, post a more detailed description, as above.
> > >
> > > Thanks!
> > > ~Neels
---------------------------------------------------------------------
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-21 22:13:33 CET