[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Trunk svnsync can't sync some existing repos

From: Augie Fackler <lists_at_durin42.com>
Date: Fri, 21 Nov 2008 09:26:11 -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.

>> 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
> 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 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 ;).

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

> 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 16:26:48 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.