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

Re: Possible svnsync data loss bug?

From: Trent Fisher <trent.fisher_at_oracle.com>
Date: Tue, 26 Jun 2012 13:37:27 -0400

On 06/22/2012 08:17 PM, Nico Kadel-Garcia wrote:
> On Fri, Jun 22, 2012 at 5:21 PM, Trent Fisher<trent.fisher_at_oracle.com> wrote:
>> On 06/22/2012 01:59 PM, Mark Phippard wrote:
>>> On Fri, Jun 22, 2012 at 1:52 PM, Trent Fisher<trent.fisher_at_oracle.com>
>>> wrote:
>>>> I just ran into a rather frightening problem. We do replications via
>>>> svnsync for backup purposes. I just found two of the replicated
>>>> repositories which had these entries for *every* version:
>>>>
>>>> r20927 | (no author) | (no date) | 1 line
>>>> Changed paths:
>>>>
>>>> And svnlook tree shows there is nothing in the repositories.
>>> I believe this matches the behavior you would get if you were using
>>> path-based permissions and the svnsync user did not have read
>>> permission to the paths in the revision. Could that be the reason?
>>> You could also get this if you did not specify the URL to the root of
>>> the repository. Any revision that does not touch the path you
>>> specified would just sync an empty revision.
>>
>> Duh! Of course. I just tested both of the possible reasons you gave and,
>> sure enough, both will produce revs like the one in my first message. But I
>> think the only way to get a replica, like mine, with *all* empty revs would
>> be via path-based permissions. If we were syncing only a subdirectory of a
>> repository which we, otherwise, had read access to, the commits outside of
>> the sync'ed url would have proper usernames and dates, but no files. (I
>> tested that too)
>>
>> I was about to ask if svnsync would get access denied errors... but I did
>> another test which, I think, answered my own question: If I run "svn log"
>> against a repository to which I have only access to part of, revs in the
>> areas I don't have access to will show up as "(no author) | (no date)".
>> Presumably svnsync is doing some variant of a "log" call and then getting
>> the contents of each rev and faithfully reproduces what seem to be empty
>> revs.
>>
>> So, I guess svnsync is arguably doing the right thing. But even if it were
>> declared to be incorrect, and a fix were checked in right now, it wouldn't
>> address any of my existing replicas. So, I'll have to develop some
>> auditing for these sorts of things. Which brings up another question: is
>> there any other reason you would ever see "(no date)" in a log entry?
> Ouch. svnsync failing to transfer due to permissions, but leaving
> empty logs, is...... That's a silent failure that's going to be really
> problematic in the field.
>
> What happens after the permissions are opened? Do the logs get
> recovere successfully?

I agree this is problematic. I might have a total loss on two
repositories due to this. I have no idea if or how this could be fixed,
I've never really delved into the guts of SVN, though maybe I will after
I take care of my current crisis.

As for later opening up permissions, I don't think that's going to help
at all with old revisions. Even though they are empty, svnsync will not
go back to reconsider them, only newly created revisions would be
affected. But if you created a new replica with svnsync and start over,
it should pick up the revisions correctly.
Received on 2012-06-26 19:38:07 CEST

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

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