[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: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 26 Jun 2012 13:43:11 -0400

On Fri, Jun 22, 2012 at 5:21 PM, Trent Fisher <trent.fisher_at_oracle.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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-06-26 19:43:43 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.