[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging and switching

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-01-25 15:34:55 CET

"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

This is an archived mail posted to the Subversion Dev mailing list.