Announcement

Collapse
No announcement yet.

Using Git on Linux to Manage HomeSeer Scripts and Files

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Using Git on Linux to Manage HomeSeer Scripts and Files

    I was wondering if anyone is using git (open source distributed version control system) to manage scripts and added files. If you have tried it do you have any opinion about pros/cons?

    Thanks

    #2
    I have installed and set up the scripts directory as a repository. Added and committed all the files. It was easy to setup and I will report back any learnings.

    Comment


      #3
      I do, but the benefits are not that high because all HS configuration files are binary.

      I would love plain text config files :-(.
      That would allow us to really version control our biggest hobby (which has cost us lot of time and money)

      Verstuurd vanaf mijn SM-G965F met Tapatalk

      Comment


        #4
        The files in HS/config (*.ini) are all text. I had not considered making them part of the VCS but I will now. Thanks! I have alot of .vb scripts so that was my original plan. I also use perl, gnuplot and bash shell scripts. All text files. I also need to get all of the exe.config files in the HomeSeer directory.


        Comment


          #5
          Originally posted by kriz83 View Post
          I do, but the benefits are not that high because all HS configuration files are binary.

          I would love plain text config files :-(.
          That would allow us to really version control our biggest hobby (which has cost us lot of time and money)
          Jon00's Event Viewer and Documenter creates both a text and csv file of your events. Can be scheduled to run via an event. Files are located in HS's html sub directory.

          Comment


            #6
            Originally posted by AllHailJ View Post
            The files in HS/config (*.ini) are all text. I had not considered making them part of the VCS but I will now. Thanks! I have alot of .vb scripts so that was my original plan. I also use perl, gnuplot and bash shell scripts. All text files. I also need to get all of the exe.config files in the HomeSeer directory.

            Technically you can put any type of file in git. I use git extensively for development and for binaries as well. You can't do a diff between binaries of course but you can store them and if there's changes between them revert to a different version.

            A system I've used before was to do an install and then add everything into the git repo. Then move the original install location and then git clone my repo to the install directory location. That way the install and paths are all correct but the full contents are in git. So you can very easily make a branch and then upgrade and run it and if it works tag it and commit it. If it doesn't work or there's a problem you can then revert back.

            git on linux is your friend. Now I've never tried that on a Windows box so I dunno how well it will work out.

            Comment


              #7
              Git is not suited for large binary files. You should include the ini files too, but then you're still missing timers, events, devices, ...

              HomeAssistant installs I do for customers are completely put in GIT.
              Custom programs that run on RPI's are also in GIT, and typically work on read-only filesystems. During startup latests software versions are pulled via GIT too.

              Comment


                #8
                I decided to not backup the binaries and other stuff that changes too often. I have backups to deal with this so I made a compromise. For anyone else who wants to ignore files here is a fairly complete .gitignore file. This keeps the data to .vb, .sh, .txt, .cfg, .temp, .cs and .csv.

                Hope this helps someone.

                #The picture files
                *.gif
                *.png
                *.jpg
                *.jpeg

                #The sound files
                *.wav
                *.mp3
                *.ogg

                #The database files
                *.hsd
                *.s3db
                *.db
                *.db-journal
                *.ZWave

                #The Log files
                *.log

                #The backup files
                *.bak

                #The zip files
                *.zip
                *.gz
                *.tgz

                #The Emacs backup files
                *~

                #miscellaous files
                *.err
                *.xml
                *.pdf
                mochad
                *.rules
                *.pfx
                tempfile1

                #ini files that change too much
                *.ini


                Comment


                  #9
                  Here is an interesting side benefit to using git. When I make changes to HomeSeer in configuration, events, etc the files that are affected change. I did not expect it to be a learning tool, but it certainly has been one.

                  Comment


                    #10
                    I am in the process of learning git. I'm making slow progress, but the effort seems worthwhile because of its general usefulness.

                    It occurred to me today that git might be very useful for tracking software changes to my HomeTroller SEL. It seemed like it might be educational, but also very convenient for backing out of changes that didn't work out. My forum research led to this thread, which I've found very helpful -- especially the .gitignore file offered by AllHailJ .

                    Thank you to all of this thread's contributors.

                    Comment


                      #11
                      I like it for scripts. Being able to back out "enhancements" has saved many hours of work.

                      Comment


                        #12
                        Originally posted by simplextech View Post
                        A system I've used before was to do an install and then add everything into the git repo. Then move the original install location and then git clone my repo to the install directory location. That way the install and paths are all correct but the full contents are in git. So you can very easily make a branch and then upgrade and run it and if it works tag it and commit it. If it doesn't work or there's a problem you can then revert back.
                        simplextech , it seems you've said something important here, but unfortunately, I don't quite get it.

                        I had envisioned a simple git init at the top level of the HS3 software tree, with a .gitignore file to exclude files of little interest. Each time I made a significant system change -- new or updated PI's, updated HS3 version, new devices and events, etc. -- I would simply make the changes, git add them, and commit. All done. If, say, a PI update caused more problems that it solved, I would expect that I could simply git checkout any previous snapshot that I liked better, and I'm good to go.

                        You describe a more complicated process. I suspect this may be because either (a) what I have in mind won't work, or (b) your approach has advantages that I haven't appreciated. Or perhaps I haven't yet learned enough about git. Can you tell me what I'm missing?

                        Comment


                          #13
                          Originally posted by ericg View Post

                          simplextech , it seems you've said something important here, but unfortunately, I don't quite get it.

                          I had envisioned a simple git init at the top level of the HS3 software tree, with a .gitignore file to exclude files of little interest. Each time I made a significant system change -- new or updated PI's, updated HS3 version, new devices and events, etc. -- I would simply make the changes, git add them, and commit. All done. If, say, a PI update caused more problems that it solved, I would expect that I could simply git checkout any previous snapshot that I liked better, and I'm good to go.

                          You describe a more complicated process. I suspect this may be because either (a) what I have in mind won't work, or (b) your approach has advantages that I haven't appreciated. Or perhaps I haven't yet learned enough about git. Can you tell me what I'm missing?
                          I think the only added "complicated" step in my previous reference was the tagging of the version and removal/clone step. Easier to keep track of tags than commit entries (to me anyways). I included the remove and clone as I hate doing something and it not work correctly and then having to tweak around it. Rather than deleting you could just move things to a new name and then clone to the original location for testing. Your description included more of the details than I provided but it's essentially the same steps and same outcome. Including the .gitignore is a nice addon that I didn't mention. Useful to help keep things cleaner.

                          Comment


                            #14
                            hey John simplextech are your prod system still on cqc?

                            Comment


                              #15
                              Originally posted by MattL0 View Post
                              hey John simplextech are your prod system still on cqc?
                              I'll take this to PM

                              Comment

                              Working...
                              X