You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jonathan Manning <jm...@alisa-jon.net> on 2004/05/03 15:49:26 UTC
reverting changes to svn-base files
Hi All,
I've been a lurker on this list since the early days. I've used svn for
many personal projects, and just convinced my fellow programmers at work
to convert our big project over from cvs. No surprises for me, since
I've been using it for a while, and the adjustment is going fairly
smoothly for the others - they are picking it up quickly.
One problem we've encountered is the use of the following idiom:
find . -type f -name \*.pm | xargs perl -pi -e
's/origstring/somenewstring/g'
This is a common way to change a function name or some other string
sitewide.
The problem is, this also changes all the svn-base files in the working
repository. I've tried some other variations (-not -name \*.svn-base
-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.
In the mean time, we get local changes that aren't identified by
subversion, and are difficult to even find, let alone resolve. To find
them in the first place - we just have to wait until a commit fails with
a md5sum mismatch error. Once that happens, there seems to be no way to
reset the WC except for backing up the files, deleting the entire
directory, updating, and copying the files back in. (which loses any
prop changes)
Is there any svn command that will ignore these local files and force a
full network update? I'd like a command that will just overwrite all the
svn-base files with the data from the repository matching the current WC
revision.
And, on the prevention side, any better idioms for making sitewide changes?
Thanks,
~Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: reverting changes to svn-base files
Posted by Scott Lawrence <sl...@pingtel.com>.
On Mon, 2004-05-03 at 11:49, Jonathan Manning wrote:
> One problem we've encountered is the use of the following idiom:
> find . -type f -name \*.pm \
> | xargs perl -pi -e 's/origstring/somenewstring/g'
> And, on the prevention side, any better idioms for making sitewide changes?
Make the find command:
find . -name .svn -prune -o -type f -name \*.pm -print
(using the explicit -print is important; it prevents the .svn
directories themselves from being printed)
--
Scott Lawrence
Pingtel Corp.
sip:slawrence {at} pingtel.com
+1.781.938.5306 x162
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: reverting changes to svn-base files
Posted by John Peacock <jp...@rowman.com>.
Jonathan Manning wrote:
> perl -pi -e 's/string1/string2/' *
>
> All files changed, despite being read-only.
Inplace edits work something like this:
1) copy source file to new temporary name
2) edit temporary file
3) rename temp file to original filename
Step #1 makes the new file writeable; step #3 succeeds because that depends on
the containing directory rights, not the file protections on the original file.
You can confirm this by using "-i.bak" and seeing that the .bak files are
still marked as readonly.
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: reverting changes to svn-base files
Posted by Jonathan Manning <jm...@alisa-jon.net>.
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 \*.svn-base
>>-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.
~J
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: reverting changes to svn-base files
Posted by Jonathan Manning <jm...@alisa-jon.net>.
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
Re: reverting changes to svn-base files
Posted by Stefan Haller <ha...@ableton.com>.
Ben Collins-Sussman <su...@collab.net> wrote:
> The .svn/text-base/ files are read-only files for exactly this reason.
> How is it that your command successfully edits them?
Ben, making the files read-only is not enough to prevent them from being
changed. You must also make the containing directory read-only.
For a thorough explanation of this issue, and why perl is right in
succeeding to change the read-only files, see
<http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz>; in there, read the file
"file-dir-perms".
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).
--
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: reverting changes to svn-base files
Posted by Ben Collins-Sussman <su...@collab.net>.
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 \*.svn-base
> -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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org