On 10/18/06 12:31 AM, "John Woodward" <john.woodward@valtech.com> wrote:
>
> Iım seeing a very similar behavior. When I commit a single file change in some
> subdirectory, and check that single file in, Iım then presented with a list of
> updates to that entire list of directories, leading to the directory the file
> was present in.
>
> The first time this happened, I did as Daniel stated --- checked in a single
> change out of several, updated to pick up whatever the directory changes were,
> and then noticed that my other changed files were no longer flagged as having
> been changed. Refreshing the project returned those files to an ³altered²
> state.
>
> What Iım puzzled about (other than that) is: why would I be presented with an
> incoming set of changes to the entire parent directory structure of my single
> file check-in? This is with Subclipse 1.1.7, and subversion 1.4.0 on Windows.
"Me too". I'll try to reconstruct what happened. I had a folder structure
like
proj/src/java/a/b/c
with Foo.java locally changed, and Bar.java a new addition. Furthermore,
directories from "proj" down to "b" (I think) were out of date with respect
to the repository. I committed Foo.java and Bar.java. Synchronize still
showed incoming changes on the folders, so I chose "updated". This actually
undid the change to Foo.java and removed Bar.java, and the synchronize
window was clear. However, I was momentarily very concerned, but when I
checked the console window, I was reassured that the commits at least went
in and would be retrievable. In fact, a subsequent "update" in the Package
Explorer pulled in my just-committed changes. So I'm guessing that the
synchronize picked up the revision difference on the top folder, but after
the commit, didn't update its notion of the latest revision.
j.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Wed Oct 18 13:37:48 2006