"Martin Letenay" <mle@whitestein.com> wrote on 07/06/2005 05:35:04 AM:
> I hope I'll be faster, but in case the 1.2.1 of svn will be released
sooner, I
> would suggest to not make a new subclipse release yet.
Svn 1.2.1 was released last night, but I need to wait for the Windows
binaries to be posted. It is hard to know when that will be. I can wait
a little bit after that but I do not want to wait for too long because of
the Eclipse 3.1 bug that exists in the current release. A lot of people
are asking about that and it would be nice to get rid of it.
> In your last observations you pointed right that the sync stuff is
working
> properly only after first synchronization is performed.
> It was the last drop, so I decided that the whole status cache and
surrounding
> code has to be rewritten nearly from scratch.
>
> The major problem there was, that we were using our proprietary
> StatusCacheComposite in StatusCacheManager as a cache for svn status
results.
> It seems there was a reason for that (according to class comment:
> IResource#setSessionProperty and ISynchronizer#setSyncInfo were also
> considered, but could not be used).
> The reason why ISynchronizer#setSyncInfo was not used, was that it was
> modyfing the workspace and there are situations when the workspace is
locked
> for modifications.
>
> However, for deleted and added resources to work properly as phantoms,
the
> syncInfo stuff had to be set anyway.
> Unfortunatelly, what we had so far was not a solution but rather a
clumsy set
> of workarounds ...
> My sync patches did that stuff, but at the end we were storing
more-or-less
> the same sync info in two places - StatusCacheComposite and
ResourceInfo#syncInfo.
> The later one being updated with a little delay in a different thread by
> SVNWorkspaceSubscriber.
> That was the reason why it worked properly only after first synchronize
action
> was done (and SVNWorkspaceSubscriber singleton was instantiated).
>
> So I took a deeper look into CVS plugin again and inspired a bit there.
> I've implemented a new status cache which directly stores the syncInfo
via
> ISynchronizer#setSyncInfo and it also takes care of situations when the
workspace
> is locked (some pendingCacheWrites). Some significant amount of
surrounding
> code was also improved/updated/fixed.
> However, from the safety reasons, I also kept the old
StatusCacheComposite
> there. I've abused the old StatusCacheComposite switch (save sync cache
in workspace),
> so it can be turned on/off.
I would rather just see you get it working good enough that you feel good
about getting rid of the old code. I would think that the saving of the
cache would still be something we need/want.
> So far everything seem to work fine, but I'd rather test it for few more
days
> so I'm not going to post any broken code ...
> If everything will work as I expect, I believe that the both correctness
and
> performance of the synchronization stuff will be improved noticably ...
It all sounds good. I do not mind helping you test if you want to send it
to me.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jul 7 00:30:15 2005