[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: reverting changes to svn-base files

From: Jonathan Manning <jmanning_at_alisa-jon.net>
Date: 2004-05-05 16:49:08 CEST

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,

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.