FW Data management – Collaboration & Maintaining Master Copy (technical)

Home Forums I can do it better FW Data management – Collaboration & Maintaining Master Copy (technical)

Viewing 1 post (of 1 total)
  • Author
  • #9950

    Here is a tutorial (or musing) for IT folks or technologically savvy individuals who serve in a church.
    This tutorial makes the assumption that as somebody who works in IT, you are familiar with the cloud platforms (Dropbox, Google Drive, etc) and version control softwares (CVS, SVN, Git, etc).

    The purpose of this article is regarding the administration of FreeWorship files, aka the contents inside “Data” folder which contains, and not only includes, Bible XML files, OpenLyrics XML files, maybe backgrounds (still and motion) and slide sets.

    From around the forums, I heard from other users about their concerns regarding hosting the contents of FreeWorship’s “Data” folder on the cloud for shared collaboration, of which Dropbox is a popular solution. The headache is when the file is shared with others, any content change by a shared user will inevitably incur an automatic file sync by Dropbox. This becomes a concern when an administrator wants to prevent unwanted changes to their “master copy”, especially because automatic syncing is the enemy of traceability. In reality, anything “auto-magic” is not helpful to trace changes.

    To combat this, I’ve proposed elsewhere on this forum to keep a “master copy” in a different location.

    • I’ve proposed keeping a “master copy” on a different Windows folder, and use a free/open-source file-comparison tool to compare the differences between the Dropbox location and the master copy.
    • I’ve also proposed to keeping a master location on a different Windows folder, and use a different cloud hosted service (hopefully free) to upload contents of the master copy.

    The drawback to either of the approaches above is that you have to manage files in two locations simultaneously.

    Then the planets aligned… I had an epiphany… What if the same “Data” folder can be shared with others for collaboration while at the same time while at the same time be treated as a master copy?

    The solution?

    • Use Dropbox on “Data” folder to be shared for collaboration.
    • Use Git on the same “Data” folder to administer with a master copy.


    • Using Dropbox on “Data” folder enables shared users to collaborate on the service. For example, an individual can update slide sets for announcements or other graphics while another can be working on the service, or another can modify a song as seem fit. The changes will then be synced across all shared users and everybody will be kept up to date.
    • Using Git on the same “Data” folder helps with maintaining a master copy because saved contents are kept in a “.git” folder. Users familiar with Git can therefore check changes with what’s committed; there is history, there is traceability, and best of all, the “.git” folder within “Data” folder can be synced on Dropbox, eliminating the need for another cloud-hosting service like GitLab, Atlassian BitBucket, etc.

    Thoughts on the Use of Git:

    1. The “.git” folder content is light, and if you don’t commit images, videos and binary content into Git, it will remain light and small. Dropbox will sync it without a problem.
    2. Song/lyrics content (MUST) – My suggested primary use of Git is to commit song files, which are the most permanent content administraters would like to control in the master copy.
    3. Bibles (OPTIONAL) – Committing Bible files is not necessary, but because they’re simple text files, it’s okay to commit them in Git.
    4. Slide sets (OPTIONAL) – Committing slide sets is not necessary, because those are less permanent content that changes over time. But if you want to keep history, they’re okay. Keep in mind that if there are backgrounds saved with the slide set, it might break unless the file location is a relative path within the “Data” folder. If the background is not found, at least you still have the text in the slide sets.
    5. Backgrounds (NO) – Committing images and videos in Git is not recommended. They can be large and over time they are likely to be moved around, renamed or deleted.
    6. As long as nobody deletes the “.git” folder, no history is lost. For an additional peace of mind, it might be a good idea to find a cloud-hosted Git server to upload your Git contents. These cloud-hosted services, if free, have limited space. If all you commit in Git are not images, videos, or binary content, you’ll be challenged to hit the capacity limit.

    References to other forum threads

    Assorted Suggestions From New User

    Is is possible to transfer my database to my other machine

Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.