Support for readonly flag - PROPOSED PATCH

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

Hello again,
 
As I not get response for this letter I make the patch myself. It is
desirable that someone who tracks svn development will look at it and
into proposed changes. The patch applies to latest 1.0.6 release (can be
found in attach).
 
The problem that is covered by this patch can be found in previous
letter (check the bottom of letter).
 
What I made and what I change:
 
1. Make the SVN to be insensitive to readonly flag on working files
I found that mentioned problem is caused by svn_io_copy_file. It cannot
overwrite read-only files. (NOTE termin readonly applies there mostly to
win32 platform). The first fix attempt was to remove read-only file
before coping, to insure that it not fail. However, later I found that
the similar problems also for svn_io_rename_files function. There was
some work around this calling svn_wc__prep_file_for_replacement and then
svn_io_set_file_read_only. Note that svn_wc__prep_file_for_replacement
make something only on Win32.
So I decided to make svn_io_rename_files to be insensitive to the
readonly flag on Win32, which is mimics *NIX behavior. It is just
modified to remove readonly falg on dest file before rename, and
restoring after. This way it never fail if file is readonly, and if this
attribute remain as it was before renaming.
That means that with this fix svn client became insensitive to readonly
flag for working copy.
Also, this fix allows change "fix" code like this:
        SVN_ERR (svn_wc__prep_file_for_replacement (basef, TRUE, pool));
        SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
        SVN_ERR (svn_io_set_file_read_only (basef, FALSE, pool));      
To just:
        SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
And also remove dummy fix function svn_wc__prep_file_for_replacement at
all.
So the goal is achieved, and some "not good" code cleared. I think this
can be useful in any case.
 
2. Mimics the CVS "Checkout files readonly option"
First of all I not know how to make it really option, I just place all
code relating this into #ifdef CHECKOUT_READONLY block.
The fixes are simple enough and appeared only in 3 places:
a) update_editor. When determined that new file comes from repository,
logged command to set readonly flag on it
b) do_commit. Successfully committed file also logged to receive
readonly flag
c) update_editor. Files merged with conflicts became writable.
 
Box fixes are trivial enough and I consider that will not cause any
problem, but may just resolve some client problems on Win32. I will be
happy if some one let me know how to make the "Checkout readonly" as
real option, since now I should use patched svn.exe.
Also, I will be happy if SOME ONE responsive for development will
schedule this to include in work branch or in 1.1 release.
ANY FEEDBACK ON THIS ARE WELCOME.
 
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