SVK already let's you mirror all revisions of a remote repository
today using SVN::Mirror, with or without the replay API. And this is
exactly how you would use SVK if you were working with the apache
sources (though you might choose to mirror only a subset of the tree
if you don't need all of it). Once the initial mirror is done users
using svk will typically present a much smaller load on the server
since they only hit the server for commit's and mirrors of new
revisions.
The main advantage that the replay API has is that it will make
SVN::Mirror faster and use less resources on the server than it does
today.
Since there doesn't seem to be an outcry on users today to prevent
people from being able to mirror their repos with svk, why limit the
more efficient new API but leave the slower existing one around?
Michael
On 4/12/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> Justin Erenkrantz wrote:
> > > Perhaps we could consider rate-limiting rather than outright blocking of
> > > the feature as a DoS avoidance strategy?
> >
> > Rate-limiting isn't the problem - it's that the normal user shouldn't
> > be making a local copy of repositories that have 400000+ revisions.
> > If they even *think* Subversion now encourages this, we're going to be
> > opening a Pandora's box. -- justin
>
> You do not provide any arguments as to why this is a problem.
>
> Upon reading your post, I'm left thinking "bah, who are you to decide
> what 'normal users' should do and not do?".
>
> Could you please provide some reasoning why you think rate limiting is
> not a good solution?
>
> To me it sounds just perfect - allow people to do what they want, but
> don't let them eat more than so-and-so-many-percent bandwidth (... or
> cpu, or memory, that would be useful too.)
Received on Wed Apr 12 17:24:43 2006