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)).
--
Johan
Received on 2012-06-26 22:14:46 CEST