Am 20.07.2007 17:39 Uhr schrieb "patrick" unter
<Patrick.Wyss@mobilesolutions.ch>:
>
>
> 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"?
>
Sponsoring the development is not enough, but you can always sponsor someone
to do the formal design and the development. I have yet to see someone being
turned down who offers to sponsor the design and the development of any
feature that is generally accepted to be a good idea. However, there is no
upper limit on how much time the design process may need, so the sum you'll
have to spend is rather hard to estimate.
The time estimate "1 week" dates from 2001 and may have been a rough guess,
but shurely you noted that quote from further down the line:
<quote>
------- Additional comments from Karl Fogel Sun Dec 18 19:59:16 -0700 2005
-------
One week isn't even enough to spec out this feature from a design/features
standpoint.(...)
</quote>
And funding may be of no help, if you read the last post in the issue
tracker (and that one is quite recent):
<quote>
------- Additional comments from Karl Fogel Wed Jun 13 10:07:35 -0700 2007
-------
We're nowhere near raising a purchase req, sorry.
What you need is a developer who's interested & available to do this. With
that, all things are possible. But we don't have that right now. The
stages
you list above are precisely what such a developer would start on.
</quote>
Obviously there is no dev out there who is both willing and capable of
implementig this feature. Maybe a statement on how much you could raise may
change some capable developers mind, but who knows.
>
>>
>>> 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.
>
See above. The one week estimate is no more.
>
>>
>>> 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...
>
Do it. Feel free, it will solve your problems at least for the main part
(maybe still takes long to run, but all in one command). It could even serve
as a reference implementation or a testbed on how svn obliterate should
behave. Maybe you can even derive a formal spec from what you learned
developing this app - what problems are there, corner case behaviour etc.
>
>>
>> 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?
>
No. What I'm saying is that any feature implemented in svn requires a
written spec that can be discussed and agreed on. This spec must describe
how the feature must behave. The spec can descrive a minimal set of features
if you wish so, but it is required. I much like it that the svn team is
quite picky on what to accept, this is a version control system, you entrust
your most valuable data to it. It's not just an app that may crash and burn
and apart from the user freaking out nothing happens. The hacking file can
tell you more about the dev process.
>
>>
>>> 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!
>
I don't think the devs do not want it. I haven't seen the statement 'it does
not fit the concept', only 'svn tries hard to protect data, so it's hard to
force it to forget something' and lots of warnings that this is a dangerous
feature that must be well designed to be viable - and I do agree on that.
Additionally, there are more features being requested and the dev prioritize
by what they need and by what they'd like to do - for some of them, this is
what they do for fun. And we're just getting one of the (imho) most
important features - merge tracking which is nearly as old as 'obliterate'
and at least as useful and as often requested. So maybe someone picks up
obliterate after merge tracking has been done and settled.
And as for telling you how to spend you money: Maybe finding people that
agree with you, ask them how much they would pay, finding a dev willing to
go all the way through the process for that amount and paying him would be
of help. This may be a bit of work and especially the last part seems to be
hard. Be aware however that merely developing the feature does not guarantee
that it will be accepted for the svn trunk. Paying a dev to do the formal
spec might be a starter or at least give an estimate on how much time is
required.
> best regards
> patrick
I hope that you don't get me wrong: I would like to see such a feature as
well. But I much rather would like to see merge tracking...
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 20:38:04 2007