Mark Phippard wrote:
> I am sure this is the intended behavior, but I wish it wasn't.
>
> When you run the command:
>
> svn update -r N
>
> The command will set every file in the WC to revision N even files that are
> at a higher revision. In my opinion, the command should only update the
> files and folders that were at a lower revision than N and leave the other
> ones alone. The switch command could always be used if the whole WC needed
> to be at a specific revision, and update could also support the --force
> option as well.
That is inconsistent with other tools such as CVS and counter intuitive. If I
ask to get the repository at revision N, I expect that all files now be at
revision N, not just files that were older than N. In fact, most uses I have
ever had of this was to go backwards in revisions/time and thus if this
change were to be made the most common us case I can think of would become
a non-use case or a special case that requires --force.
> In Subclipse we have this "Synchronize" view that lets you graphically
> Synch your WC with the repository. This might include graphically merging
> changes manually etc... Anyway, for correctness, we have used update -r N
> to perform updates so that if additional commits have been made since the
> process started the user does not receive any unexpected updates.
Why not just do an svn up? The single command will get you an atomic update
to the current revision with merges and conflicts shown. At this point you
can then do all of your local graphical magic to show what is going on.
(Note that a non-conflicting merge will still show as local modifications and
thus would have the correct text-base in the WC and thus "svn diff" shows
what your local change looks like)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 25 22:01:00 2006