You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Files <fi...@poetryunlimited.com> on 2003/08/21 14:21:06 UTC
Blair, re issue 1455 in v0.27
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.
Just on the odd chance that you're wondering, I used the svn_load_dirs.pl to load 6
months worth of backups to 3 large codebases. The load took hours. And hours. And
hours. And had to be repeated at times, because the svn_load_dirs.pl couldn't
handle situations where there were newer files to be added as compared to the
original and so on. Those were minor irritants at the time given that the repeated
restart (I had to even figure out a way to start where I left off instead of
starting over) requirement due to db4 breaking down every now and then.
I work at an insurance company. I have been working in the computer industry since
1988 (Ontario government straight out of high school, Gateway 2K, FedEx, Kellogg,
Old Kent Bank, Meijer Corporate, etc), I have to say, that I feel truly and utterly
stepped on in that I as a simple user cannot be anything other than just making
noise, and it takes a publicly visible project like Perl to make things worth
fixing.
Come on guys. That's not what this is about. It's about listening to what someone
is saying and asking them the conditions under which they're operating and finding
out if what they're saying may actually have some merit.
Isn't it?
Grassroots is always where it's been at. Hasn't it? If you step on your fellow
commoners, you risk alienating your potential developer base, as well as your low
level user-base that can recommend your software's use at higher levels.
Originally, when I encountered subversion, I was ecstatic that someone was working
on something in this manner which seemed to match what Knuth and Sedgewick would
have been proud of. I was even wondering how I could get involved.
Now I'm more inclined to sit back and see what, or if you fix a bug and much less
inclined to report anything, and hoping maybe that someone will come out with the
next best thing to revision control to supercede subversion.
Do you see a problem here? I do. Subversion is a great product. But you've managed
to make me less than a believer with nothing more than a mouse click, whereas you
could have had a staunch supporter, ally and possibly contributor.
My posting in the uesrs mailing list is understandably more light-weight. I think
you guys can fix the problem before it becomes systemic.
Shamim Islam
BA Life Sciences 91
BS Computer Science 95
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blair, re issue 1455 in v0.27
Posted by Paul Lussier <pl...@lanminds.com>.
On Thu, 2003-08-21 at 10:34, Ben Collins-Sussman wrote:
> But I have to say, IMHO, I think the developers on this project do
> more tech support, hand-holding, and generally pay more attention to
> users than almost any other open source project I've seen.
I have to agree with this. I've on dozens of open source lists over the
years usually being a seeker of support. I've been so impressed with
the svn list(s) to the point of joining the team (I'm not sure if it's
that they made me feel that welcome, or they just needed a warm body and
there weren't any chimps available ;)
--
Seeya,
Paul
GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blair, re issue 1455 in v0.27
Posted by Ben Collins-Sussman <su...@collab.net>.
"Files" <fi...@poetryunlimited.com> writes:
> Now I'm more inclined to sit back and see what, or if you fix a bug
> and much less inclined to report anything, and hoping maybe that
> someone will come out with the next best thing to revision control
> to supercede subversion.
>
> Do you see a problem here? I do. Subversion is a great product. But
> you've managed to make me less than a believer with nothing more
> than a mouse click, whereas you could have had a staunch supporter,
> ally and possibly contributor.
Files,
Sorry you feel stepped on. We get dozens of problem reports every day
(in issuezilla, IRC, and email), and 80% of them turn out to people
who are confused with how to use the software, or people who didn't
read the docs, or people who just don't understand Unix. For the
remaining 20%, we try to figure out if the problem report matches any
of our existing filed bugs -- and if it's new, we file it. On top of
that, we have a huge triage system going on. We try to decide whether
the bug is worth "holding" up a 1.0 release for or not.
So amazingly, some reports *do* slip through the cracks from time to
time, and misunderstandings *do* happen. It's inevitable. There's no
system of discrimination going on.
But I have to say, IMHO, I think the developers on this project do
more tech support, hand-holding, and generally pay more attention to
users than almost any other open source project I've seen. I'm sorry
you feel differently.
> 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 personally agree with your complaint here -- but that's just the way
tigris.org (and sourcecast) works. It assumes that people filing bugs
want to participate in the community for the longer term. That may or
may not be a good design decision, but that's an off-topic discussion.
In the meantime, we actually *don't* like it when a new person posts a
new issue unexpectedly. We try to keep our issue-tracker neatly
pruned and organized, and as I said before, random issue filings tend
to be dups or non-bugs 80% of the time. That's why we ask people to
post their problem to the users@ list first (which requires no
registration anyway.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blair, re issue 1455 in v0.27
Posted by Blair Zajac <bl...@orcaware.com>.
Files wrote:
>
> 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."
Patches to fix issues like this are always welcome. You don't
have to ask to send them out.
Also, I may have missed your offer to help, since I don't read every
message to the mailing list, unless it has svn_load_dirs.pl in the
subject.
> Just on the odd chance that you're wondering, I used the svn_load_dirs.pl to load 6
> months worth of backups to 3 large codebases. The load took hours. And hours. And
> hours. And had to be repeated at times, because the svn_load_dirs.pl couldn't
> handle situations where there were newer files to be added as compared to the
> original and so on. Those were minor irritants at the time given that the repeated
> restart (I had to even figure out a way to start where I left off instead of
> starting over) requirement due to db4 breaking down every now and then.
Have you tried the latest version of svn_load_dirs.pl that is distributed
with 0.27.0? It fixes the huge checkout issue.
I'll be closing 1356 since 1455 was the same issue.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Blair, re issue 1455 in v0.27
Posted by cm...@collab.net.
"Files" <fi...@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".
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