SteveKing wrote:
> TSVN does that merge like
> svn merge -r2:1 file:///C:/myrepo/trunk/mergme.txt
> which means (since its the log dialog and it doesn't know that the file
> you've selected for reverting still exists in the working copy (yes, it
> *could* know, but that very complicated and requires an analysis of the
> whole logs up to that revision).
>
>> However, if on the command line I cd to the trunk working copy and:
>> svn merge -r2:1 mergeme.txt
>> It successfully undoes the changes.
>
>
> Here, Subversion uses the working copy as the peg revision, so the merge
> succeeds.
Thanks for the explanation, Steve.
1.
I wonder if this information could be obtained in another way. If I
clicked on the file in my working copy and did a show log then the file
is guaranteed to exist in the WC. Is there a way TortoiseSVN could
optimize for this case, so it could work as easily as the command line
client? In other words, if Show Dialog is called from a working copy,
then use just the local working copy filename direcly instead of the
full path (as I understand your explanation of the difference to be).
2.
> But you can use the TSVN merge dialog which will work if you use the
> working copy paths there too.
I had tried this before posting but it had the same error. If I right
click a file in my WC, choose TortoiseSVN -> Merge, I get, a From: url
of, e.g.:
file:///C:/myrepo/trunk/mergeme.txt
Changing this to just mergeme.txt doesn't work. How can I make it use
"working copy paths" ?
The only way I could get the merge to work was to look through the
history, and manually type in the full original path of the file
(file:///C:/mergeme.txt) for it to work. In my real use-case this is a
very long path.
Am I doing something wrong?
As always, thanks for your excellent work!
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jul 14 23:08:04 2005