> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: dinsdag 26 juni 2012 22:14
> To: kmradke_at_rockwellcollins.com
> Cc: Mark Phippard; Trent Fisher; users_at_subversion.apache.org
> Subject: Re: Possible svnsync data loss bug?
>
> On Tue, Jun 26, 2012 at 8:07 PM, <kmradke_at_rockwellcollins.com> wrote:
> >> > 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?
> >>
> >> I cannot speak to all scenarios because I have not tested them. For
> >> example, if the svnsync user simply had no read access to anywhere in
> >> the repository it seems like it ought to error. But that scenario
> >> aside, the way that svnsync works is actually a huge feature. Imagine
> >> you have a remote team of contractors that you want to give a local
> >> replica of your repository. These contractors are not allowed access
> >> to parts of your repository. The contractors can use svnsync to crete
> >> a local replica using their credentials and their local repository
> >> will only contain the content they are allowed to access. The
> >> revisions that altered other paths will simply be empty commits.
> >>
> >> As I started, there may be other scenarios where this could be handled
> >> differently, but overall I think this is a great feature of svn.
> >
> > Both are valid use cases. I frequently use the current access behavior
> > to "filter" large repositories instead of using svndumpfilter which
> > would require terabytes of scratch space and days of downtime to filter.
>
> It's also sometimes used to recover from some forms of repository
> corruption (lacking proper backups), if the corruption is limited to a
> single file (or a set of files) in history. By configuring an authz
> policy that denies access to that file, one can svnsync to a new
> repository, which is then free of corruption (without the corrupted
> file of course).
>
> > Any reason svnsync couldn't grow a "--fail-on-access-error" option?
>
> Sure, I think that could be useful (as long as it's not the default
> (backwards compat)).
The problem here is that we don't get an access denied error. Svnsync just
notes an empty revision, which is somehow valid. (We try not to create empty
revisions, but there are quite a few repositories that have them via
different tricks or bugs).
So we should have a way to detect that this happens.
Bert
>
> --
> Johan
Received on 2012-06-28 12:10:54 CEST