On Wed, Jan 30, 2002 at 11:10:38AM -0800, Sean Russell wrote:
>
> > An later, Ben Collins-Sussman <sussman@collab.net> wrote:
> > > But to answer your question: once we fix this use-case, yes, your
> > > algorithm is the right way to back out changes to a file. You would
> > > view the log for the *one* file, determine that you want to backdate
> > > the file to revision N, and then do something like:
> > >
> > > svn diff -r N -r HEAD <filename> | patch
> > > svn commit
> >
> > Super, thanks. Could you not also do:
> >
> > rm <filename>
> > svn up -r N <filename>
No need to do the rm first. You can 'svn up -r N' the file, and the
server will send a patch against whatever revision of the file you
already have.
But understand: you'll simply have a mixed-revision working copy
after you run that update. The file won't be "locally modified". The
whole point of backdating (I thought) was to make the rollback happen
on the *server*. To do that, you need to have the backdating applied
as a patch to your working file, so it appears locally modified... and
then you commit the file.
---------------------------------------------------------------------
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