VersionRecall not updating repositories consistently

[ssr025]

To help you better we need some information from you.

*** Please fill in the fields below. If you leave fields empty or specify 'latest' rather than the actual version your answer will be delayed as we will be forced to ask you for this information. ***

Product, version and build: VersionRecall 1.8.72
Operating system: Windows Server 2019 Standard
PowerShell version(s):

*** Please add details and screenshots as needed below. ***

DO NOT POST LICENSES, KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM

We have VersionRecall set up to update repositories every 6 hours but it is not doing this consistently.

Here is the D:\Websites\websites.recall file contents:
[Depot]
Name=Websites
DepotFolder=D:\PreviousVersions\VersionRecall Repositories\Websites
AlternateFolder=
FileTypes=*.*
ExcludeTypes=
Recursive=1
HasVersions=1
Synchronize=0
MaxVersions=0
LogHistory=0
SignFiles=0
LogTypes=*.vbs;*.js;*.ps1;*.psm1;*.cpp;*.c;*.h;*.hpp;*.cs
SignTypes=*.vbs;*.js;*.ps1;*.psm1
Certificate=
TimeStampURL=http://timestamp.globalsign.com/scripts/timstamp.dll
LogActivities=1
[Service]
Active=0

Attached are the VRKService.log and Service.inf files. The log file shows that repositories were updating correctly from 10/15/2024 to 10/25/2024, but stopped updating after that.

[Alexander Riedel]

According to the log the update ran again yesterday:
10/25/2024 09:29:03 AM Updating repository Websites
11/19/2024 09:13:43 PM Updating repository Websites

Generally that is an indication that either the tray application was not running or the user which is associated with the tray application was not logged on.
Please check if the VersionRecall Tray application is set to start automatically after a restart.

[ssr025]

The repository updated yesterday because I opened VersionRecall on the server. Since then, it has been updating repository every 6 hours like it's supposed to. Not sure why it stopped after 10/25. I checked the Startup Apps on the server and VRKTray is listed.

[Alexander Riedel]

So this is installed on a server? VersionRecall was created as a user endpoint application, not a server application.
The purpose is to submit changes from multiple users to a central repository and track access and changes.
Running it on automatic on a server removes the tracking of who's done what entirely.

Additionally, the tray application requires a user to be logged in. Tray applications do not run when nobody is logged on.
So the tray app started to work again because you logged in, not because you started VersionRecall on the server.
As soon as you logged out or will be logged out automatically, the tray app will terminate.

Not knowing exactly what your environment and your goal is, makes it difficult to provide any additional recommendations.
Please feel free to elaborate on this if you would like any additional suggestions.

[ssr025]

Thanks for the info. We have 2 developers who make changes to our ColdFusion code repository which is located on the server. Our main goal is to track different versions of the ColdFusion files. It actually tracks versions quite well when the repository updates run according to schedule, but the updates have been running sporadically, I guess only when one of us was logged into the server as you mentioned. We're not that concerned about who did what but would be nice to know. So what would you recommend in our situation? Should each developer have VersionRecall installed on their local system and have it pointed to our ColdFusion code repository on the server?

[ssr025]

Alexander, can you provide a response to my 11/22 question on what is the best way to set up VR in our environment?

[Alexander Riedel]

My apologies, I had it all lined up what to answer but as I was traveling I seem to have that spaced out. Again, apologies.

Let me preface this with mentioning that I know not one thing about ColdFusion development or how your environment is set up. I will just describe in broad strokes was has worked best for me in the past and you can take from that what applies to you.

Generally I urge everyone to always edit code locally. On their hard drive. With virtual environments there may be no such thing as a local hard drive, but you can still have storage space localized to you as the user. Then you publish to your server code repository, if that is what you need to do, submit the changes to a version control system as well and, by some schedule, create a backup. The main point here is that only code that is deemed working is submitted to any place where someone else may go and grab it for further work.

The first reason for this is that code, while being edited, is almost always not in a compile-able or executable state. So by editing directly in a server repository you
have the potential of keeping other from using whatever app or site you are working on until you are finished with your changes. As teams grow larger and communication inevitably suffers, this becomes ever more important to avoid.

The second reason is that doing this has the code exist in more than one place. If you and your other developer edit locally and publish to a server, the code exists in three places.
If and when you submit your changes to a version control system, you have a fourth place. I hope your VRK repository is not on the same server where you normally keep your code.
Hard drives, SSDs, any hardware really, can fail. If you have a single point of failure it can come back to haunt you. I have my own story about the IBM DeathStar, err, sorry, DeskStar drives.

Thirdly, each individual submitting from their user id and their machine creates a history of who has done what and when. This may be important when you need to hunt for that prior version you need to restore, when something went sideways.

As a general policy each developer should submit their changes to a Version Control System repository every time they reach a milestone in your development. Be it a feature that is complete, a point release or a submit to QA that has to happen. This is manual, since the software just doesn't know what you are thinking (yet). But people forget. Some more than others. So it is prudent to have a fall back and submit regularly by a schedule. Personally, I have it set to Friday 3:00 pm, which is generally done before the weekly backup runs.

Version control also does not replace regular backups. You still need to do those on a regular basis and hopefully these are stored outside of your regular environment.
I see in your original post that you attempt to auto-submit every six hours. I don't know your development schedule, but that feels as if it was way too often.
Creating more versions does not necessarily make you safer. But it will make it harder to find what you need in case of a blunder, since you have to wade through a much larger number of iterations. As I said before, submit manually when the code is deemed working and auto submit on a reasonable schedule as a fall back. Daily if you must, but usually weekly works well in unison with manual commits.

I hope this helps. Please let me know if you have any questions.