> > 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.
Any reason svnsync couldn't grow a "--fail-on-access-error" option?
Kevin R.
Received on 2012-06-26 20:08:10 CEST