B. W. Fitzpatrick <fitz@red-bean.com> writes:
> I think that you've got some excellent ideas, and they've
> actually been brought up on the list several times in the past.
> I *completely* agree with your sentiments that the earlier we
> can get them into Subversion, the better. However, I can go
> through the issue tracker and find at least 15 other features
> that I feel the same way about.
>
> My point here is this: Subversion has been in development for
> three and a half years now and has not yet gotten to 1.0.
> Every feature we add, however small, takes time from the
> committers". It doesn't matter if someone submits a perfect
> patch complete with tests, documentation, etc--each new feature
> takes time to review and apply. Most importantly, edge cases
> come up, new bugs are discovered at a later date, and a million
> other small things happen that push 1.0 further away, one
> minute at a time.
You make a very good point. I certainly appreciate how delays
get introduced into the software development process and agree
with you 100%.
> Designing and writing new features is a lot of fun. Hunting
> down and fixing arcane bugs and edge cases is considerably less
> entertaining. It's frustrating to say the least when you're
> head down fixing annoying little bugs and people keep showing
> up with new features to add--features that you'd *love* to be
> designing and writing yourself, but you can't because you're
> pushing for 1.0. Heck, most people would rather write 10 new
> features than fix 1 bug, and 90% of the projects on SourceForge
> are damning proof of that.
Although I agree with you that new features are fun, my
motivation for proposing those ideas is more of a practical
nature. In other words, I brought up issues that I saw as
impediments to adoption. I have in mind many fun features that
I think are best left to post-v1.0. Of course, as always, your
mileage may vary.
> If you really want to see some new features added to Subversion
> sooner rather than later, grab an unassigned pre-1.0 bug and
> help out. Once we hit 1.0, then I'm sure people will be much
> more amenable to adding new features.
I think this is an excellent idea. I will take a look at the bug
list and see where I can lend a hand. However, please do
consider what I'm about to say:
To summarize, these were the four features I proposed:
1) Separate .svn/ meta data directories
2) Explicit file edit
3) Commit list editing
4) Flexible external diff support
As others pointed out on the list, #2, #3, #4 are solved using a
variety of external scripting methods. I can agree with these
solutions in the short-term, and given your thoughts on getting
to v1.0, I can certainly live with workarounds until post-v1.0.
However, I feel more strongly about #1, and I respectfully ask
everyone to take this into consideration for v1.0. The feature
is not easily scripted around (unless somebody can think of an
idea for a solution). Also, unless I'm missing something, it
should be relatively straightforward to implement and test in the
client.
It takes extra effort to work with a workspace that has
directories and files that don't belong to the project. In my
opinion, I would rather aggregate that extra effort and solve the
problem once in SVN. After this is done, all of the popular text
and data processing tools (find, grep, awk, sed, perl, tar, etc)
can be run without having to explicitly exclude the .svn/
directories. In my experience, there is great value in working
within a pristine workspace.
In any case, in deference to your points, I am happy to pick up
some pending tasks and try to resolve them to the best of my
ability. Before that, I do need to implement #1 for myself at
the very least. If my patch cannot be reviewed and accepted, I
suppose I can maintain a private patch for myself to apply
against new releases. Having said that, however, I would most
appreciate if the patch could be reviewed for inclusion into the
trunk.
Best Regards,
Kumaran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 24 02:35:27 2003