[attachment=0]DupUUID.jpg[/attachment]Hi Folks - hoping for some clarity on the SVN Process and how it interacts with Serclipse if possible? I’ve recently converted this solution to SQL Anywhere from MySQL, so this could (probably is) in some way associated with this problem.
I renamed a form in my solution and this form had a number of methods in an attached .js file. The rename went fine and the solution was still intact and running with no errors, but I decided to revert to an earlier version from SVN (the most recent version - taken just before the form rename) using overwrite and update, and that seemed to go OK too.
However, I now have a number of errors indicating that all of the .js methods have duplicate UUID’s and the Quick Fix is indicating that the new form name is still somehow in existence??? This .js file is now correctly attached to the original named form - though with these errors flagged in the editor page.
I have searched for the renamed file and found nothing - using search and Navigator. Quick Fix appears to solve the problem (and asks to generate a new UUID for either the new or the old form name) but actually does nothing - on rebooting developer the errors are back.
I’m guessing its (the new form name) being cashed in the Db some place - as I’ve actually overwritten the entire Servoy directory in an effort to get rid of these errors. The only thing that’s not changed is the Db.
When running MySQL we wer’nt using the repository, just a workspace - but I’m wondering if, when using a standard install of Servoy, (which we did with v5 in order to get the SQLA Db system in) Servoy is actively using the repository now. So, couple of questions:-
++++++++++++
Additional:
I’ve searched the system for the same UUID and it only appears once in the workspace
I did a Clean - with no further change!
++++++++++++
Q. Can I turn off the use of the repository when using Sybase?
Q. Is there some way to flush these errors on a phantom form?
I searched my WorkSpace in win explorer and discovered the offending form and .js files. They we’rent shown in the Servoy explorer, nor could I see them in the SVN repository.
It seems that when I renamed the form and then reverted from the SVN - a new form was added with all the same UUID attributes - and therefore there were two form sets clashing.
I’ll remember that for future - though why Servoy could see the clashing UUID’s and yet not show the listing for the second form I don’t understand?
I know that when I update from SVN, there are sometimes error because it seems that Servoy is keeping an internal cache and it can have conflicts with what you just checked-out. A simple restart is sometimes all it takes to get everything back to normal.
Patrick - yes I know what you mean - and almost all the errors I’ve had have been dbi’s or have been cleared with a re-start of developer.
However in this specific instance I think I probably missed the logic of it. For e.g. Rename a a form and upload to SVN - revert to original with an overwrite from SVN.
I had expected that SVN would recognise this form as the original (possibly using UUID - or at least its own tracking data) and overwrite it. In fact it appears to have reinserted the original form but left the other form in existence in the WS too. Hence there being duplicate UUID’s in the WS.
I would have thought Servoy would have been able to display both UUID’s simultaneously and flag them as conflicting - where in fact it showed the original form and its .JS with errors (as dupes in the .js file) but not the new conflicting form (even though it was sat in the WS).
It was even more confusing when I looked at the conflict in code comparison mode and noted the two .js files were identical.
I also tried to delete and have the UUIDs recreated in the .js file for each method (I assumed that deleting the comments with the UUID and saving would create NEW UUID’s - it created them but I forgot to check if they were new ones or not.
All very confusing - but at least it got me looking into the WS - I’ll know to look there in future should this happen again.
