You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Ciprian Dorin, Craciun" <ci...@gmail.com> on 2009/11/21 08:46:26 UTC
Subversion file name restriction
Hello all!
Is there a restriction in the file names for Subversion (I have
version 1.6.5). Because I can not refer to files that have an `@`
character in their name. For example:
svn add ./something@somehost.com
says something like: `./somenting does not exist`
But if I do `svn add --force .` then the file
`something@somehost.com` is added.
Thanks,
Ciprian.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422715
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 21, 2009 at 04:49:28PM +0200, Ciprian Dorin, Craciun wrote:
> 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.
We do it for this case:
$ svn add @foo
svn: '@foo' is just a peg revision. Maybe try '@foo@' instead?
But not for:
$ svn add fo@o
svn: warning: 'fo' not found
$
This could be improved...
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2423259
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Nov 23, 2009 at 10:25:22AM +0100, Andreas Schweigstill wrote:
> > 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"...
>
> It is not neccessary to read the book once a year but prior to write
> questions to the mailing list.
The trick is to know what to look for in the book.
I knew to look for "peg revision" and quickly found the relevant
section of text in the book (within a couple of seconds).
To know what to look for you need experience with the tool,
and experience with looking up answers to questions in the Subverison
book (know how the book is structured, etc.). Which implies that,
when you look up the first few answers, it will take you a bit
longer, but once you've done it a few times you become much quicker.
> > 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.
>
> Subversion is used in lots of shell scripts and makefiles, so it would
> be highly risky to change it's behaviour.
I'd rather tune the command line for interactive use than for scripts.
We have stable APIs scripts can use.
Which does not mean having the client ask the user lots of questions.
But suggestions in error messages can help a lot to help users understand
potentially confusing behaviour. For example, Mercurial developers have
done a very good job at this. Mercurial can be learned very quickly
because of little helpful non-obtrusive hints they place into the output.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2423263
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Nov 23, 2009 at 12:13:25PM +0200, Ciprian Dorin, Craciun wrote:
> On Mon, Nov 23, 2009 at 11:25 AM, Andreas Schweigstill
> > Especially on this mailing list there are lots of people who say: "This
> > project is highly important for my company and me, so I *won't* RTFM and
> > prepare myself but instead require the best support for free from the
> > community. The community should be proud to be allowed to support me!"
> So, nowhere in my posts I've implied <<project is highly important
> for my company and me, so I *won't* RTFM and [...]>>.
I don't think Andreas was making an accusation directed at you.
Rather, he was talking about the context of the list you are posting to.
Understanding the context helps understand people's reactions to your own
posts. People don't clear everything they know about this list from
memory before reading new posts.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2423267
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by "Ciprian Dorin, Craciun" <ci...@gmail.com>.
On Mon, Nov 23, 2009 at 11:25 AM, Andreas Schweigstill
<an...@schweigstill.de> wrote:
> Hello!
>
> Ciprian Dorin, Craciun schrieb:
>> 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.)
>
> Especially on this mailing list there are lots of people who say: "This
> project is highly important for my company and me, so I *won't* RTFM and
> prepare myself but instead require the best support for free from the
> community. The community should be proud to be allowed to support me!"
Initially I didn't want to continue anymore with this thread, but
it seems I'm too weak... :)
So, nowhere in my posts I've implied <<project is highly important
for my company and me, so I *won't* RTFM and [...]>>. But instead if
you read more closely my post above you'll see: <<[...] it makes the
difference between "this is where your question is answered", and "you
should have known better>>.
>> Agree again. But a mailing list usually provides a quicker
>> solution, and saves wasted time (for the user).
>
> So what? There are no service level agreements between a normal user
> and a community mailing list.
>
>> Agree again. But quick answers are usually more useful than an
>> hour spend reading a documentation.
>
> So why not make a contract with a paid consultant?
And that's why no-one is obliged to reply to posts...
>> 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.
>
> But that means that about thousand people have to spend one second just
> to read the subject. This is more than a quarter of an hour. So this
> creates costs of about 20$ to the community.
So then it means that your reply and my new one just costed the
entire community another 40$... :(
>> 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"...
>
> It is not neccessary to read the book once a year but prior to write
> questions to the mailing list.
>
>> 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.
>
> Subversion is used in lots of shell scripts and makefiles, so it would
> be highly risky to change it's behaviour.
Here I agree with you. I didn't proposed to update the behavior,
but just maybe to show a notice to the user in case an error happens
and the file name contains a '@'.
> Regards
> Andreas Schweigstill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2423264
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Ciprian Dorin, Craciun schrieb:
> 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.)
Especially on this mailing list there are lots of people who say: "This
project is highly important for my company and me, so I *won't* RTFM and
prepare myself but instead require the best support for free from the
community. The community should be proud to be allowed to support me!"
> Agree again. But a mailing list usually provides a quicker
> solution, and saves wasted time (for the user).
So what? There are no service level agreements between a normal user
and a community mailing list.
> Agree again. But quick answers are usually more useful than an
> hour spend reading a documentation.
So why not make a contract with a paid consultant?
> 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.
But that means that about thousand people have to spend one second just
to read the subject. This is more than a quarter of an hour. So this
creates costs of about 20$ to the community.
> 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"...
It is not neccessary to read the book once a year but prior to write
questions to the mailing list.
> 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.
Subversion is used in lots of shell scripts and makefiles, so it would
be highly risky to change it's behaviour.
Regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2423254
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by "Ciprian Dorin, Craciun" <ci...@gmail.com>.
On Sat, Nov 21, 2009 at 3:47 PM, Stefan Sperling <st...@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 <st...@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 <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Stefan Sperling <st...@elego.de>.
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 <st...@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.
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?
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.
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.
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.
Locating information in the documentation is quicker than sending a
question to the mailing list and waiting for replies. It saves time.
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.
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.
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.
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422781
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by "Ciprian Dorin, Craciun" <ci...@gmail.com>.
On Sat, Nov 21, 2009 at 3:06 PM, Ryan Schmidt
<su...@ryandesign.com> wrote:
> On Nov 21, 2009, at 06:44, Ciprian Dorin, Craciun wrote:
>
>> On Sat, Nov 21, 2009 at 1:58 PM, Stefan Sperling wrote:
>>> [...]
>>> It helps to read the book....
>>
>> Thank you for your feedback. I shall try that.
>>
>> 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);
>> * 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...)
>> * 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)...
>>
>> 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...
> To be fair, the Subversion community is actually pretty awesome. There are tons of people subscribed giving answers to tons of questions every day. Just check the volume of messages in the archives to see how big the community is. I answered your original email and provided you a link to a workaround for your issue within 9 minutes of you posting it; I think that's pretty awesome too.
Yes, I was positively impressed that you've quickly given me the
right answer. And this was enough for me to correct my wrong doing.
(And to be clear I was not referring to you in my previous email.)
I'm also a member of this mailing list since two or three years
ago, and I quietly skim through the subjects. (There were only a few
threads that I've actually followed closely, and their were related
with mainly what opportunities did SVN opened.)
> Occasionally there will be a rebuke on the list (perhaps sometimes sounding harsher than intended) about not having read the book or a FAQ entry, but that's because the book is so thorough and well-written and even fun to read and the FAQ has so many pertinent answers in it. They really are worth a look and will increase your understanding of Subversion.
Yes I agree that the book is well written, especially in the
end-user area (but there are still rough edges in the back-end
(server-side) area...)
And I have read the book about three-or four years ago, and indeed
it was pleasant to read. But unfortunately I forgot all the
"fine-print" details.
> And once you've gotten used to Subversion's quirks (and what tool doesn't have some of those), I think you'll agree (if you don't already) that it's a pretty great tool.
:) Yes it's true that Subversion is the best (open source) tool
for most use cases. For example I'm currently using SVN to allow my
students to upload their projects. This enables me to impose
deadlines, allow team work, isolate different teams from seeing their
code, and to enforce what they upload (for example I disallow
binaries)...
Thanks again,
Ciprian.
P.S.: Unfortunately for my own projects, I've migrated to Git. :(
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422736
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 21, 2009, at 06:44, Ciprian Dorin, Craciun wrote:
> On Sat, Nov 21, 2009 at 1:58 PM, Stefan Sperling wrote:
>> [...]
>> It helps to read the book....
>
> Thank you for your feedback. I shall try that.
>
> 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);
> * 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...)
> * 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)...
>
> 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...
To be fair, the Subversion community is actually pretty awesome. There are tons of people subscribed giving answers to tons of questions every day. Just check the volume of messages in the archives to see how big the community is. I answered your original email and provided you a link to a workaround for your issue within 9 minutes of you posting it; I think that's pretty awesome too.
Occasionally there will be a rebuke on the list (perhaps sometimes sounding harsher than intended) about not having read the book or a FAQ entry, but that's because the book is so thorough and well-written and even fun to read and the FAQ has so many pertinent answers in it. They really are worth a look and will increase your understanding of Subversion.
And once you've gotten used to Subversion's quirks (and what tool doesn't have some of those), I think you'll agree (if you don't already) that it's a pretty great tool.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422733
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Les Mikesell <le...@gmail.com>.
Ciprian Dorin, Craciun wrote:
>
>
> 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...
>
If you aren't going to read the documentation even after someone quotes it for
you, good luck with that. Subversion has some complicated features and quirks
that are better if you understand them yourself instead of blindly following
someone's random suggestions.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422833
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by "Ciprian Dorin, Craciun" <ci...@gmail.com>.
On Sat, Nov 21, 2009 at 1:58 PM, Stefan Sperling <st...@elego.de> wrote:
> [...]
> It helps to read the book....
>
> Stefan
Thank you for your feedback. I shall try that.
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);
* 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...)
* 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)...
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...
But, thanks anyway,
Ciprian.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422730
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 21, 2009 at 02:55:21AM -0600, Ryan Schmidt wrote:
> On Nov 21, 2009, at 02:46, Ciprian Dorin, Craciun wrote:
>
> > Is there a restriction in the file names for Subversion (I have
> > version 1.6.5). Because I can not refer to files that have an `@`
> > character in their name. For example:
> > svn add ./something@somehost.com
> > says something like: `./somenting does not exist`
> >
> > But if I do `svn add --force .` then the file
> > `something@somehost.com` is added.
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3489
>
> says you need to escape the @ character because it is special to Subversion.
And it's even in the documented, not just the bug tracker:
Quoting http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
The perceptive reader is probably wondering at this point whether the peg
revision syntax causes problems for working copy paths or URLs that actually
have at signs in them. After all, how does svn know whether news@11 is the name
of a directory in my tree or just a syntax for “revision 11 of news”?
Thankfully, while svn will always assume the latter, there is a trivial
workaround. You need only append an at sign to the end of the path, such as
news@11@. svn cares only about the last at sign in the argument, and it is not
considered illegal to omit a literal peg revision specifier after that at sign.
This workaround even applies to paths that end in an at sign—you would use
filename@@ to talk about a file named filename@.
It helps to read the book....
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422728
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Subversion file name restriction
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 21, 2009, at 02:46, Ciprian Dorin, Craciun wrote:
> Is there a restriction in the file names for Subversion (I have
> version 1.6.5). Because I can not refer to files that have an `@`
> character in their name. For example:
> svn add ./something@somehost.com
> says something like: `./somenting does not exist`
>
> But if I do `svn add --force .` then the file
> `something@somehost.com` is added.
http://subversion.tigris.org/issues/show_bug.cgi?id=3489
says you need to escape the @ character because it is special to Subversion.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422717
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.