Stefan,
>Lieven Govaerts wrote:
>
>> some of my colleagues found this problem with TortoiseSVN 1.2.3 while
reverting
>> a file (part of a revision).
>>
>> The problem:
>>
>> 1. create trunk
>> 2. add a folder with some files in, and commit
>> 3. make some changes on those files on trunk (rev 3-6)
>> 4. create a branch 1.x from trunk
>> 5. checkout that branch 1.x in folder c:\temp\1.x
>> 6. from the local folder, select show log
>> 7. find revision 3, click on one of the files you changed in that revision,
and
>> select 'Revert changes from this revision'.
>>
>> TortoiseSVN will show you the folder to which it's going to revert your
changes,
>> what I typically see is that that folder is incorrect. It appears that some
>> characters are missing, ex. : c:\temp.x\test.
>>
>> If my report isn't clear, please let me know.
>
>Report is very clear and reproducible.
>Problem is: TSVN can't reconstruct such a renamed path. That means it
>can't find the path to the working copy file which is needed for
>reverting the changes.
>I added an explanation error message in revision 7021, which also hints
>about how to work around this issue.
I think there are two common scenarios which can be solved in TSVN even though
Subversion itself lacks this functionality.
First scenario:
Suppose we have a working copy of branch 1.x, copied from trunk. On trunk we
deleted a file file.txt.
Suppose I want to revert the deletion of file.txt. It seems logical that I can
do a show log on the working copy, go to
that revision, select the deleted file and select 'Copy to working copy' (like
you have now in the Repo Browser).
Second scenario:
Suppose we have a working copy of branch 1.x, copied from trunk. On trunk we
modified a file foldera/folderb/file.txt.
Suppose I want to revert the modification on file.txt. In the log message you
see: 'Mofified /trunk/foldera/folderb/file.txt'.
TSVN could:
1. Check all folders trunk, trunk/foldera and trunk/foldera/folderb to see if
one matches the root of our working copy (UUID check)
2. If no folder matches, just show your error message.
3. If one matches, take the relative part of the file and try to find (based on
name, check on UUID) it in the working copy. If it's not found, show the error
message.
4. Revert the modification on that file.
Hm, while I'm typing this I realize that in the second scenario there still is a
bit of guessing involved.
Let me know what you think about this.
thanks,
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Jul 19 10:12:28 2006