On Fri, March 11, 2005 8:36 pm, Eric Hanchrow said:
> Douglas> I realise that this isn't how you are supposed to "back
> Douglas> out" changes but it still looks like very bizarre
> Douglas> behaviour to me.
>
> I think it's for when you want to temporarily look at the Way Things
> Were. There's certainly no reason for the files to appear as
> "changed" in the working copy. If you actually want to undo a change,
> see
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-4.2.
Yes, I'm familiar with using merge over reversed revisions. I wasn't the
first time I hit this problem and I assumed it was just me, but since I
recently met this again I thought I should mention it.
I still don't know why this shouldn't mark the file as changed however.
Imagine if you had updated a file to a previous version and then gone home
for the weekend. On Monday, you have a project that looks like it is a
perfect replica of HEAD, according to the overlay icons and the commit
messages. You think everything is working, but another programmer
complains it is broken.
Eventually, despite knowing that you are up-to-date with the repository,
you try running update. Suddenly, your copy is broken too, but the log
files for the server say that nothing was changed since your last commit.
OK, so I'm probably overdoing the dramatic descriptions, but I still can't
see why this results in a file marked as unchanged. Is it useful this way
in some way I don't understand? Is it mimicking some behavious of SVN I
wasn't aware of?
Thanks for your help,
Douglas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Mar 14 18:00:20 2005