On Thu, 2 Dec 2004, Joe wrote:
> Hi!
>
> I'd like to know if there is some way to verify what svn update will do
> BEFORE it applies the changes. Here is a scenario: I've updated
> several files in the trunk, merged those changes into a branch, and have
> a work area with files from the branch, some of which have already been
> changed locally (but not committed).
>
> First, I'd like to know what files in the branch are going to be
> updated, with or without conflicts, somewhat like a "svn need-update"
> command that would only LIST the files to be fetched.
This sounds very much like "svn status -u" - does that work for you?
>[...]
> The second issue is what changes will be actually be applied,
> particularly when they conflict with my local changes. With a list as
> described above, if it showed "U" or "C", I could run svn diff to see
> what was the extent of the "damage". I realize that svn update produces
> an annotated merged version and keeps the old copy (.mine) as well as
> the two versions in case I don't like the merged version. However, svn
> appears to get confused if I decide to revert, either manually or using
> the svn command. svn revert wipes out everything and instead of
> restoring my original local copy, it goes back to the original rev in
> the branch.
Yes, "svn revert" removes any local changes, restoring a copy that is
identical to the version that was checked out, in this case the version on
the branch.
> If I kept a copy of my changes and use that to overwrite
> the original rev, svn update then refuses to merge changes again
> (stating it's at head revision).
That's right, because svn has remembered that it's already done the
update; it notices that you've modified the file, and assumes that you've
deliberately removed the changes that were added as part of the update.
> If I rename the .mine file to overwrite the merged version, svn status
> still thinks it has a conflict.
I think this is the same as the previous case (ie you're overwriting the
file in question with your modified version)? In any case, "svn status"
will continue to flag a conflict until you explicitly tell it otherwise
(with "svn resolved <file>").
What you probably want to do in this case is as follows:
(1) Make sure you've still got your ".mine" file with your changes in!
(2) Delete the offending file:
rm <file>
(3) Restore the old version (ie the one your changes were made to):
svn update -r<oldrev> <file>
(4) Copy your changes over the file
cp <file>.mine <file>
Then you'll have the working copy in much the state it was before the
original update - so you can either update again (when you've had some
coffee and are prepared to face the merge), modify/revert your changes, or
whatever :)
> I'm using 1.0.6 so maybe this confusion has been fixed in a later
> version. Nevertheless, a mechanism for previewing the possible
> conflicts without actually updating the files seems like a useful feature.
Yes, this would certainly be useful; I don't know of such a feature - I'm
sure someone more qualified than me can speak as to whether it's been
discussed...
Patrick
--
The easy way to type accents in Windows: http://www.frkeys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 2 10:55:12 2004