On 06/22/2012 08:17 PM, Nico Kadel-Garcia wrote:
On Fri, Jun 22, 2012 at 5:21 PM, Trent Fisher<trent.fis...@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.fis...@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.
