Felix Gilcher-3 wrote:
>
>
>> it's been talked for years now and i do not understand the "if it's so
>> important then somebody would have done it" thing.
>
> Obviously it's not sufficiently important for you to do it because you
> haven't done it, and obviously it's not suffiently important for me,
> otherwise i'd have done it. And by 'doing' it I don't mean that you'd have
> to learn C and write the code on your own - if that feature is that
> important to you, you could fund a developer writing it, you could
> initiate
> a funding by all interested parties or you could otherwise participate in
> the process of getting it done. Obviously noone has felt the urge to do
> so,
> or otherwise such a feature would have been implemented, but so far it's
> not
> even formally designed. Go figure.
>
>
i'm not sure. it certainly is one of the most often mentioned issues (see
the wikipedia entry for example). it's one of the most often wished features
as well.
there even have been people who wanted to sponsor the development but they
were turned away "because it needs to be specified first" etc.
did you see the comment in the bugtracker: "1 week estimated"?
>
>> i read tons of posts and i still don't see what is the problem with
>> implementing the simple case of completely erase a file/directory from
>> all
>> revisions. i know some people want more functionality. but i say 90% just
>> want the simple case the hardcore blaster solution (call it "archive
>> unneeded projects and remove trash to save disc space").
>
> Well, I don't see the problem either, but I'm no subversion dev and the
> people that know the code say it's not that easy and I trust them more on
> such matters than I trust my judgement.
>
>
the only thing i see is the estimated one week, which certainly was for the
simple solution. what i'm trying to say is, that this simple solution could
be maybe considered.
>
>> i never had a look at the code (wouldn't help either, i'm a java guy) i
>> had
>> some glimps into the revision files in FSFS and certainly saw loads of
>> dumpfiles. and i can not imagine that implementing this simple case is
>> realy
>> difficult. am i wrong?
>
> Probably. Try erasing such a revision file and you'll quickly notice that
> these files may depend on each other. Note that it's always easy to remove
> the last revision in a FSFS repository (by removing the revision file and
> resetting the 'latest revision marker', though I'd recommend using
> svnadmin
> dump/load with a revision range), so if you notice the error fast enough
> you
> won't have much pain.
>
>
i'm not stupid. i can see that the revisions depend on each other. but i can
also see that erasing a whole file (not just the changes of one revision) is
not a difficult task. find the root where it was added, remove it and then
go trough the history and remove all future referecnes to this file.
i could write a java app which does it in the dumpfiles if i had to. it
would be slow...
>
> Others that desire such a feature have other small or large wishes and so
> far, noone has found a comprehensive set of features that form "svnadmin
> obliterate". Finding a featureset that people agree on would be the first
> step.
>
>
we'll never find a perfect solution so let's not do anything at all?
is that what you are saying?
>
>> at least would it be possible to have some "dump grep sed-awk dumpfilter
>> load" thing which does the work (my solution involves and cygwin-grepping
>> and ultraedit, not the worlds most elegant solution...)
>>
>
> Well, bash-scripting FTW. Or use your javaskills and the java language
> bindings (though I don't know wether these exist for the administrative
> part
> of svn) or any of the scripting language bindings.
>
>
you know why we moved from CVS to SVN? because it is better. i love
subversion i think it rocks! i want to stay with it. ignoring features that
loads of people think are important just by saying "it doesn't fit into the
concept of VC it's not important, and there is a workaround (why a
workaround if it doesn't fit in the concept), and we could not find a
solution to make everybody happy, so we dont' even care to search for one"
is not cool. i know that complaining and demanding features from an open
source product is not cool as well. i'd happily donate some money i'd love
to help if i can lots of others think the same way. but some please tell us
how.
IMHO i get the impression that the developers do not want this feature (i'm
talking the "make it as simple as possible" solution), and i can not
understand why. i mean, come on: 5 years!
best regards
patrick
--
View this message in context: http://www.nabble.com/the-obliterate-discussion---why-dumpfiltering-is-no-valid-workaround-tf4116918.html#a11710471
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 20 17:38:22 2007