Hi Mark, Mark Phippard writes: > On Wed, Jul 7, 2010 at 10:47 AM, Ramkumar Ramachandra > <artag...@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
