Am 20.07.2007 15:03 Uhr schrieb "patrick" unter
<Patrick.Wyss@mobilesolutions.ch>:
>
> hi there,
<snipped feature description of a possible svn obliterate command>
>
> 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 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.
>
> 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.
>
> if i had just one wish it'd be a non-blocking (or very shortly blocking ;-))
> svadmin obliterate MYREPOS *.log
See - you have "just" two "little" wishes:
- non-blocking (for an operation that might modifiy the whole repository)
- wildcard support
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.
>
> 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.
> best regards for any help with this
> patrick
>
> ps: and by the way for all monthy python fans: jehowah
Regards
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
E-Mail: felix.gilcher@exozet.com
URL: www.exozet.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 15:44:32 2007