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

Re: Backing out changes: the prefered method?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-01-30 22:36:59 CET

Sean Russell <ser@germane-software.com> writes:

> On Wednesday 30 January 2002 11:24, Ben Collins-Sussman wrote:
> > No need to do the rm first. You can 'svn up -r N' the file, and the
> ...
> > But understand: you'll simply have a mixed-revision working copy
> > after you run that update. The file won't be "locally modified". The
>
> OIC, so you couldn't svn up -r N the file and then commit it. You'd have to
> either do the diff, or svn up -r N and then edit the file and change it
> subtly. Would it then commit, or would you get a conflict with the current
> version?

If I run 'svn up -r 5 foo.c', then my working copy has foo.c as it
appears in revision 5. This means that if a tweak the file and run
'svn diff', I will see my mods appear as differences against *revision
5*, not the head revision. This is because a "pristine" copy of the
revision 5 of the file is stashed in .svn/ (This allows 'svn diff' to
be a network-less operation, and allows the client to send diffs when
committing changes.) My working copy actually believes that it has
rev 5 of foo.c, and it will fight to keep that notion. So 'svn up'
isn't the tool that you want to use for reverting a change.

Here's the example. Assume you have a working copy, all at revision
5. You then make a change to foo.c, and commit, thereby creating
revision 6 in the repository. A few other commits to other files go
by, and you do some updates.

Now it's the following week, and you have a working copy (mostly) at
revision 15. You run 'svn status -v' and notice that the last time
foo.c changed was in revision 6. You now decide you want make remove
that last change you made to foo.c.

So -- this has nothing to do with updating. You have subversion
generate a diff between foo.c in revision 6 and foo.c in revision 5;
you then apply that diff to your working foo.c. Now: your working
copy still believes that you have version 15 of foo.c (which
incidentally is no different than revision 6 of foo.c). But now you
have some local mods too. The working copy has no idea that those
local mods just *happen* to revert the last change made to foo.c.
When you commit your modified foo.c, you create revision 16. And now
foo.c in rev 16 is exactly equal to foo.c as it was in rev 5.

Am I too verbose? :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:01 2006

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

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