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 Mon, Oct 15, 2012 at 7:21 AM, Jason Heeris wrote:
> 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 onc
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 Mon, Oct 15, 2012 at 5:40 AM, Jason Heeris wrote:
> 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 ma
On Mon, Oct 15, 2012 at 05:40:42PM +0800, Jason Heeris wrote:
> 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
>
>
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
On Mon, Oct 15, 2012 at 12:56:40PM +0800, Jason Heeris wrote:
> Okay, I managed to cheat a bit, so I'm sharing my workaround here. In
> my includes file, I used the form:
>
> /specs*01234*
>
> ...and for the directories:
>
> /results/RST-0001 (v0.01) #001*
>
> ...and now everything seems to
Okay, I managed to cheat a bit, so I'm sharing my workaround here. In
my includes file, I used the form:
/specs*01234*
...and for the directories:
/results/RST-0001 (v0.01) #001*
...and now everything seems to be expunged that should be.
I have no idea why the original form doesn't work, m
I am trying to use svndumpfilter to remove specific files and
directories from a repository dump, but I can't seem to remove all of
them.
Some of the files are, for example:
/specs/[01234] product x spec.pdf
There are other files in other top-level directories, but they all
have that "[x]"
