[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn update --dry-run?

From: Patrick Smears <patrick.smears_at_ensoft.co.uk>
Date: 2004-12-02 10:52:51 CET

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


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.