SVN timing

[Kevin Puetz]

Dirk Mueller wrote:

>>- real move/copy without serverside hacks
> 
> - no way to remove failed imports, fix repository screwups server-side. no

On the plus side, not needing the cruft cvs import requires (vendor branche
names, etc) to use the 'import' command ought to cut down on the incidence
of botched imports :-) "svn import /local/path/foo
http://svn.kde.org/kdeplayground/foo" is moderately idiot-resistant.

It doesn't at first glance seem that hard to  obliterate an entire commit
(at least for fsfs, bdb's schema I don't really know). It would mess up the
WC of anyone who had already gotten those changes, but that's just as true
of server-side munging in CVS, and pretty much par for the course;
generally if nuking a botched import, one assumes nobody has it checked
out. Otherwise just do a normal versioned remove and continue on.

The basic approach would seem to be swapping the file in db/revs/<revnum>
for an appropriate noop commit, and probably changing the log message in
db/revprops/<revnum> to indicate an obliterated commit. There would be some
cleanup needed in later revisions which also touched that area of the
repository to keep the subfolder from showing up if they mention it in
passing (if they actually modify it, just fail the obliterate - that's
where things get too nasty). I wonder what I'm overlooking that makes this
tricky enough to still be missing...

> anoncvs servers for users anymore (we have >= 600 people using anoncvs
> servers every day).

Well, not anoncvs, but I don't think anonsvn should be that hard to provide
(other than prodding people into adjusting their mirror scripts, which may
admittedly take some doing). SVN::Mirror is quite mature (doing the
mirroring at the svn protocol level instead of directly poking the
backend), or, if preferred because of existing scripts, fsfs interacts
quite nicely with rsync (read and remember 'current', rsync the
revs/revprops folders, then write current - the repository is consistent
and readable the whole time). This is all quite tidy, since the files
corresponding to existing revisions never change again, unless the
shifty-eyed admins are nuking revisions (see above).