Support for readonly flag

[Sergey Korotkov <Se...@mail.ru>]

Hello List, 
 
I just send the same as feature request into issue tracker but some one
told me that first this should be discussed there.
 
So.
 
We are working on SCC provider for SVN and have the following problem. 
IDE "likes" when source controlled files are readonly. Than means that
if file 
not readonly it does not check it status when user start file editing,
or it 
automatically assign readonly after checkin.
I know, this can be considered as IDE issue, however most of IDE follow
that 
logic, and as you understand no chance to change them.
We implement some work around this, manually setting and removing the
readonly 
flag. However this makes working copy incompatible with standard SVN
client 
(any). SVN can not update the readonly files with error like "cannot
copy 
file.tmp to file.real_file extension).
What I ask is:
1. Minimal fix
Fix windows svn client to always remove readonly flag for all updated
files before copy. 
2. Good minimal fix Remove readonly flag before file update and restore
it later if it was on file. 
3. Implement some analog of CVS "Checkout readonly" option to set
readonly flag 
for all committed and initially retrieved files from SVN. 
 
I would be happy if you will consider this as useful fix and include
into 1.1 
branch.
 
 
 

Re: Support for readonly flag - PROPOSED PATCH

[John Peacock <jp...@rowman.com>]

Sergey Korotkov wrote:

> 
> Any chance to get response on this?
> 

I'll give you a response, but it might not be the one you are looking 
for. ;)

1) Read the section "Patch submission guidelines" in HACKING; 
specifically you didn't include a log entry documenting what you 
changed, and you attached a zipped patch file (which makes it more 
difficult to review).

2) Your patch file is a truly horrific combination of line endings (the 
header of each diff has CR/LF, but the body has LF only).

3) Read also the section of HACKING which deals with code formatting; 
you have tabs all over the place in your new code.

4) Enabling/disabling features based on #ifdef's is not popular among 
the core developers (I know, because I proposed a patch which did just 
that ;).

5) You need to be more patient; 1.1.0rc2 just came out and I would think 
that most of the core developers are busy with testing that, and aren't 
going to spend much time looking at new features.

HTH

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org