On 9/24/2010 2:26 AM, David Huang wrote:
Am I wrong in thinking that similar accidents happen to everyone
eventually and that a feature to fix them would be desirable?
Yes, the feature has its use case. And if you'd like to see it
implemented yesterday, that's cool. Just don't assume that everyone
thinks the same way please.
Can you actually name anyone who thinks it's not a useful, or
potentially useful feature? Anyone?
I suspect what was meant is that not everyone thinks obliterate needs to be "implemented
yesterday" or that it's the "#1 request". I do think obliterate would be useful, but
I personally have not ever needed it in my 2 or 3 years of administering an SVN repo, and don't
forsee needing it in the future.
Also, it's not like the SVN team has rejected the feature; the FAQ mentions
that it's planned: http://subversion.apache.org/faq.html#removal and there's
even a roadmap for it:
https://svn.apache.org/repos/asf//subversion/trunk/notes/obliterate/plan-milestones.html
Aside from the necessity of being able to fix inevitable mistakes in
source management, I think being able to delete things is the main thing
that keeps subversion from being usable as a generic versioned remote
file store (with or without fuse mapping to a real filesystem). There
are lots of places where you want _some_ history and you'd like to be
able to use subversion tools and have central control with easy remote
access, but storage that can only grow indefinitely just doesn't fit.
This may not be a priority for anyone on the SVN team but I think
solving it would expand the use of the code base by orders of magnitude.
Even where your main use is for source, think about how handy it would
be to let an automated build system commit binaries back into a tag area
that could be cleaned up periodically to remove the ones that fail
testing or become obsolete due to subsequent releases. If you do that
now, you make your repository harder to maintain and back up over time,
and if you don't do it you have to come up with some out-of-band
mechanism to version and transport the binaries.
--
Les Mikesell
lesmikes...@gmail.com
