On May 26, 2006, at 17:04, Michael Pickard wrote:
>>>> Read the section "Undoing Changes" in the book:
>>>
>>> Would this also work when there is a requirement to 'rollback' an
>>> entire working directory to a previous revision ? i.e
>>>
>>> svn merge -r 8109:8099http://path/to/trunk/rep rep
>>
>> it depends on what you intend to do: if you just want to have a
>> look at
>> rev 8099 and don't want to check in any changes based on the
>> version, a
>> simple "svn up -r8099 " will do the job - but you won't be able to
>> check
>> in any changes.
>>
>> Otherwise, if you wish to undo the changes in the versions between
>> 8099
>> and 8109, your command is the proper one.
>
> However, I ran 'svn up -r 8099', and while it did appear to make
> some changes, and 'svn info' now returns 8099, files that were
> added after revision 8099 remain in the working directory, leading
> me to believe it wasn't a true roll back.
Subversion is designed to not destroy any of your work which has not
yet been committed. Therefore, if you have a working copy with
changes, and you "svn up" to a different revision, your working copy
gets updated to the specified revision, and still retains the changes
you had made. If you wanted Subversion to throw away your changes,
you should have first used "svn revert". If you had new files or
directories that were not yet committed, and you wanted those to be
destroyed as well, then you would need to write a script to destroy
them before running svn up. IIRC several scripts to delete
unversioned items have been posted to the list over time.
> Can you elablorate a little on what 'svn up' does ? - it doesn't
> appear to be documented in O'Reilly's book.
svn update is described in the book:
http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.update.html
> As an alternative option, I guess I could delete the contents of
> the working directory and then
> svn checkout -r 8099
> but that seems a little clumsy.
If you want a pristine copy of r8099 with no changes, then that's a
good way to do that, yes. Otherwise, if that's too expensive in terms
of time or network bandwidth or another reason, then reverting the
working copy, recursively, and writing a script to delete unversioned
items, and then updating it, is a good alternative.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 28 19:36:31 2006