Karl Fogel <email@example.com> wrote on 11/28/2007 01:46:21 PM:
> firstname.lastname@example.org writes:
> > A majority of our 1500 users are using multiple clients, and many
> > have expressed concern that clients can (and do) show conflicting
> > information about the same working copy.
> > A real user quote: "How can I trust Subversion if it can't even
> > consistently show status information between clients?"
> Whoa. That's a whole different claim, and much more serious. If you
> have a bug to report, could you please start a new thread and describe
> exactly what you're seeing? Thank you.
> (I realize the bug might involve multiple clients, some of which are
> not maintained by the core Subversion team. Nevertheless, we can
> serve as an organizing point, and what you're describing sounds pretty
NOT a bug, just the potential inconsistent status behavior in certain
configurations. Some clients visually cache information (individually)
from other clients, and that information is not always in sync.
I was trying to identify how 2 clients with separate caches can
cause user confusion. I was not trying to say this is typical
behavior between current Subversion clients. (Sorry for not
making that obvious in my email.)
Most of this is how Eclipse caches workspace information and can force the
user to manually refresh to see outside changes. (As a developer of
Eclipse plugins, the manual refresh is really expected to be required,
but as a normal user it can be confusing. And I do realize that Eclipse
does have a preference to "refresh automatically", but that is
unbearably slow on large projects, and if I remember, off by default.)
A non-locking example: (since I'm getting beat up about my locking
1) Check out a project using subclipse in Eclipse.
2) Modify a file in Eclipse.
3) Use TortoiseSVN to commit the file change to the repo.
4) Enjoy how Eclipse and sublipse still feel the file has been modified.
5) Right click on the file in Eclipse and select Team->Commit...
6) Enjoy how Eclipse tells you nothing has changed but still shows
the subclipse svn changed icon decorator.
A manual refresh in Eclipse "fixes" it. So does enabling automatic
refreshes in Eclipse.
NOTE: Eclipse works exactly the same way if you do something like use
windows explorer to rename a file, so this is not a Subversion
specific problem. The solution here is to enable automatic
refresh in Eclipse and endure the performance problem on large
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 28 21:52:03 2007