All well and good, but I wanted to bring up something that seems to have been
forgotten. How will svn blame deal with reverted code. It would be super
nifty there was a way to make it go back to the way it was before, instead of
making it appear that you made a change, when really you just put it back to
the way someone else made it.
I guess it's not the end of the world if it doesn't happen that way, but it
would definitely be cool.
On Wed, Jan 30, 2002 at 03:36:59PM -0600, Ben Collins-Sussman wrote:
> 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
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:37:01 2006