Mark Phippard wrote:
> So what I think is happening is that you do a Synchronize and it has a
> mixture of Incoming and Outgoing changes. Let's say the highest incoming
> revision is 100. You then do a commit first, this updates the committed
> files in your WC to revision 101. You then select a root folder and do an
> update. Our code sees revision 100 as being the highest revision so we
> do:
>
> update -r 100 /SomeFolder
>
> The problem is that this command will update everything to revision 100.
> So the files that were committed are put BACK to revision 100. Personally,
> I think it is incorrect for update to do this, it ought to skip over the
> revision 101 files and force you to use the switch command if you really
> want to put everything at revision 100. Regardless, there is nothing we
> can do about the fact that it works this way.
>
> This should be easy to test/verify if someone wants to, but I am fairly
> certain that this is what is happening.
>
> At the moment, I cannot think of a good way to approach fixing this. I
> will probably put the code back to updating to the HEAD revision as I
> think it has the least negative side effects. Or maybe I will do
> something like if you select a folder and do Update, I will use HEAD, if
> you select a specific file, I will use the revision of the file, or the
> highest revision in the set of files.
Is it possible to invalidate the synchronize? When a synchronize is done
against a working copy, the wc
is at some particular revision number and the synchronize is then at
another revision number. If when
the update is performed from synchronize, and the wc is at a different
revision, couldn't it notice it and
do some appropriate behavior (e.g. put up a dialog where the user can
choose to redo the synchronize)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sat Feb 25 21:32:04 2006