> > So I believe that now:
> > - deleting versioned resource properly triggers parent
> resources dirty
> > decorators
> > - deleted resources are removed from syncView after commit
> > - resources added to repository are displayed as incoming
> in syncView
> > - when a svn properties are changed on a file, it is displayed as
> > change in syncView
> Not bad for a day's work!!
> I eagerly look forward to trying this out on Monday.
Well, I very exceptionally had a whole Saturday for myself, so I spent some
14 hours on that ;-)
Anyway, I've been investingation the synchronize behaviour more thoroughly
and there are still few issues unresolved.
In general, it seems that the actual code is too "file-centric", the
directories do not behave correctly.
- when the new (empty) directory is added to repository, after update and
next synchornization (with non-empty result), the
Newly created directory is still presented in syncView as incoming addition.
(In fact not the directory is presented as incoming, but file ! with the
same name/url as the directory. It is cause by the fact that
during svn status, it is not known yet whether incoming resource is file or
directory and by default the findChanges() method
in SVNWorkspaceSubscriber creates a (phantom) file. That phantom is not
being removed later due to the fact that it pretends it has remote
representation, but it's not his remote status but the real directory's with
the same url ....)
- when a directory is deleted, it is not presented in syncview and it also
does not dissaper from resource perspective, although it is flagged as dirty
And probably few more ....
I was trying to get rid of that "ghost" file, but got lost and I still could
not find how are the resources getting into syncView in the first place ...
If I'll find some more time today, I'll try to fix the other deleted
directory issues ...
P.S. As I was getting into these issue more deeply I've realized that very
probably the whole code in internalResourceChanged() method is pretty
Well, the last call to fireTeamResourcechange probably not, but the
whole stuff above it yes ...
Received on Sun Jun 12 22:52:10 2005