Hi Karl (and list),
Thanks for the reply I appreciate your time.
I am certainly under no illusion as to how tired I am going to get of
hear myself say something like;
That's a great idea - but what would we need to do in order to implement it?
Fleshing out the "nitty-gritty" of each and every use-case is where
nearly all the time is going to be.
While I am aware that any code changes may be considerable, ensuring a
"complete" scope of works is always-without fail the hardest part of the
I am also under no illusion as to how long it will take.But if there is
"steward" in place who can keep tasks on track - then the chance of a
successful project is greatly increased.
I certainly take on-board your thoughts about not starting work until
the RC is ready for 1.5.
To be successful I am sure I am going to need the assistance of current
developers who inherently know that when you do "A" - B and C are also
effected. It is going to be the successful identification of all the B
and C's that determine how successful the project is.
While I realise your version 1.6 comment was pretty much just "shooting
from the hip", none the less - I wouldn't be "aiming" for it to be
implemented in any specific release.
Once the due diligence was done, once the coding was completed would
surely dictate the release it did / did not make it into?
It's nice to have a goal... and I will use the link you provided to see
if we can source some developer funding, but as a worst case scenario,
there is no funding - everything will be at "when people can get around
to it" and that certainly doesn't tie-in with any software release schedule.
For the time being, I will make sure that I go through the message
archives and capture all that I can so that we have a good starting point.
It could well take until the 1.5RC to do this. None the less, I will
repost then and see what the feeling is for an "official" request for
Karl Fogel wrote:
> Gavin 'Beau' Baumanis <gavin_at_thespidernet.com> writes:
>> I have been doing a little reading of what I can find out about the svn
>> obliterate proposal.
>> And subsequently have a few questions, please.
>> ( And of course, if this has already been started - I have obviously
>> missed it, could someone please point me in the right direction?)
>> Is the obliterate functionality supported / required by the community?
> A lot of people seem to want it. On the other hand, none of those who
> fund Subversion development have found 'svn obliterate' sufficiently
> compelling to give it the funding it would need. (Of course, a lot of
> work here is unfunded, or not directly funded, too. So please don't
> take this to mean that all features require funding -- that's
> certainly not the case.)
>> Is it supported by those performing the development of SVN?
> Yes, in theory: we'd all like to see it happen, but we have other
> priorities right now, mainly the 1.5 release.
>> Is there any anticipated start date with respect to starting the
>> required work?
>> There seems to be a lot of 1/2 started discussions - but no "official" one.
> That's precisely the problem, yes :-).
>> Subsequently, (if the answers to my above questions are yes), what is the
>> process for starting things off?
>> I assume we would start with asking for use cases and ensuring that
>> we have all use cases discussed for acceptance / rejection. The
>> gathering and vetting of use cases alone is going to be a fairly
>> large undertaking - let alone any "actual" design / development work
>> being completed - or even started for that matter.
>> While I can't think of any off the top of my head - I am certain there are
>> going to be many use cases that can be solved by better education of what is
>> available as opposed to the introduction of any new feature.
>> Lastly, in an effort to be as pro-active as possible and to limit
>> the effort of people already involved - I will most happily and
>> enthusiastically take on the task of "Use Case Coordinator", for
>> want of a better term.
> Thank you for recognizing that this is what is needed. Be careful,
> though: a lot of people have been down this path before you, but were
> not specific enough to be useful. They say things like "obliterate
> should let you remove a path", without specifying the behavior any
> more precisely than that. Each use case will lead to a proposed
> Subversion behavior, and we need to know *exactly* how that behavior
> would work. For example, how does 'svn log' on the repository look
> before and after the obliteration of that path? Is the data removed,
> or merely unlinked? What about copies? Etc, etc.
> If you take this on, be prepared to spend 90% of your time asking
> people to be more specific. That's what it's going to take. That's
> more or less what I've been trying to say in these comments...
> ...especially the last one.
> In issue #516, there are some interesting ideas about how to fund the
> work, and one useful step might be for you to set up a pledge drive at
> fundable.org. Set a high number, like $50,000 US or something, and
> see if you get pledges meeting that. If you do, that might attract a
> developer to come along and drive this to completion.
>> I don't want to step on any toes and sincerely welcome any required
> It sounds like you've got the right intentions :-), just be prepared
> for the process to require a lot of attention to detail.
> We'd all love to see this get done, clearly a lot of users want it
> (but my priority right now is the 1.5 release, so I'm not volunteering
> for issue #516). The earliest 'obliterate' could get into Subversion
> would be the 1.6 release. You may wish to wait until 1.5 is out, or
> at least in release candidate stage, before starting this discussion.
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
The Spidernet Web Design
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)
Received on 2008-02-18 04:38:56 CET
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org