date:20101201

On Dec 1, 2010, at 06:45, benstoe...@aol.com wrote:

> I'm developing and hosting an open source project 
> (treegraph.bioinfweb.info) and want to start using subversion to
> manage the source codes (including a webinterface with sventon).
> Until now the source codes revisions were organized manually without
> any version controol system in formof f backups and the current 
> revision is 197. I have already set up a svn server with an empty 
> repository and want the revision numbers in svn to start with 198, 
> when uploading my source codes there, to avoid having different 
> revision numbers in svn and the download section of the website. 
> Is there any way to set an initial revision number when doing the 
> first import to svn?
>  
> I have not found any information on that, and the only idea I have
> until now is to make 197 more or less senseless commits before 
> committing the first real change to my source codes. I would really
> appreciate if anyone known a more elegant (and faster) way of doing
> that.

Creating 197 throwaway revisions is the only thing that occurs to me as well.

However, the revision number is really only "the number of changes that have 
been made to the repository" so you shouldn't attach too much meaning to it.

If you have kept backups of each (or some) of your existing 197 revisions that 
you managed by hand, perhaps you'd like to import these into the repository. 
You could use the svn_load_dirs.pl script to help you with this, assuming each 
revision is in its own complete directory somewhere. Then your 197 revisions in 
the repository wouldn't be senseless; they'd be your existing history.

How can i export a file named "a[.txt" by SVN.EXE

2010-12-01 Thread embedmobile y

How can i export a file named a[.txt by SVN.EXE.
When i try to use svn.exe to export a file whose name consists '[', it will
fail and error info as "svn: URL 'svn://127.0.0.1/test/a[.txt' is not
properly URI-encoded".
If i use TSVN, it can export successfully. But i can only use CLI. So how
could i export such kind of file by svn.exe?
My enviornment is winxp and SVN version 1.5.4 or 1.6.11.
Thanks for your kindly help.

Re: How can i export a file named "a[.txt" by SVN.EXE


On Dec 1, 2010, at 06:51, embedmobile y wrote:

> How can i export a file named a[.txt by SVN.EXE.
> When i try to use svn.exe to export a file whose name consists '[', it will 
> fail and error info as "svn: URL 'svn://127.0.0.1/test/a[.txt' is not 
> properly URI-encoded".
> If i use TSVN, it can export successfully. But i can only use CLI. So how 
> could i export such kind of file by svn.exe?
> My enviornment is winxp and SVN version 1.5.4 or 1.6.11.
> Thanks for your kindly help. 

Properly (percent-)encode the special characters in the URL, i.e.:

svn://127.0.0.1/test/a%5B.txt

RE: svn diff: output stops after first couple hunks?

2010-12-01 Thread Cooke, Mark

> -Original Message-
> From: Laird Nelson [mailto:ljnel...@gmail.com] 
> Sent: 01 December 2010 13:01
> To: Cooke, Mark; users@subversion.apache.org
> Subject: Re: svn diff: output stops after first couple hunks?
> 
> > On Wed, Dec 1, 2010 at 3:32 AM, Cooke, Mark 
> >  wrote:
> > 
> > 
> > ...it sounds like you are expecting `diff` to check against the
latest
> > version in the repository.  This is not what happens, at least using
> > the command as you provided above.
> > 
> 
> You know, I have read words to that effect before, but 
> haven't ever really properly thought about the ramifications.
> 
> 
> > Most operations within a working copy use the latest known pristene
> > copy as the reference (i.e. the copy stored from the _last_ update
of
> > _this_ wc in your .svn subdirectories).
> > 
> > Does that explain the differences you are seeing?
> > 
> 
> I believe it does.  So, to be very clear, she is computing 
> differences between her working copy, and the version that 
> was the result of the last svn update, whenever that happened 
> to have occurred?
> 
Exactly.  Subversion minimises the network traffic by storing the latest
known 'master' locally.  When you do a commit, only the diffs are sent
across the network, hence one reason why a commit will fail if your WC
is not updated...

> I suppose then if I really wanted to do the diff properly 
> (read: against the copy in the repo) I would do:
> 
>   svn diff pom.xml http://path.to/my/svnrepo/myproject/trunk/pom.xml
> 
> ...that is, diff the working pom.xml against the copy stored 
> in the repository?  (I don't have the command or the manual 
> up right now, so I may have left off an argument or two, but 
> hopefully you get the idea.)
> 
While you can do that, most people would simply update the working copy
and then do the diff locally.  You will not be able to commit until you
have updated anyway.

An update will bring in any changes that others have made but these
generally merge silently with your changes and any conflicts will be
flagged for resolution.  This is one reason for updating regularly,
these merges seem to work best when taken in smaller increments!

By the way, do you know the online subversion book
(http://svnbook.red-bean.com/)?  It is very good and the first two
chapters should be compulsory reading for all users.  The `svn diff`
reference is here:
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.diff.html

~ mark c

Re: How to find out the rev number where a file was deleted?

2010-12-01 Thread Les Mikesell


On 12/1/10 5:30 AM, Andrey Repin wrote:



What database operation is fast when it has to follow recursive
self-references in the same table?


SELECT operation, even on a multitude of arguments, is relatively fast.
Hell, even UNION JOIN over a NetFlow data is just about a few seconds.


You miss the point that you have to join the table with another field in the 
same table.  This is not going to be fast.



Nota a concern. Mainline go on and at some point die (if at all), giving all
sort of hints, as to where to look further, in process.


It might. Or a file could be moved in every revision.


svn log -r 0:head file://${HOME}/trash/repo/f...@3

It only looks in head because that command asks it for the history of
head.


No.
Really, I see this as pointless discussion. You absolutely don't hear my
arguments.


Same from this side...


P.S.
Please don't use "reply to all" in reply to my posts. It's not a big problem
deleting a few more messages from my inbox, still it's disturbing.
TIA.


That's the way mailing lists have always worked.  Unless the Reply-To: header is 
set to go back to the list, you have to use reply-all to get one to go to the 
list.   This list doesn't set it, but you can set it yourself if you want to 
control where replies go.


--
  Les Mikesell
   lesmikes...@gmail.com

Upgrade OS/400 from V5R4 to V7R1

2010-12-01 Thread Bob Nason

Hi...

Any issues with Subversion jumping from release V5R4 to V7R1 of the 
iSeries OS/400?

Thanks... Bob

Robert Nason
American Board of Pediatrics, Information Technology
111 Silver Cedar Court
Chapel Hill, NC, 27514-1513 
(919) 918.7107 Ext. 121

"Some people spend an entire lifetime wondering if they made a difference 
in the world.  But the U.S. ARMED FORCESS don't have that problem."  
Ronald Reagan

How to resolve 'directory replaced by symlink' conflicts that come in via a merge ?

2010-12-01 Thread Hans Lambermont

Hi list,

How to resolve 'directory replaced by symlink' conflicts that come in via a 
merge ?
'svn st' says "local obstruction, incoming add upon merge" on such a directory.
Please note that these directories were not locally modified.

svn 1.6.12 used.

ps. please cc me as i'm not subscribed to this list.

regards,
   Hans Lambermont

Re: AW: How to find out the rev number where a file was deleted?

2010-12-01 Thread Les Mikesell


On 12/1/2010 6:40 AM, Ludwig, Michael wrote:



And if you did have the name lookup you want, you still have to
deal with the issue that in every rev where the name is found it
may be some different object.


It is not an issue, Andrey and I mentioned that repeatedly.


I think the functionality he wants is different.


The revision disambiguates the name and provides identity.


It seems like you are asking for what you would get if you collate the 
output of:

svn ls -r? URL
 where you cycle the ? through all the revisions.
That is, you want every instance where the name appears regardless of 
the objects referenced by that name.


I think Andrey wants something more like:
svn log -r0:? u...@peg
  where the ? is the highest rev where the same object was present at 
that path.  Or at least to find the value of that highest rev.


But for me, the question I would want to be able to answer would more 
likely be "where else was this copied?" as in "what release tags include 
this file or its descendants?" or "what is its new name after a move in 
a future rev?"


But we all agree that there are things you might want that you can't do 
easily.  The developers here all use an issue tracking system with 
tickets to discuss the changes being done and always include the ticket 
number in a certain format in the commit message for every commit - in 
fact we just added a pre-commit hook to enforce that.  And I think the 
svn revision that completes/closes an issue goes back to the ticket. 
This doesn't exactly address tracking changes to individual files and 
objects, but at a higher level it connects the purpose of a change with 
the work itself and lets you use a better tool to handle the related 
context, making it less likely that you would need a brute-force search 
for lost items.


--
  Les Mikesell
   lesmikes...@gmail.com

RE: AW: How to find out the rev number where a file was deleted?

2010-12-01 Thread Ludwig, Michael

> From: Les Mikesell [mailto:lesmikes...@gmail.com] 
> On 12/1/2010 6:40 AM, Ludwig, Michael wrote:
> >
> >> And if you did have the name lookup you want, you still have to
> >> deal with the issue that in every rev where the name is found it
> >> may be some different object.
> >
> > It is not an issue, Andrey and I mentioned that repeatedly.
> 
> I think the functionality he wants is different.

It is. But there was overlap in what we said.

> > The revision disambiguates the name and provides identity.
> 
> It seems like you are asking for what you would get if you 
> collate the 
> output of:
> svn ls -r? URL
>   where you cycle the ? through all the revisions.
> That is, you want every instance where the name appears regardless of 
> the objects referenced by that name.

No, but not entirely dissimilar. I gave an example a couple of messages ago.

Best,

Michael

Unable to lock error: what is going on here?



$ svn update
svn: Unable to lock 'utscmd'

$ svn propget svn:ignore
utspkg_src
utscmd
utslib
utsbin
utstool

utscmd is a subdirectory of the current working directory.  It is 
included in svn:ignore.  Why is svn even trying to lock this directory?


The sequence of events here is that the project was checked out and then 
its build command run.  The build command created a number of 
directories, which have been added to svn:ignore so as not to figure in 
svn at all.


What am I failing to understand here?

Steve Cohen

Unable to lock error: what is going on here?



$ svn update
svn: Unable to lock 'utscmd'

$ svn propget svn:ignore
utspkg_src
utscmd
utslib
utsbin
utstool

utscmd is a subdirectory of the current working directory.  It is 
included in svn:ignore.  Why is svn even trying to lock this directory?


The sequence of events here is that the project was checked out and then 
its build command run.  The build command created a number of 
directories, which have been added to svn:ignore so as not to figure in 
svn at all.


What am I failing to understand here?

Steve Cohen

svn:ignore with recursive and non-recursive patterns


I have a need to define a number of svn:ignore patterns in my project.

Some are specific directories somewhere in my project tree.  Others are 
particular file types created by a build process such as *.o which may 
be found in any number of  directories.


However, the svn propset command only allows the recursive -R switch to 
be applied to the entire set of values for the svn:ignore property. 
Whereas what is needed is to be able to apply the recursive switch to 
the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore).  Is there any way of 
achieving this?  There doesn't appear to be one.  Yet without it, 
svn:ignore is useless, or at least too cumbersome to be used well.


Steve Cohen

Re: svn:ignore with recursive and non-recursive patterns


On Dec 1, 2010, at 12:29, Steve Cohen wrote:

> I have a need to define a number of svn:ignore patterns in my project.
> 
> Some are specific directories somewhere in my project tree.  Others are 
> particular file types created by a build process such as *.o which may be 
> found in any number of  directories.
> 
> However, the svn propset command only allows the recursive -R switch to be 
> applied to the entire set of values for the svn:ignore property. Whereas what 
> is needed is to be able to apply the recursive switch to the VALUE(e.g. *.o), 
> not the KEY (e.g. svn:ignore).  Is there any way of achieving this?  There 
> doesn't appear to be one.  Yet without it, svn:ignore is useless, or at least 
> too cumbersome to be used well.

svn:ignore is not useless; it works fine, but doesn't have the feature you're 
looking for.

However, you can set "*.o" in your global-ignores in your Subversion config 
file; in fact it should already be there unless you've changed it.

pattern for specifying svn:ignore for files without extension

The build process of the application I am bringing under svn creates a 
number of unix binary executables that have no extension : for example


abcde
fghqp

etc.

I believe that * will match any files with or without periods so it 
isn't suitable.  Is there a pattern specifier that would embrace all 
files without an extension?


Alternatively, one common differentiating aspect of these files is that 
they have executable privileges.  Being able to svn:ignore based on this 
would be a nice feature to have.

Re: pattern for specifying svn:ignore for files without extension


On Dec 1, 2010, at 13:31, Steve Cohen wrote:

> The build process of the application I am bringing under svn creates a number 
> of unix binary executables that have no extension : for example
> 
> abcde
> fghqp
> 
> etc.
> 
> I believe that * will match any files with or without periods so it isn't 
> suitable.  Is there a pattern specifier that would embrace all files without 
> an extension?

I can't think of a way to do that.


> Alternatively, one common differentiating aspect of these files is that they 
> have executable privileges.  Being able to svn:ignore based on this would be 
> a nice feature to have.

Unfortunately that feature doesn't exist either.

Re: pattern for specifying svn:ignore for files without extension

On Dec 1, 2010, at 13:33, Ryan Schmidt wrote:

> On Dec 1, 2010, at 13:31, Steve Cohen wrote:
> 
>> The build process of the application I am bringing under svn creates a 
>> number of unix binary executables that have no extension : for example
>> 
>> abcde
>> fghqp
>> 
>> etc.
>> 
>> I believe that * will match any files with or without periods so it isn't 
>> suitable.  Is there a pattern specifier that would embrace all files without 
>> an extension?
> 
> I can't think of a way to do that.

Can you have the build process write its files to a different directory (a 
"build" directory) that you could svn:ignore everything in?

Re: pattern for specifying svn:ignore for files without extension

Redirecting this discussion back to the mailing list..


On Dec 1, 2010, at 14:05, Steve Cohen wrote:
> On 12/01/2010 01:38 PM, Ryan Schmidt wrote:
>> Can you have the build process write its files to a different directory (a 
>> "build" directory) that you could svn:ignore everything in?
>> 
> 
> Sadly, no, not without a major rewrite of the build process.  This is deep 
> legacy stuff, using make, with the typical pattern of mixing source and 
> object in the same directory.  Not the way I would have designed it but ...

Then you may have to set an svn:ignore for each file you want to ignore.

question about .merge-right.r

2010-12-01 Thread Abrahm Scully

I have a branch of trunk that I'm doing some work it. Someone
committed changes to ^/trunk that I wanted, so I ran "svn merge
^/trunk" in a wc of my branch.

One of the files had a conflict, and I postponed resolution. I opened
the myfile.merge-left.r* and found the old version of the file. I
opened myfile.working and found what is currently in my branch.

But when I opened myfile.merge-right.r*, the contents didn't match any
version of the file I can find. None of the myfile.* files match what
is in ^/trunk. I thought the myfile.merge-right.* file was supposed to
be a copy of the file from ^/trunk.

Can someone help me understand this? What gets put in the merge-right file?

Thanks,
Abrahm

Re: pattern for specifying svn:ignore for files without extension


On 12/01/2010 02:08 PM, Ryan Schmidt wrote:

Redirecting this discussion back to the mailing list..


On Dec 1, 2010, at 14:05, Steve Cohen wrote:

On 12/01/2010 01:38 PM, Ryan Schmidt wrote:

Can you have the build process write its files to a different directory (a 
"build" directory) that you could svn:ignore everything in?



Sadly, no, not without a major rewrite of the build process.  This is deep 
legacy stuff, using make, with the typical pattern of mixing source and object 
in the same directory.  Not the way I would have designed it but ...


Then you may have to set an svn:ignore for each file you want to ignore.





It seems to me that
svn --recursive propset svn:ignore xyz

is basically just syntactic sugar for manually going through issuing
svn propset svn:ignore xyz

on every node of the directory structure,  It is syntactic sugar in the 
sense that the end product in either case would be the same.  There is 
no "recursive" data attribute in a project's svn:ignore tree.


Which leads me to think that a one-time shell script or python script or 
whatever might be written to walk the directory tree, look for all the 
executable files and manually add them to that directory's svn:ignore list.

Re: pattern for specifying svn:ignore for files without extension

On Dec 1, 2010, at 15:19, Steve Cohen wrote:

> It seems to me that
>   svn --recursive propset svn:ignore xyz
> 
> is basically just syntactic sugar for manually going through issuing
>   svn propset svn:ignore xyz
> 
> on every node of the directory structure,  It is syntactic sugar in the sense 
> that the end product in either case would be the same.  There is no 
> "recursive" data attribute in a project's svn:ignore tree.

Yes, that's right.

> Which leads me to think that a one-time shell script or python script or 
> whatever might be written to walk the directory tree, look for all the 
> executable files and manually add them to that directory's svn:ignore list.

That should work.

The other approach that initially occurred to me was to clean the directory so 
there are no unversioned files ("make clean" perhaps), then build the software 
("make"), then copy the output of "svn status" into an editor and massage it a 
bit to turn it into something you can hand to "svn propset svn:ignore --file". 
Though this would have to be done on a per-directory basis, so if there are 
many directories involved this may be impractical and a script as you suggest 
may do better.

Re: pattern for specifying svn:ignore for files without extension

On 12/01/2010 03:33 PM, Ryan Schmidt wrote:

On Dec 1, 2010, at 15:19, Steve Cohen wrote:

It seems to me that
svn --recursive propset svn:ignore xyz

is basically just syntactic sugar for manually going through issuing
svn propset svn:ignore xyz

on every node of the directory structure, It is syntactic sugar in the sense that the
end product in either case would be the same. There is no "recursive" data
attribute in a project's svn:ignore tree.

Yes, that's right.

Which leads me to think that a one-time shell script or python script or
whatever might be written to walk the directory tree, look for all the
executable files and manually add them to that directory's svn:ignore list.

That should work.

The other approach that initially occurred to me was to clean the directory so there are no unversioned files
("make clean" perhaps), then build the software ("make"), then copy the output of "svn
status" into an editor and massage it a bit to turn it into something you can hand to "svn propset svn:ignore
--file". Though this would have to be done on a per-directory basis, so if there are many directories involved
this may be impractical and a script as you suggest may do better.

Thanks for confirming, this should work, but one more question.
I've already got some other files in svn:ignore in each directory.
There is no command to append a name to the svn:ignore property. So my
script would have to call

svn propget svn:ignore
and then
svn propset svn:ignore
appending the list, right?

Re: How can i export a file named "a[.txt" by SVN.EXE

2010-12-01 Thread embedmobile y

I tried and it's ok!
Thanks for your kindly help


2010/12/1 Ryan Schmidt 

>
> On Dec 1, 2010, at 06:51, embedmobile y wrote:
>
> > How can i export a file named a[.txt by SVN.EXE.
> > When i try to use svn.exe to export a file whose name consists '[', it
> will fail and error info as "svn: URL 
> 'svn://127.0.0.1/test/a[.txt'
> is not properly URI-encoded".
> > If i use TSVN, it can export successfully. But i can only use CLI. So how
> could i export such kind of file by svn.exe?
> > My enviornment is winxp and SVN version 1.5.4 or 1.6.11.
> > Thanks for your kindly help.
>
> Properly (percent-)encode the special characters in the URL, i.e.:
>
> svn://127.0.0.1/test/a%5B.txt
>
>
>

RE: SVN Path Authorization

2010-12-01 Thread Ramesh Nadupalli

What are the other characters supported in the apache authorization file
(AuthzSVNAccessFile)?  Any documentation available? 

In case if there are any human errors in the authorization file, its making
repository unavailable. Is there a tool/mechanism to check the access
configurations before restarting the apache? 

 

For ex: without having a group, granting access to a directory will break
the repository access. 

 

Thanks

Ramesh

From: Engebakken Geir [mailto:geir.engebak...@edb.com] 
Sent: Tuesday, November 30, 2010 9:19 AM
To: Joseph Isenberg; users@subversion.apache.org
Subject: RE: SVN Path Authorization

 

I had the same problem when I set up SVN1.5.x  (way back then). Could not
get arounf the fact that users needed R-access to root of repos, so I ended
up with something like the following to prevent users from having R-access
to entire repos.:

 

 

[repo:/]

@admin = rw

*=r

 

 

[repo:/projects/Project1/subProject1]

@project1_subproject1Developers = rw

~project1_subproject1Developers = 

 

 

The ~ is a negation, meaning "all users not in the group"

 

 

 

 

Geir

 

Note : All inquiries regarding Subversion, MKS and general Development
servers should be directed to "EDB SourceControl System"

 

From: Joseph Isenberg [mailto:jisenb...@gmail.com] 
Sent: 27. oktober 2010 16:19
To: users@subversion.apache.org
Subject: SVN Path Authorization

 

Can I set up an AuthZSVNAccessFile that doesn't allow read to the root, but
does allow read an read/write to sub-paths. I want something like this:

 

[repo:/]

@admin = rw

 

[repo:/projects/Project1]

@project1_admin = rw

 

[repo:/projects/Project1/subProject1]

@project1_subproject1Developers = rw

 

I would then give the devs the url to the subproject and they could check
that out. I'm pretty sure I've done something like this in the past, but now
it won't let me check out unless I have read access to the parent paths.

 

Thanks for any help.

Joseph Isenberg

Re: svn:ignore with recursive and non-recursive patterns

You can use 'propedit --editor-cmd=script.sh **/', where script.sh
appends '*.o' to argv[1].

Another example, the following is a "Fix typo in the log message" idiom:
% svn propedit --revprop -r69426 --editor-cmd 'sed -i s/foo/bar/' svn:log

Steve Cohen wrote on Wed, Dec 01, 2010 at 12:29:58 -0600:
> I have a need to define a number of svn:ignore patterns in my project.
>
> Some are specific directories somewhere in my project tree.  Others are  
> particular file types created by a build process such as *.o which may  
> be found in any number of  directories.
>
> However, the svn propset command only allows the recursive -R switch to  
> be applied to the entire set of values for the svn:ignore property.  
> Whereas what is needed is to be able to apply the recursive switch to  
> the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore).  Is there any way of  
> achieving this?  There doesn't appear to be one.  Yet without it,  
> svn:ignore is useless, or at least too cumbersome to be used well.
>
> Steve Cohen

Re: pattern for specifying svn:ignore for files without extension

Steve Cohen wrote on Wed, Dec 01, 2010 at 17:40:12 -0600:
> On 12/01/2010 03:33 PM, Ryan Schmidt wrote:
>> On Dec 1, 2010, at 15:19, Steve Cohen wrote:
>>
>>> It seems to me that
>>> svn --recursive propset svn:ignore xyz
>>>
>>> is basically just syntactic sugar for manually going through issuing
>>> svn propset svn:ignore xyz
>>>
>>> on every node of the directory structure,  It is syntactic sugar in the 
>>> sense that the end product in either case would be the same.  There is no 
>>> "recursive" data attribute in a project's svn:ignore tree.
>>
>> Yes, that's right.
>>
>>
>>> Which leads me to think that a one-time shell script or python script or 
>>> whatever might be written to walk the directory tree, look for all the 
>>> executable files and manually add them to that directory's svn:ignore list.
>>
>> That should work.
>>
>> The other approach that initially occurred to me was to clean the directory 
>> so there are no unversioned files ("make clean" perhaps), then build the 
>> software ("make"), then copy the output of "svn status" into an editor and 
>> massage it a bit to turn it into something you can hand to "svn propset 
>> svn:ignore --file". Though this would have to be done on a per-directory 
>> basis, so if there are many directories involved this may be impractical and 
>> a script as you suggest may do better.
>>
>>
>>
>>
> Thanks for confirming, this should work, but one more question.
> I've already got some other files in svn:ignore in each directory. There 
> is no command to append a name to the svn:ignore property.  So my script 
> would have to call
>   svn propget svn:ignore
> and then
>   svn propset svn:ignore
> appending the list, right?
>
>

svn propedit --editor-cmd foo.sh
where foo.sh gets some filename as argv[1] and appends to it.

Re: pattern for specifying svn:ignore for files without extension

Ryan Schmidt wrote on Wed, Dec 01, 2010 at 13:33:50 -0600:
> 
> On Dec 1, 2010, at 13:31, Steve Cohen wrote:
> 
> > The build process of the application I am bringing under svn creates a 
> > number of unix binary executables that have no extension : for example
> > 
> > abcde
> > fghqp
> > 
> > etc.
> > 
> > I believe that * will match any files with or without periods so it isn't 
> > suitable.  Is there a pattern specifier that would embrace all files 
> > without an extension?
> 
> I can't think of a way to do that.
> 

svn:ignore patterns are apr_fnmatch() patterns, and apr_fnmatch() does
accept regex-like [a-z] expressions in its patterns, so you could try

[a-z][a-z][a-z][a-z][a-z]

to ignore all 5-lowercase-character filenames.  :-)

> 
> > Alternatively, one common differentiating aspect of these files is that 
> > they have executable privileges.  Being able to svn:ignore based on this 
> > would be a nice feature to have.
> 
> Unfortunately that feature doesn't exist either.
> 
>

Re: svn diff: output stops after first couple hunks?