On May 22, 2006, at 01:31, Adam Megacz wrote:
>>> That is, if I have a working copy with version 5, I want to put my
>>> working copy in the state it would be in if version 3 had never been
>>> checked in (that is, the changes in versions 1,2,4,5).
>
>> I don't know darcs. Does "svn up -r 3" do what you want?
>
> Not really what I wanted, since after doing so the changes embodied in
> versions 4+5 would no longer be represented in my working copy.
>
> For example, if change 3 added function "foo()" to "bar.c" and
> revision 4 added function "baz()" to "bar.c", the result should be
> that "bar.c" contains "baz()" but not "foo()" (assuming they don't
> share any lines, which would require human intervention, of course).
Ah, indeed. So this trick would be useful if you were not making
changes to the same file as the one affected by the update. For
example, if someone broke foo.c and you needed to change bar.c, you
could svn up -r 3 foo.c and continue working on bar.c.
But if you're both changing bar.c, then you're right, you'd first
have to back out the change from r3 and remember to redo it before
committing. Messy.
The idea of using a branch was also a good one.
>> If you did in fact want to make the changes such that you could
>> commit them, then Subversion does support a much more-intelligigent
>> solution than svn diff and a manual patch, namely svn merge.
>
> Hrm, okay, it seems that "svn merge -r 2:3" would automate the
> diff-patch hack I'm currently using, but still has the accidental
> checkin problem. Plus it gets even worse if I mix "good" edits with
> the "undo" change:
Note that the command to *undo* revision 3 is actually "svn merge -r
3:2"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 22 12:35:37 2006