On 1/19/07 11:11 PM, "Ryan Schmidt" <email@example.com> wrote:
> On Jan 19, 2007, at 21:09, Steve Bakke wrote:
>>> svn up -r42
>>> will update your working copy to the state of the repository at
>>> revision 42.
>>> Something different: If you want to undo a change, and commit that
>>> undo to the repository, you do a reverse merge, which is described
>>> in the book:
>> I'm just chiming in here because after seeing the last response, I
>> the gun and attempted to test using the command 'svn up -r##'.
>> This worked OK. I did this on a subdirectory of my working copy.
>> % svn up -r102 subdir1
>> D subdir1
>> I happened to have picked a revision which did not have this
> I assume your working copy also happened to have local modifications
> to it. Therefore, Subversion did not delete the directory.
No. 'subdir1' was completely up-to-date with respect to the head. So why
does it show up as being scheduled for deletion? What would happen if I had
actually done a commit?
>> Then for kicks I tried doing a regular update at the top-level of the
>> working copy:
>> % svn up
>> svn: Failed to add directory 'subdir1': object of the same name
> Correct: Subversion will not add an item if one of the same name is
> already there.
While that makes sense, from an intuitive sense. The original svn up -r
left me with a mixed working copy. I guess that because it is not a branch,
'svn status' will still report status relative to the head. On the other
hand, it seemed to make sense that I should be able to "undo" what I had
just done by doing an 'update' back to the head revision since I didn't
actually have something locally modified. Does that make sense? Maybe that
argument falls apart when the directory in question didn't exist in that
revision? I'm just trying to get my head around how it is intended to
> If subdir1 contained local modifications, rescue them, then delete
> the directory. Then you can "svn up" back to the HEAD revision.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jan 20 17:38:27 2007