[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: deleting files from the repository

From: Ryan Schmidt <subversion-2009a_at_ryandesign.com>
Date: Tue, 10 Mar 2009 01:00:13 -0500

On Mar 9, 2009, at 06:13, Bolstridge, Andrew wrote:

> I have a large (several gigabyte) repository and unfortunately a
> remote developer has checked in quite a few temporary build objects.
>
> What I’d like to ask is what others do about such a problem. I’ve
> tried dumping the repo and running svndumpfilter on it, but that
> complained that I’d dumped the repo with the –deltas option (of
> course) and refused to have anything to do with it. I’d try dumping
> the repo without deltas, but the resulting dump is unmanageably huge.
>
> Are there any plans for an improved dump/filter process, preferably
> one that could remove several files in 1 go?
>

You don't need to write the huge dumpfile to disk. You can pipe the
output of svnadmin dump directly to svndumpfilter whose output you
can pipe directly into svnadmin load to put it back into a new
repository.

> Are there any plans for svn obliterate to be implemented (I’m not
> sure of this as a client command, I think it should be an admin
> tool, which would be nice)
>
Everything we know about "svn obliterate" is in this ticket:

http://subversion.tigris.org/issues/show_bug.cgi?id=516

> Can I manually edit the dump file? If I wrote a tool that removed
> the relevant sections, would it work? These particular files do not
> have any branches/moves/renames etc.
>

While the dumpfile format is not complex, I'm sure it would take a
significant amount of work to write a tool that processes it
accurately. I would instead strongly recommend you look into the
existing tools that can modify dumpfiles, including svndumpfilter,
svndumptool, svndumpfilter2 and svndumpfilter3.

> I’ve since updated the pre-commit hook to prevent this kind of
> problem, but I live in fear that someone will upload a tiff or a
> database file.

If it's size in the repository you're concerned with, your pre-commit
hook could check the size of the committed files and fail if they're
too large.

> Wouldn’t it be a good idea to set such a hook up by default for
> most repositories – it wouldn’t be a newbie-knowledge problem, the
> first time someone checked in a banned file, they’d get a commit-
> error message telling them why and they could alter the hook.

What criteria would you suggest the hook script use to reject files?
Are you talking about just matching certain filename extensions,
perhaps the same list Subversion uses by default for global-ignores?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1301295

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-10 07:01:24 CET

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.