> That is inconsistent with other tools such as CVS and counter intuitive.
Well I did say the current behavior was likely expected. I guess my point
was that Subversion already provides switch -r N that can do this, it does
not provide a command that does what I need.
> 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.
That is how I work, and I am sure a lot of others. The problem is that
Eclipse comes with the Synchronize view that everyone is in love with and
is one of the main reasons the CVS support in Eclipse is so highly praised.
So Subclipse users expect us to support the same features in Subclipse. If
the user always did the update before the commit there would be no issue.
I guess it would be the equivalent of running:
svn st -u
Noting the HEAD revision at the time. Investigating changes manually.
Then doing the commit of your local stuff or part of it (since it was
non-conflicting). Then doing:
svn up -N
After and losing your commits.
This is fairly far-fetched and arguably user error, but often times a GUI
makes it a lot easier and more likely that people will do this sort of
stuff. We have had at least 5-6 users in the last week report this in
Subclipse. It was only today that I realized this is the scenario that
causes it.
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
Received on Sat Feb 25 22:15:40 2006