Jump to content

New to Source Control and looking for easy... safe solution


Recommended Posts

1. What type of source control software you are using?

Git on GitLab with Git Fork or Git Tower 

2. You love it, or hate it?

LOVE it!!

3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else

We get to choose, and git is the scc system of our choice.

4. Pro's and Con's of the source control you are using?

Pro: Decentralised, very popular (i.e. many teams use it), very flexible, very fast, feature branches, tagging, ...
Con: Complicated to set up if using SSH, Exotic use cases/situations can be very hard to solve and sometimes need turning to the command line

5. Just how often does your source control software screw up and cause you major pain?

Never. It's always me (or another user) doing something wrong. For our internal team of 5, it never happens. For our customers, the occasional problem occurs.

 

As mentioned above, we use Git Fork and/or Git Tower as our graphical UIs to git. IMHO, using a graphical client is soo superior to working with git on the command line (but I'm posting to a LabVIEW forum, so who am I telling this?).

In order to avoid having to merge VIs (we actually do not allow that in our internal way of working), we use the gitflow workflow. It helps us with planning who's working on which parts of an application (repo). I honestly can count the number of unexpected merge conflicts in the last few years with one hand.

On top of git, many management systems like GitHub, GitLab, Bitbucket etc. offer lots of functionality like merge requests, integration with issue tracking, and other project-management-type features.

Edited by joerghampel
  • Like 2
Link to post

1. What type of source control software you are using?

Currently use Git for my LabVIEW work with my repos hosted on github.com

2. You love it, or hate it?

Love it. Sure there is a learning curve, but anything worth learning will take a bit of time.

3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else

My choice. I have gone down the path of Nothing-->Zips-->SVN --> Mercurial --> Git   and am happy with git. I still have heaps to learn (even coming from pretty high competency with Mercurial), but I am treating this as an opportunity to get better.

4. Pro's and Con's of the source control you are using?

Pro: Lot's of resources out there to help me when I screw up. Git is ubiquitous now. I love the GitKraken client!

Con: Some of the things still confuse me a bit, especially how local and remote can have different branches.

5. Just how often does your source control software screw up and cause you major pain?

I don't think I have ever actually lost work or been caused major pain because of my misuse of source code control. Certainly I have made mistakes but have always managed to recover things. Contrasting this, I still sometimes lose stuff when I am being careless with documents that are not yet under any kind of control

In a nutshell I could not live without Source Code Control as a regular part of my daily workflow.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By maristu
      I’m a big fan of JKI VIPM, and I’ve been usen Source code control with labview for some years (First with mercurial and now with GIT). Following the good practices with SCC and LabVIEW I always check the separate compiled code from vi to avoid unwanted changes on Vis.
      In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project…
      My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?.
      Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling
       
      Thanks!!
    • By Francois Normandin
      As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github.
      I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done!
      For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:
    • By MrShawn
      Hi all,
      I am fairly new to Labview development.  I want to implement revision control software (SVN in particular) to my workplace.  Before I can do this, I need to prove the concept and usefulness of the SVN application for us.  I have used SVN in some degree in the past, and noticed tortoiseSVN integration with Labview via the TSVN Toolkit.  I have a few questions regarding SVN and how I should organize my project files, in particular when using SVN.
      File organization has been a particular gray area for me in Labview, unlike linking my libraries and specifying their locations I don't seem to quite have that control in Labview.  This issue is somewhat more exacerbated (or at least so I think) when I began using SVN.  Let me explain: Using the TSVN toolkit it sees that my entire class (which was developed in a separate directory - then linked in) is not sourced and revisioned.  This is also the case for several other libraries which I have borrowed or developed myself.  I have two primary questions regarding this.
      The first - How does SVN add/commit these project files when they are not present within the project directory itself?  In fact I have created a separate repo for the class which I use to maintain that code.
      The second - Is my file organizational design fundamentally flawed? Especially in the context of SVN?  What are some good organizational tips/ schemes (when using SVN) which would help me for future projects in avoiding issues such as this? 
       
      A  less pressing question:
      How well does the "merge" functioning work with the Labview VIs?  Remember I am do not have the most experience with SVN - it is my understanding that merge basically would merge changes I have made back with changes by other devs to the file along the main trunk(?).  
       
      Thanks in advance.
      MrShawn
    • By Tim_S
      Our IT department is rolling out a SCC package called Version Dog to our site. Looking a the website, it looks to be geared for PLCs but down in the documentation it mentions LabVIEW. Has anyone heard of this before? Used it? Have opinions on it? Not impressed by the amount of openly available non-fluff information on the website.
      We do have a SVN server running, however the network changes from when the current owners took over have FUBAR our ability to connect to SVN from our desk. This appears to be a much needed effort to version control the PLC programs (long overdue) and an attempt to close out IT work tickets that are many years old.
      Thanks in advance for any replies.
    • By JackDunaway
      While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one!
       
      After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.
       
      So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore
       
      Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.
       
      Here's the contents of the file right now:
       
      # http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps How can this be improved?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.