[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion file name restriction

From: Ciprian Dorin, Craciun <ciprian.craciun_at_gmail.com>
Date: Sat, 21 Nov 2009 16:49:28 +0200

On Sat, Nov 21, 2009 at 3:47 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Nov 21, 2009 at 02:44:52PM +0200, Ciprian Dorin, Craciun wrote:
>> On Sat, Nov 21, 2009 at 1:58 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > [...]
>> > It helps to read the book....
>> >
>>     Thank you for your feedback. I shall try that.
>
> I hope that you will enjoy reading and learning from the Subversion book.
>
>>     But on the other side, I want to make a small remark. The most
>> important element of open source projects are their community. If
>> there is no community, it means that there are no developers, and
>> there are no users. Also from the community it stems something else:
>> mutual non-profit help. By this I mean that if someone has a question
>> (even the most silliest one), and he sends an email to the community
>> mailing list, the usual outcome (depending on the community) is:
>>     * someone gives a polite answer correcting him, or pointing him to
>> the correct place (like one of the repliers to this email has done);
>
> I pointed you to the correct place in the documentation.
> I did it because the other poster pointed you to the bug tracker,
> and the bug tracker is not the place to get documentation.
>
>>     * he is ignored (usually happens with projects governed by
>> elitists, which have forgotten that their were once newbies (I've seen
>> a lot of these kind)); (and eventually the user will end-up RTFM, but
>> mumbling because he has to loose a couple of hours reading the
>> "Advanced" part of the (RT)FM just to clarify a very simple issue...)
>
> Posts can also be ignored because no one has the time to read
> them or answer to them, without any malicious intent.
>
>>     * or seldom someone just sends him to RTFM... (which is even worse
>> than ignoring him in the first place, because now he's indirectly
>> called an ignorant)...
>
> I don't agree, at all, that sending an RTFM response is bad.
> It is 101% good, provided the user gets pointed to the correct
> place in the documentation.

    I agree with this (that a pointer to the documentation is the best
solution). But the way someone says it makes the difference between
"this is where your question is answered", and "you should have known
better". (And this usually makes a difference for a newbie.)

> If the answer to the question which was asked is in the documentation
> already, then why not point people there instead of writing the
> documentation again on the mailing list, duplicating efforts?

    (See above.)

> Writing good documentation takes a lot of time.
> The authors of the book wrote the book so that they won't have to spend
> time again and again answering questions they already answered.

    Agree. That's why the authors are not obliged to answer.

> Pointers to where people can find the most current documentation are
> better than mailing list posts that can never be updated.
> The documentation is being maintained, mailing list posts are simply
> archived.

    Agree again. But a mailing list usually provides a quicker
solution, and saves wasted time (for the user).

> The official documentation tends to be more complete and well-written,
> and is more suitable as learning material than mailing list posts,
> because documentation can incrementally introduce concepts that build
> on one another.
>
> Pointing people to the documentation helps people help themselves,
> because they might discover that the documentation contains a lot
> of information, more than they need right now. But they may need more
> information on other topics later and now know where to go to get it.

    Agree again. But quick answers are usually more useful than an
hour spend reading a documentation.

> Locating information in the documentation is quicker than sending a
> question to the mailing list and waiting for replies. It saves time.

    Disagree completely. Documentation should be used as reference,
and as comprehensive guide. But for quick problems a mailing list is
priceless. (Of course that if the answer wouldn't have come for a
couple of hours, I would have started searching in the documentation.)

> Because sending a question to a huge list like this means that a couple
> of hundred people will spend some of their time processing the question.
> This makes the list a huge and valuable resource of expertise that we
> all can tap into, but it should not be abused to get answers to questions
> that are already answered by the documentation.

    This I don't agree with. For example I'm subscribed to about 50
mailing lists, and I usually only read the subject, and if it matches
with my interest then I look closer. Thus no great overhead.

> Of course, such questions pop up here, and that's fine since people are
> free to ask anything. But they will most likely end up getting redirected
> to the documentation, by people who have already read the documentation
> and know where in the documentation the answer is located.
>
> This is why I said "reading the book helps" -- I meant to suggest that
> you should try to locate information there first, because it will save
> you and everyone else time, and because it will give you a better
> learning experience. This really is the "mutual help" you mentioned above,
> and mutual implies effort on your part, too.

    As I said previously I've read the book once a few years ago, but
forgot the small details. Thus I didn't see any point in rereading the
documentation every year, just to keep up with the "fine prints"...

> I could have worded it in a less grumpy way, but it was well intended.
>
>> So my two cents opinion: rather than using an awesome tool, I
>> would prefer to use a sh...ty tool, but with an awesome community...
>
> I didn't mean to offend, sorry.

    Maybe I over reacted a bit... So sorry also from my part. :) (I
suggest we leave this to settle and fade away.)

> I tend to give quick RTFM responses to questions that pop up repeatedly,
> and which are covered in the documentation (e.g. the "@" in filename
> question comes up quite often and is documented).
> If a question shows that something in the book is missing, I make changes
> to the book either instead or in addition to answering the question on the
> mailing list. This wasn't the case with your question, so you got the RTFM
> response.
>
> Stefan

    If the same issue keeps popping up every once in a while, then it
means that the problem in question raises from counter-intuitive
behavior of the tool. So maybe the tool should be enhanced so that if
a user uses a `@` in the file name and there is an error, a suggestion
should be printed.

    So thank you for allocating time to reply.
    Ciprian.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422787

Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-21 15:50:28 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.