"Cronemberger, Constantino" <constantino.cronember...@gft.com> writes:
> Yesterday I left the update running and this morning it was finished. Today I > executed "svn status" and saw that I still had some modified files that I > have never touched before, then I did the same steps as yesterday and got the > same problems: > > - I try to revert those changes that I did not do > - the files are deleted and I have to re-create the files, do a "delete from > work_queue" and a "svn cleanup" > > at the end the files are still reported as modified. > > I also tried to delete the directory where those files are and tried an > update afterwards to get them replaced but the result was the same: modified > files. > > Finally I tried to do an "svn delete" in those files and tried to revert > again and got the same problem. > > The problems I found so far are: > > - I did not change the files that are being reported as modified (in fact I > never opened them), so the upgrade process must have done this > - The error happens if I try to revert those changes and if I first delete > the files and try to revert the deletion > > Is there any query I can run on my wc to help identify the problem? The one I gave last time: select * from work_queue That's the starting point of the investigation. Having identified the local_relpath then select * from nodes where local_relpath='some/path' select * from actual_node where local_relpath='some/path' Deleting rows from the work_queue is bad idea. Removing rows may appear to solve the temporary problem but it is likely to lead to errors in future operations. -- Philip
