On Nov 21, 2008, at 3:13 PM, Daniel Shahaf wrote:
> 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?
Given the lack of any ability to set arbitrary hooks on Google Code, no.
>> 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.
>>> 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).
> 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:34:48 CET