Just following up my post for those that may experience the same
problem and are looking for a solution in the mail archives.
Turns out, easiest thing was doing:
#get a copy of trunk
svn co http://repo/project/trunk
#touch all files that could possibly have bad tags (xml/java only in my
case)
find trunk -name "*.java" -exec touch {} \;
find trunk -name "*.xml" -exec touch {} \;
#svn stat will show "M"odified files for all the ones which have the
bad $Id:$ tags in the
#repo.
svn commit trunk -m 'fixing bad tags'
This solves the problem as the newly checked in files will get their
tags set properly on that revision. You are still kinda screwed if you
need to diff old versions vs head as they will still show as diffs.
But at least you can avoid the problem moving forward.
-David
On Apr 27, 2004, at 11:39 AM, David Budworth wrote:
> Resurrecting an old topic here...
>
> Given that my repository is littered with these tags, we'd like to go
> through and fix them all.
>
> Anyone has a good idea on how to do this en mass?
>
> At first i tried to do:
> svnadmin dump badrepo | perl -pe 's/\$Id:\$/\$Id\$/g' | svnadmin load
> goodrepo
>
> but of course, that doesn't work (didn't even think about md5
> hashes/content length on the items).
>
> Next best thing I can think of is to write a script that either
> a) modifies the dump file, properly setting the md5 and content length
> b) just scans for bad id's and logs the file names, then we go edit
> the source itself
>
> There are hundreds of offending files, and 400mb of repo. So I was
> hoping to do it by editing the stream, but I don't see how that can
> really be an option.
>
> Is there a more proper way to do this?
>
> We are willing to kill off all our branches to get this resolved. So
> maybe there's a way to force-recommit the entire tree? Since it seems
> that re-commiting the offending file seems to fix the repo version.
>
> On Apr 7, 2004, at 7:22 PM, John Peacock wrote:
>
>> Philip Martin wrote:
>>> John Peacock <jpeacock@rowman.com> writes:
>>>> Not really. If you dump the repository created using the
>>>> reproduction
>>>> recipe given in the issue:
>>>> ...
>>>>
>>>> You'll see that what is in the repository is not the expanded
>>>> keyword,
>>>> but a stub that looks like an keyword (for the first two). foo3
>>>> does
>>>> not contain a keyword at all, and will not be expanded in the WC.
>>> All I meant by "expanded" is that it had not been "detranslated".
>>> Change foo3 to be "$Id: xxx $" and now it's a keyword and it shows up
>>> in the diff.
>>
>> I just noticed that an additional commit will cleanse the taint (i.e.
>> unexpand the keywords in the repository), i.e. all files when dumped
>> will contain $Id$ and nothing more. This is a more subtle bug...
>>
>> John
>>
>> --
>> John Peacock
>> Director of Information Research and Technology
>> Rowman & Littlefield Publishing Group
>> 4720 Boston Way
>> Lanham, MD 20706
>> 301-459-3366 x.5010
>> fax 301-429-5747
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 28 21:44:00 2004