> believe me, I'm pretty upset the way things are going, and I also did
not
> mind to work this way ...
I have run into all these same problems when I was trying to fix Synch. I
would do some tests and everything would work, and the next day nothing
would work with no changes having been made. The improvements you have
made are great, do not let this discourage you.
> Ther problem is that this sync stuff is really pretty hard to verify.
> The unit test fo this mess would be absolutely wonderfull, but I can't
> imagine how to write it to guarantee its 100% isolation level.
> This last issue, I was not able to reproduce at all, until I completely
> deleted the workspace and started from fresh one.
> It means the unit test would also need to remove old workspace, set up a
new
> one etc ...
> Is there any way how to achieve it ? I have no idea how ...
Me neither. It would be great if someone wanted to start creating Unit
tests, but it will not be me.
> The problem itself was indeed related to removal of
> PersistantResourceVariantByteStore.
> It was his responsibilty to register the synchronization partner and
since
> it has gone, nobody was setting it.
> However, since I had an old workspace the partner was already
registered.
> Fix is pretty simple: add
> ResourcesPlugin.getWorkspace().getSynchronizer().add(qualifiedName); to
> constructor.
> Like this:
>
> public static synchronized SVNWorkspaceSubscriber getInstance() {
> if (instance == null) {
> instance = new SVNWorkspaceSubscriber();
>
> ResourcesPlugin.getWorkspace().getSynchronizer().add(qualifiedName);
> }
> return instance;
> }
>
> Regarding starting from square one, I do not think that it is necessary,
I
> believe the last patch
> solved the problems properly, this unregistered partner was just a
glitch I
> did not encountered in my environment.
> I tested it, everything seemed to work fine. I just did not started from
> clean workspace.
> All right, lesson learned, getting a fresh workspace has to be a part of
my
> testing scenario from now ...
>
> Last thing, an explanation of this PersistantResourceVariantByteStore
story.
>
> Initially I've introduced it as a way how to set the syncInfo on the
> resources.
> However, later I had to set the syncInfos on the resources directly (by
> means of Synchronizer) anyway,
> so the original reason for existence of
PersistantResourceVariantByteStore
> vanished.
> Later I've realized that both PersistantResourceVariantByteStore and my
code
> in SVNWorkspaceSubscriber
> were accessing the same syncInfo structures and under some conditions
they
> were conflicting there.
> Thus, since I'm setting the syncInfos a different way, there is no
reason
> why the PersistantResourceVariantByteStore
> should be there at all ...
Thanks for the explanation and fixing it. I just committed it. It sounds
like it was dumb luck that I started with a new workspace. Ironically, I
did it because I did not want the previous problems to have been
corrupting my tests.
All this being said, I did encounter some more potential problems, it is
hard to say for sure if they are problems or not.
I created a new workspace, checked out a project, then closed Eclipse and
restarted. I made some changes in another workspace and committed so that
I would have something to synch with. In my test workspace, I first
deleted a couple of files to test that the decorator was working. It
wasn't. I then said, oh well, let's try Synch. I did the Synch and got
all of the right info. I then selected the two files I had deleted and
took the Commit option. This committed the files but did not remove them
from the Synch view. I then tested updating the various incoming changes.
These all worked fine. I deleted the Synch, and did it again and the
outgoing deletes were gone.
Since the incoming updates all worked fine, I figured I would test
outgoing changes more. So I did some mods, adds and deletes. First off,
now whenever I delete a file the decorators all work! I do not know if
this is good or bad? Second, when I Synch, all of the commits now work
and refresh properly. In short, everything works correctly.
I do not have any explanations, which is why I am providing so much
detail. Perhaps the problem with the deletes not decorating and not
refreshing only happens if the deletes occur before the Synch option has
ever been taken? It sounds like some kind of "store" of some sort maybe
hasn't been initialized yet?
Since these problems seem relatively minor and you patches improved things
a great deal I committed what we have so far.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Fri Jul 1 22:32:18 2005