Behavior of update command

[Mark Phippard <ma...@softlanding.com>]

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.

Why?

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.

The problem is that if a user does a commit before they do updates, then
when they come back and do an update at their root folder, the update
process removes what they just commited from their WC.  We cannot just
update the revision based on the commit because to do that you would really
have to just rerun the whole process, which from a performance point of
view is not desirable.

Just venting I guess.

Thanks

Mark


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Behavior of update command

[Julian Foad <ju...@btopenworld.com>]

Mark Phippard wrote:
> 
> 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.

I don't know Eclipse or Subclipse.  Please could you explain in more detail the 
sequence of Subversion operations that is involved.  When you say "We have used 
-r N" do you mean Subclipse chooses a particular revision number (which one?) 
to update to and then performs multiple updates (why? where?) to that same 
revision?

> The problem is that if a user does a commit before they do updates, then
> when they come back and do an update at their root folder, the update
> process removes what they just commited from their WC.  We cannot just
> update the revision based on the commit because to do that you would really
> have to just rerun the whole process, which from a performance point of
> view is not desirable.
> 
> Just venting I guess.

I don't yet understand the problem.  Are all of these user operations (commits, 
updates) done from within Subclipse?  What's the significance of your words 
"come back and do an update at their root" and "rerun the whole process"?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Behavior of update command

[Michael Sinz <Mi...@sinz.org>]

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