On 15 October 2012 20:05, Nico Kadel-Garcia wrote:
> Understandable, but it can really bite the next person who works with
> your scripts or material. I've encountered a lot of adventures with
> non-7-bit-ASCII character sets over the years, and it leads to me
> doing a lot of sanitizing of filena
On 15 October 2012 18:53, Nico Kadel-Garcia wrote:
> So why do you do it? Similar to putting spaces and question marks and
> quotation marks in file names, it can cause a lot of scripting
> confusion for your hook scripts.
I did it once, because I didn't realise it would cause problems, and
it co
On 15 October 2012 17:30, Stefan Sperling wrote:
> The square brackets are wildcard syntax saying "match any of the characters
> listed within the brackets". This is part of the syntax of the fnmatch()
> standard C function
Oh, that makes sense now. That's not the first time I've been bitten
by u
x27;t work, maybe it's the "["
characters or somesuch. Obviously you need to be a bit careful that
your patterns aren't too general; in my case those five-digit numbers
are a unique enough pattern to work for me.
— Jason
On 15 October 2012 09:57, Jason Heeris wrote:
> I
;m not
really able to try a lot of trial and error.
All of this is done on Windows Server 2003. Versions of both svnadmin
and svndump are 1.7.5 (r1336830), and they're the binaries that come
with VisualSVN server 2.5.5.
Please CC me on replies.
— Jason Heeris
On 12 July 2012 17:51, Jason Heeris wrote:
> I don't really know *what* constraints there are on honouring existing
> authz file syntax, whether or not it's explicitly specified.
Thorsten Schöning said: "How about just telling svn explicitly which
parse mode for section n
The issue is filed as #4204:
http://subversion.tigris.org/issues/show_bug.cgi?id=4204
— Jason
On 12 July 2012 17:45, Bert Huijben wrote:
> [Please try to keep the mails in plain-text]
Oops, my apologies!
> Things might be simpler when defining that lines that start with ‘[‘ and
> end with ‘]’ should parse everything in between as section markers.
> But then, I don’t know how that affect
On 12 July 2012 17:28, Johan Corveleyn wrote:
> I think the only character that causes problems is ']' (which ends the
> section name parsing). It seems not too hard to change that parsing
> function to make it handle some kind of escape sequence for ']'
> (perhaps ']]'). Would you care to write
On 12 July 2012 08:03, Jason Heeris wrote:
> I'll file it later today and see what response I get.
>
Apparently I need a buddy with whom to file the bug. If anyone would be
willing, I'd appreciate it.
I've attached a bash script that reproduces the problem under SVN 1
On 11 July 2012 23:01, Matthew Pounsett wrote:
> I note by your examples that you're using a unix filesystem (as opposed to
> Windows). I would be a little surprised if this worked there, since the
> square brackets are normally used by unix shells as glob metacharacters,
> similarly to * and ?.
(Please CC me on replies, I'm not subscribed to the list.)
My basic problem is: I want to restrict access (read and/or write) to paths
that contain spaces, square brackets and '#'s.
The details: I have an application that uses an SVN repo to store file
attachments. The paths to these attachments
I'm using PySVN to manipulate a working copy, and I'd like to do
sensible things on error conditions. This involves differentiating
between the errors that could occur — I'd like to do something
different for "File already exists" than, say, "Repository on fire".
As far as I can see, the best way t
13 matches
Mail list logo
