cmpilato@collab.net wrote:
>
>"Files" <files@poetryunlimited.com> writes:
>
>> Blair,
>>
>> Did you know that your issue #1455
>> (http://subversion.tigris.org/issues/show_bug.cgi?id=1455) which you
>> reported on 2003-07-31 15:16 PDT is really inapplicable according to
>> Michael in issue #1356
>> (http://subversion.tigris.org/issues/show_bug.cgi?id=1356) as
>> exhorbitantly long processing times for large projects which I
>> successfully reported along with a potential fix or an offer to help
>> code a fix on 2003-06-13 09:04 PDT, "since this doesn't really have
>> anything to do with Subversion proper's usability."
>>
>> This is a wake up call, IMHO.
>
>Dude, you've simply misunderstood what the 'inapplicable' milestone
>means. We use that milestone marker not as an indication of priority
>or severity -- it just let's us know that we could ship a perfectly
>healthy Subversion product without addressing that issue. It's not
>like I closed the issue as "INVALID" or "WONTFIX".
Dude, I hate to break it to you, but it ceased to be a "subversion works the way it
needs to" issue when I couldn't load 6 months worth of backups into a repository
because it starts taking exponentially longer and longer amounts of time to do each
revision using the bundled svn_load_dirs.pl.
The documentation says subversion can do vendor branches. That's why I picked it.
It came with a tool that made use of the feature, so I used it.
I had no idea it was completely production unready.
And I guess it sucked that I fixed the problem and then posted the issue asking if
you wanted the fix.
It took Perl.com reporting the same problem for you guys to fix it yourselves.
That's the real meat of the problem.
When someone is posting an issue WITH a solution, is it time to say "This is
inapplicable in this release"????
I specifically asked if you wanted it or if someone was working on it.
I got coddled in return. "Oh, it's no big deal".
It is a big deal because I was going out of my way to make sure that this product
could be proven in a production environment.
The issue was never that subversion itself was butt-slow -- I never thought it was
slow.
The issue was the perl script was dumping hundreds of megs of data unnecessarily -
especially branches that had no REAL storage, but only virtual storage - all the
tags directories were being exported as real files.
This in turn made the whole repository grow. At one point I had nearly a gig of
data from a repository that was only 200 megs in size.
I HAD to fix it to make use of it. I was attempting to give back to the community
and got a fly swatter in return.
>svn_load_dirs.pl is a tool to help folks do certain Subversion tasks
>more easily -- it's not a part of "Subversion", per se. Sure, we want
>to make sure it runs as fast as possible. But we have to focus on the
>core first. If svn_load_dirs.pl is butt-slow because Subversion
>itself is butt-slow, well, we fix Subversion and -- score! -- the
>secondary issue just falls out of that process.
>
>> P.S. You should be able to report a bug/post a fix w/ an email
>> address w/o needing to be fully registered. That just seemed way too
>> much effort to just HELP you guys out. I almost didn't do it. If you
>> have my return email address, and the stuff I sent you, it's easy to
>> check the validity of the posting. For mailing lists, yes, I would
>> have to agree. Other than that, it's just one more place w/ a
>> password to remember for no good reason other than someone saw fit
>> to do so.
>
>Again, you're missing the point. We specifically ask folks to post to
>the mailing list with their bugs and *not* file an issue in the
>database. Why? Well, it could be that their issue has already been
>addressed, and they don't know it. It could be that their issue
>raises serious theoretical concerns that we want to hash out on the
>list before filing an issue/plan for solving. But mostly, it's just
>easier to send an email to our list than to register on tigris.org and
>file an issue. You don't have to be registered to email our list.
>
>We *want* folks to help us out. And we *want* to help folks.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
I would have to disagree with this. I'm not trying to draw out this argument.
I'm pointing out that I posted specifically because I had found an answer - I HAD
the solution to the bug.
And then I got told you didn't need my help. That's your prerogative.
In order for me to believe you want help, I will need to see different behavior.
That's about all it amounts to.
End of line.
Shamim Islam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 25 17:33:48 2003