Hi Mark,
Mark Phippard writes:
> On Wed, Jul 7, 2010 at 10:47 AM, Ramkumar Ramachandra
> <artagnon_at_gmail.com> wrote:
>
> > I have recently developed a new svn_editor_t editor for Subversion
> > that uses the replay API to generate a dumpfile v3 over the network
> > on-the-fly (without touching the filesystem except for some temporary
> > files). I initially started building the tool to merge it into the
> > git.git tree and link it to a "remote helper" tool to allow Git to
> > seamlessly import Subversion history as part of a Google Summer of
> > Code project. I later figured that the tool would be useful to both
> > SVN server admins to generate backups and other VCS developers; my
> > current plan is to get it merged it into git.git, and then (if it's a
> > good idea) get it merged into the Subversion tree and remove it from
> > git.git. As an added bonus, it currently performs significantly better
> > than `svnsync` because it doesn't need to touch the filesystem or
> > apply any deltas.
>
> Since it uses the RA layers, how does this interact with authz rules?
> Does it respect any authz that has been established, just as svnsync
> does?
Actually, I realized that svn_delta_editor_t comes with absent_file
and absent_directory to handle exactly this. By default, they're
no-ops, so I don't think I need to write in any extra code to handle
authz.
> How about adding a pre-* hook so that an administrator could disable
> this? There might be some administrators that would want to disable
> this.
I thought about this, and I'm not too much in favor of this either
(see Daniel's comment): should we really give the admins an option to
block replay? If replay is disabled on a server, people can still
extract the revision history the brute-force way: fetch the text and
props for each revision by hand, and this is not pretty.
-- Ram
Received on 2010-07-08 09:20:46 CEST