Michael Eager <eager@eagercon.com> writes:
> I saw the FAQ about the unimplemented "svn obliterate" command.
>
> It's easy to import or checkin crud into a repository. For example,
> I have several svn-commit.tmp files resulting from errors in importing
> files, or .swp files from files which had been edited. It's also
> pretty easy to import a tree into the wrong place in a repository,
> then import it into the right place, resulting in two copies in the
> repository.
>
> The work-around in the FAQ to delete a file or directory from the
> repository is cumbersome.
>
> The unpleasant choice seems to be to "svn del" files or directories
> so that they are not checked out, but to have them persist in the
> repository, cluttering up contents generated by viewvc.cgi, and
> confusing people about which is the "real" repository.
>
> This is (in my opinion) a major flaw in Subversion. Managing
> a repo means being able to clean up errors and messes when they
> occur, not having to live with them forever. Is there any way to
> fix these kind of problems in an Subversion repository?
>
> I've only looked at the SVN code very briefly. What would it take
> to implement the "svn obliterate" command?
The hard part is to define exactly what it will do, see
http://subversion.tigris.org/issues/show_bug.cgi?id=516#desc17
for more on that.
We badly need the feature, everyone agrees -- but defining exactly
what the feature is is the hard part :-). It will need someone to
drive the discussion, an "honest broker" in the sense described here:
http://producingoss.com/html-chunk/consensus-democracy.html#voting (I
don't mean to imply that voting will be needed here, I'm just linking
to that as a description of what broking means).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 5 19:50:01 2006