Correction, we are using PushOK 1.7.0 RC2 32-bit on Windows 7 64-bit. We use SmartSVN as our subversion client.
What do the SVN overlay icons in the Windows Explorer view show? We use SVN but do not integrate it with our RH project. We just check out the required files, open RH, make our changes, close RH and check in via the Windows Explorer SVN interface. Have you tried this to see if this works?
The Windows Explorer icons are either marked with a green circle with a white check mark in it or a red circle with a white exclamation point in it. More often than not, the icons end up having the red circle with the white exclamation point.
Yes, we use Smart SVN 7.5.2 as our SVN client. And yes, we can add the project into the SVN repository, open the project in RH, make changes, save changes, update the SVN, see the changes, and commit the changes.
But shouldn't the Adobe software work as it should with the plug-in they suggest? Why did our previous version (RH8) work with the plug-in, but this does not??
Yes it should but I'm just trying to see whether it does. The green icon shows a file is up to date with the SVN repository but the red icon with an exclamation means there is a conflict between the repository and the file on your PC. This may explain RH's behaviour. What I'd do next is to check the SVN repository on one of the conflicted files (via Windows not RH) and see whether the file is up to date there. If it isn't you'll have to solve the conflicts before going any further.
I'm not sure the icons have anything to do with it. This check-in problem only affects one of our six help projects. And, some of the others have the red icon, but they work fine.
If the problem is related to just one project then that discounts any problem with SVN or the PuskOK plugin. The issue must be with that project. I really think the next step is to interrogate those files with the conflicted status. Out of interest are they the same files that you are having issues with?
It's actually happening to two projects with two different results. I have no idea how it could be due to the particular project. It worked with RH8. This is the process I followed in trying to solve the issue:
1. Copied all files and sub-folders to a new folder.
2. Stripped the .svn files from the new folder (to make it unversioned).
3. Imported the new folder directory into the SVN repository.
4. Committed the new folder directory to the repository. (It is now versioned).
5. Perfomed metadata validation and clean-up function. No problems or clean up issues detected. All files at this point have the green icon in Windows Explorer (I have double and tripled checked).
6. Opened the new directory .xpj file in RH. Processed the upgrade from RH8 to RH10 for the project files. Used the "Add project to version control" command.
7. Project opens, showing all topics with a "checked out" status.
8. I am able to check in all topics (only during this time--the first time after the project is added to version control)
9. Close project.
10. Attempt to reopen project.
11. Plug-in status freezes at "Updating Version Control" (I have literally waited hours on this part, and Task manager indicates very, very little activity in either RH or PushOK.
12. I can unplug my network cable, open the project offline, and all statuses are "read-only." This does me no good.
1. Imported the old directory into the SVN repository.
2. Committed the old directory to the repository.
3. Perfomed metadata validation and clean-up function. Metadata indicates that some files were corrupted. But still, all files at this point have the green icon in Windows Explorer (I have double and tripled checked).
4. Opened the new directory .xpj file in RH. Processed the upgrade from RH8 to RH10 for the project files. Used the "Add project to version control" command.
5. All files show checked in (blank) status.
6. Change a topic and save. Checked out status shows. Attempt to check in. PuskOK plug-in window shows activity, then leaves the "checked out" status.
7. Close project. Reopen project.
8. Topic previously changed now has a "read-only" status; however, the change was committed with the SVN client.
Other things I have already tried with both of these projects:
Deleted the cache file .cpd before opening in RH.
Told the SVN client to ignore known file trouble-makers (cpd, pss, ssl, ldb, elHlp, $rhvariable, etc).
Upgraded the project to RH10, THEN copied to a new folder, stripped SVN files and completed all steps in Project 1 above. Same result.
With project 1, the process stagnates. With project 2, it's actually making changes, just not updating the RH status correctly.
However, I AM able to import the files into the SVN client (without the .svn files), add to repository, open in RH, NOT using the "add to version control" command, making changes, then updating the SVN client. For all intents and purposes, I am successfully using version control. Just without the convenience of Push OK doing the back and forth for me. But shouldn't it work???
From what you are saying it seems like two of your six projects are working 100% OK. This seems to say that the other four projects are not having any problems using the PushOK plugin with RH10. I am just trying to narrow down the problem. If this is correct, the problem could be either with the plugin or the content you are trying to add to source control. If all projects are suffering the problem it probably is only the PushOK plugin.
Could you try something for us. Can you create a brand new project in RH10, add it to SVN via PushOK, open the project, make some amendments and see if you can commit the changes successfully. If that works, can you see if you have a RH8 project that you can upgrade (not one of the six you refer to) and do the same with that. Having the detail of what happens to those will help us narrow down things further.
BTW the SVN client is notoriously bad at refreshing the icon status on files. I've learnt to take the SVN status icons with a HUGE pinch of salt. Sometimes closing / opening a folder or window helps, sometimes rebooting the PC helps, other times I just give up looking at the icons!!
As an aside you say that in the second project that there were indications of corrupted files. Can you tell us what files these were and whether these were in the repository?
Thank you for the suggestions. The results of doing what you suggested were:
I was able to create a brand new, blank project in RH10 and added it to SVN through PushOK. All went well, and I was able to make changes and commit them sucessfully in RH (correct status appeared, no red checkmark etc, and SVN showed the change with no difficulty). However; I attempted multiple times to add a new topic, and RH would freeze when I clicked OK on the Add New Topic window. The lower left-hand corner would freeze on "Querying version control status" and never recover. For testing purposes, I created another brand-new and blank project in RH10, added the new topics first (with no problem), then attempted to add the project to version control. Again, the app froze for over an hour.
Second suggetion: I found another RH8 help project and upgraded it, added it to version control, checked all in, made a modification, and attempted to check it in. It continued to show the checked out status, although SVN showed the change. Upon closing and re-opening the project, the modified topic still showed as checked out. I then attempted to make a modification to the same topic. I make the modification and save it. I attempt to check it in, but the same checked out status. I then try to commit the file in SVN and get a a "Working copy is locked" warning, followed by a processing command telling me to run the clean up function. I run the clean up function and get the processing command: "The node 'C:\pathexample.htm#bookmarkname" was not found. Then it once again tells me the working copy is locked. Just a side note, the Validate Working Copy Metadata detects no problems.
I am also experiencing the same "attempt to commit/working copy locked/run cleanup/node error/working copy locked" circle with the problem projects. The only difference there is that the Validate Working Copy Metadata process shows corrupted svn files (thousands of them).