Stefan Haller wrote:
> Ben, making the files read-only is not enough to prevent them from being
> changed. You must also make the containing directory read-only.
That was my first thought. But wouldn't that make it difficult to add
and remove files from that dir when needed by the svn client tool?
> Jonathan: what I don't understand is how you managed to change files in
> .svn/ with the command
>
> find . -type f -name \*.pm | xargs perl -pi -e 's/foo/bar/g'
>
> This shouldn't be possible, the files in .svn don't match the pattern
> *.pm (they end with .svnbase or .svnwork).
>
Yes, I guess I condensed my example a bit too much. I also used a
straight 'find . -type f | ...' for the cgi directory, since the files
there don't have extensions. That command is clearly the one that caused
these issues. Perhaps extensionless files are a poor design decision,
but that's legacy stuff.
To summarize the conclusions I've drawn from this thread, I'm going to
create an alias or shell script that has a more precise find command
that excludes the .svn directories (thanks Scott). It's also clear now
why the read-only files changed.
For now, I'll have all our devs make a backup of their WC, (excluding
all .svn dirs), checkout a fresh copy, and copy any local modifications
back in. We'll lose all prop changes, but there weren't many.
Things left for subversion devs to consider:
* Making the directories themselves read-only. What other issues might
this cause?
* Creating a command or option to force a refresh over the network,
ignoring the 'convenience' copy stored locally. My command isn't the
only one that has potential to change the base files, and it creates a
very broken WC (even worse, a silently broken WC - it doesn't complain
until a md5 error arises during a commit -- update, status, and other
commands work normally). Some variation on cleanup could easily retrieve
fresh copies and make it consistent again - even just check md5sums
against both the WC copy and the base copy to flag any local corruption.
Thanks everyone,
~Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 5 16:49:48 2004