"Jay Freeman \(saurik\)" <saurik@saurik.com> writes:
> That isn't what "update" is about... if that were the case, when you did an
> update you would remove all local changes to the working copy, including
> those to files that _are_ on the server (as having those changes obviously
> makes this NOT an "exact copy"). When you do an update, you are taking the
> changes that were made between your revision and another revision (most
> often the HEAD), and merging them in with your possibly modified local copy.
> I can't imagine a situation where I would want to delete all of the changes
> I've made (including adding new files and directories) to my repository...
> are you sure you aren't looking for a clean checkout?
Right. The working copy library (libsvn_wc) has a design tenet:
"never destroy the user's data, unless they explicitly ask."
In practice, this means:
* as Jay says, 'svn up' merely patches your working copy. It
doesn't destroy local mods. And it certainly doesn't destroy
unversioned items. As a result, the patching may result in a
conflict (C), or in an "obstructed update" -- meaning the server
is trying to add a new file to your working copy, but an
unversioned item of the same name is in the way. When that
happens, the update bails out.
* When you schedule a file for removal, the working file isn't
actually removed unless you pass --force.
* When 'svn up' tries to destroy a version-controlled directory, it
very carefully looks for local mods anywhere within. If any mods
are found, the directory isn't completely removed from disk; it
leaves behind "narrow paths" right town to the locally modified
objects.
---------------------------------------------------------------------
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:36:59 2006