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.
I think the only way to really do what you want is to use a branch.
Start the branch from r2. Then merge in r4 - r5 and all later changes
as they occur on the main development trunk. After merging commit
your changes to your branch. Your branch will never have r3 in it in
this case. You get to commit your changes and so there is no longer
fear about accidentally putting this onto the main trunk.
Because subversion does not (yet) have merge tracking this must be
done manually at this time. Please see this section of the manual for
details of how this needs to be tracked manually.
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.track
The svnmerge tool is often used to automate this process. But I am
not using it myself and do not know how it would operate in the
presence of cherry picking of changes or of purposefully skipping
changes. But a number of projects are using it successfully in the
normal typical cases.
> 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:
>
> svn merge -r 2:3
> <edit>
> svn commit # create version 6 = (1,2,4,5,<edits>)
>
> Now if I realize I wasn't supposed to destroy the changes from version
> 3, I can't just undo version #6 -- I have to delicately take apart the
> erroneous checkin.
You could reverse r6 then reapply whatever changes you wanted. But
you are right that it can get messy.
> Here's a question: would the state of my working copy be any different
> if I had performed "svn merge -r 2:3" versus if I had manually done a
> diff-and-patch? In other words, does svn keep any sort of memory in
> my working copy that "hey, this guy undid version 3", or does it just
> know that "hey, this guy edited a bunch of stuff"?
There is no difference. 'svn merge' changes the local files in the
working copy. But nothing is known about this in the repository until
you commit your changes, which are committed just as if they were
normal changes by hand to the working copy. It is not tracked whether
it was modified with 'patch' or 'svn merge'.
Subversion at this time does not do any merge tracking. Merge
tracking is a high want feature. The topic comes up regularly and
there are long discussions about it in the archives. But it is not
easy to get right in the general case. Figuring out how to implement
it right has been holding up development of it.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 22 05:18:58 2006