just an idea,
but if perl uses folowing approach:
read_file -> alter_content -> rm_file -> ceate_new_file
it is very easy to overwrite 'ro' files.
In this case the directory should be read only.
Deleting and creating a file alters the directory strukture,
not the file itself (on unix as far as I know)
Mit freundlichen Grüßen / With kind regards
> -----Ursprüngliche Nachricht-----
> Von: Jonathan Manning [mailto:firstname.lastname@example.org]
> Gesendet: Montag, 3. Mai 2004 21:54
> An: Ben Collins-Sussman
> Cc: email@example.com
> Betreff: Re: reverting changes to svn-base files
> Ben Collins-Sussman wrote:
> >On Mon, 2004-05-03 at 10:49, Jonathan Manning wrote:
> >>The problem is, this also changes all the svn-base files in
> the working
> >>repository. I've tried some other variations (-not -name
> >>-and -not -name \*.svn-work) (| grep -v .svn |). Hopefully
> we'll get
> >>used to using these soon, but it's been a difficult habit to break.
> >The .svn/text-base/ files are read-only files for exactly
> this reason.
> >How is it that your command successfully edits them?
> No idea.
> I did confirm the files are read-only.
> I'm not using sudo, or any special account.
> I just triple checked - running just the perl command seems to change
> the files without complaint.
> cd .svn/text-base/
> perl -pi -e 's/string1/string2/' *
> All files changed, despite being read-only.
> I thought it might be something funky with OSX, but the same thing
> occurs on my Linux system as well.
> It seems perl ignores read-only. Frustrating. I'll have to find a new
> command for global updates.
> In any case, is there any hope of getting a variation of the cleanup
> command that refreshes the text-base files? It's a huge pain dealing
> with these broken WC's, and the only way to fix it is to do a fresh
> checkout and risk losing all the local changes.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue May 4 09:35:32 2004