• AVR Freaks

Helpful ReplyVersion Control for MPLAB C Code

Author
JTP5568
Starting Member
  • Total Posts : 37
  • Reward points : 0
  • Joined: 2018/04/16 16:22:06
  • Location: 0
  • Status: offline
2018/08/10 06:37:43 (permalink)
0

Version Control for MPLAB C Code

Hi All.  I am relatively new to the PIC embedded development with PIC microcontrollers and was wondering what everyone uses as version control for commercial development.  I have some new designs I am looking to "release" and need a way to properly maintain and archive my C code.  Thanks all in advance.
#1
Jim Nickerson
User 452
  • Total Posts : 6184
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: online
Re: Version Control for MPLAB C Code 2018/08/10 06:44:59 (permalink)
+2 (2)
I use GIT
#2
KTrenholm
Super Member
  • Total Posts : 710
  • Reward points : 0
  • Joined: 2012/08/08 14:04:23
  • Location: Connecticut, USA
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/10 06:49:27 (permalink)
+1 (1)
I use Mercurial with TortoiseHG Workbench.  I like it well enough, although I don't think I really use it to its full potential.  Mostly just committing and updating a single branch for most firmware I write.  I definitely like it more than SVN, which I think is rather dated now if I'm not mistaken.  I'm pretty sure MPLABX has a plugin for integration with Mercurial (and some others), but I've never used it.
#3
malaugh
Super Member
  • Total Posts : 400
  • Reward points : 0
  • Joined: 2011/03/31 14:04:42
  • Location: San Diego
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/10 08:24:10 (permalink)
+2 (2)
The revision control systems most people use are Subversion and GIT.  GIT is gradually taking over from subversion, but personally I use Subversion.
 
The biggest difference between the two is GIT uses two repositories, a local repository and a remote repository.  The way this is works is changes are first committed to the local repository, then these changes are committed to the main repository in a second process.  Subversion uses a single repository.
 
I depends what you need.  If you are a lone developer then Subversion would be a good choice, since the added complexity of two repositories is not needed and unless you have a good backup process for your local computer, the chances of loosing work are greater with GIT.  Even with one or two developers working on the same project, Subversion is a good choice.
 
As for the main repository, you an use your own computer (which I would not recommend), a company server (which is what I use), or an on-line service, which is the easiest to maintain.  BitBucket is the most used on-line repository for GIT, and there are a number of companies offering on-line Subversion repositories.
 
As for client programs, my all time favorite is TortoiseSVN.  It integrates into the file manager on your computer and in addition to check-in and check-out it has a ton of really useful features to inspect the revision history of file and projects.  Mplab-X has commands to check in and out directly in the IDE.  I have never tried them so I cannot say how good they are.
 
 
 
 
#4
twelve12pm
Overseer
  • Total Posts : 325
  • Reward points : 0
  • Joined: 2012/04/09 17:27:24
  • Location: 0
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/12 10:18:53 (permalink) ☄ Helpfulby Antipodean 2018/08/13 03:56:09
+3 (3)
We use Subversion and have been using continuously it since 2007.

Some people say that GIT is taking over or that Subversion is old. I don't think that is true at all. Subversion is under continuous development and a new version of Subversion was just released a few weeks ago. I think the Internet has a way of skewing perceptions and in this case it's because most open source efforts have switched their version control from CVS or Subversion to GIT, thanks in part to the convenience of GitHub, which has become something of a social platform as well as a cloud code storage place.

Because of GIT's popularity in the world of open source, we recently evaluated it to see if we should switch, and we decided to stick with Subversion. Here's why:

The executive summary: Subversion is better suited to business. GIT is better suited to open source efforts.

The long version: Both systems are designed to allow many people to collaborate on something. Subversion is a centralized version control system. GIT is a distributed version control system.

Subversion's centralized nature means that it has a "client/server" architecture. You can use it on just one computer if you're working by yourself, or you can put the server portion of it on a server and then multiple people can interact with it using the client portion. The server portion contains a central "repository" of files. Each person gets a "working copy" of those files and does their work in the working copy. When they're ready, they can receive an "update" of the latest information from the repository, and when they've created something new (a bug fix, a new feature, some milestone reached), they can "commit" their changes to the repository. Subversion takes care of all the details behind the scenes so that earlier changes are not forgotten when later changes are made, etc. It can handle text files (like source code) and binary files (schematics, PCB layouts, Word documents, etc). You can put any kind of information into Subversion. If multiple people work on the same file at the same time, it can automatically merge their changes together when the files are text, like source code. For binary files, it cannot do the automatic merging (neither can GIT or any other version control software for that matter) so it offers you the option to require a "lock" on binary files, so that only one person can work on such a file at a time, kind of like taking materials from your local public library and then bringing them back. In practice, we've never used locking; we just communicate with each other and have a daily 10 minute morning meeting where we discuss who is going to work on what, and everything just works out. In a larger organization you might need to use the locking feature. Subversion also offers permissions so that you can have some files accessible only to certain people, etc.

Subversion has a lot of advanced features, including a "telescoping" ability (called viewspec in some version control systems) where you can do a sparse checkout and expand only the directories you want. You can also put arbitrary attributes on files and directories, define "externals" (very useful for constructing a software directory that includes source code coming from various libraries), etc. Also, some new features are in development right now to compete with distributed systems like GIT, including shelving and checkpointing.

Subversion itself is open source and comes with a command line client, but there are GUI clients available, both free (e.g., TortoiseSVN) and commercial (e.g., Cornerstone). The command line client is very easy to use. There are only about a handful of commands you'll use regularly. When I need something outside of that regular set, I find it within a few moments in the book.

GIT on the other hand is a distributed system, which means there is no client/server architecture and no concept of a central repository and satellite working copies. In GIT, instead of checking out a working copy, you clone someone else's entire copy. If you have more than one person working on something, you could work as a peer-to-peer, exchanging your work with each other, or you can put a copy on a server and designate that one the "central" one even though there is no such concept in GIT. This makes GIT particularly useful to open source efforts, where anyone from anywhere in the world might want to participate. It makes it easy to "fork" something if you don't like the direction its development is headed and you want to take it in a different direction. It is also why proponents of GIT claim that it's "faster" -- because all the files are local on your computer and there is no need to communicate with another computer unless you are receiving or sending information between them.

In practice, there are actually disadvantages to this distributed nature. For example:

In Subversion, you can do what's called a Monolithic Repository or "monorepo" for short. This is where you organize all your hardware/software/documentation projects into a single repository. Then, each person can check out only the portion they need to work on. You can have as many checkouts as you want, by the way.

In GIT, things don't really work that way. Because every check out is actually a clone, if the repository gets too bit in GIT, it becomes a serious PITA when you start having multiple people working on it (because everyone has to clone that huge repository). Also there is no permissions (except repository-wide permissions) so you can't protect some sensitive files; you have to put anything sensitive into a whole different repository and disallow access to it. Because of these reasons, in GIT, it is recommended to create a separate repository for each project. In practice, that means each board you create will need a repository; each software you write will need a repository; etc. Each person who works on something needs to clone the repository for it. All of these things together lead to a proliferation of repositories where you might end up with hundreds of repositories in even a small organization, and it's difficult to manage or keep track of.

For a business, Subversion's one central repository gives the following advantages:

(1) You know where your stuff is. It isn't scattered in hundreds of repositories.

(2) You have one thing to worry about backing up -- and you do need to have reliable backups including off-site backups for all the usual reasons (but this is true regardless of what system you use -- it's just easier to do when it's in one place).

(3) It may sound like this becomes the one weak link in your chain, but the flipside is that because you have one important asset to worry about, you can take steps to make sure that this one asset is well-protected and backed up.

(4) Subversion doesn't limit you to one repository; you can create as many as you like, if that makes sense to you.

Note that with either system, you can get commercial technical support. Some companies that participate in Subversion development include: WANdisco, Assembla. Also I should note that we thought about going with Perforce, which is a commercial system you may also want to look into. Ultimately since we are already using Subversion and It Just Works (tm) we have stayed with that. Just thought I'd mention it anyway.

I recommend you give a fair evaluation to both Subversion and GIT -- and be mindful that the Internet is full of hype and b.s. so you need to evaluate reality, not hype; also note that much of the pro-GIT hype out there contains criticisms of Subversion that are not true, or that were true a long time ago but are no longer true -- as I said, Subversion is under continuous development and it has improved a lot over the past decade, particularly in terms of better branching and merging, as well as faster speeds. So, bottom line, don't just choose based on hype; give some real thought to where you are today and what you hope to achieve in the future, and then choose the system that will best serve you.
#5
Jim Nickerson
User 452
  • Total Posts : 6184
  • Reward points : 0
  • Joined: 2003/11/07 12:35:10
  • Location: San Diego, CA
  • Status: online
Re: Version Control for MPLAB C Code 2018/08/12 10:42:27 (permalink)
+2 (2)
I started out with SVN and was very happy for many years.
I made use of the SVN revision numbers within my code.
Built in support for SVN within MpLab X and Visual Studio and free SVN servers became a problem
I also develop in Visual Studio.
I switched to BitBucket and it has been working within MpLab X (net beans) and Visual Studio for some time now.
I also make use of Tortoise Git for those times like now when a Microsoft Update has caused a temporary problem with GIT Sync to BitBucket from Visual Studio
I do not have a Corporate server with IT to maintain a remote SVN server.
I work with multiple other developers who contribute to the GIT repository on BitBucket.
Because of the distributed nature of GIT we all can sync our local GIT repositories as changes are made.
I do not like having to use keyboard command strings to interact with GIT.
Fortunately for me BitBucket provides helpful prompts so I can get on with it.
#6
twelve12pm
Overseer
  • Total Posts : 325
  • Reward points : 0
  • Joined: 2012/04/09 17:27:24
  • Location: 0
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/13 11:03:30 (permalink)
0
JANickerson
I do not have a Corporate server with IT to maintain a remote SVN server.

 
I'd like to point out that multiple companies offer Subversion hosting with access from anywhere, etc. In our case, we like to keep our IP in-house so we set up our own server. Also, in our case, we work at the office, so access from anywhere in the world is not so important for us, but there's always the possibility to VPN into the office.
 
JANickerson
I do not like having to use keyboard command strings to interact with GIT.
Fortunately for me BitBucket provides helpful prompts so I can get on with it.



GIT's command line interface... needs improvement. Let's just leave it at that. :-)
#7
Bruce Lavoie
Super Member
  • Total Posts : 196
  • Reward points : 0
  • Joined: 2014/06/30 11:23:22
  • Location: Rhode Island
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/13 11:11:50 (permalink)
0
I'm currently using GIT with a small team and its been working well for us. 
#8
marcov
Super Member
  • Total Posts : 252
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: online
Re: Version Control for MPLAB C Code 2018/08/14 01:50:42 (permalink) ☄ Helpfulby twelve12pm 2018/08/14 08:07:22
+1 (1)
Subversion, using tortoisesvn as client. We experimented with GIT, but it was more complicated (as in more manual actions needed for simple stuff), with only the road-warrior scenario (committing to local repo without connection) as benefit, but that is not as important anymore in this 4G world.
#9
Bruce Lavoie
Super Member
  • Total Posts : 196
  • Reward points : 0
  • Joined: 2014/06/30 11:23:22
  • Location: Rhode Island
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/14 04:12:54 (permalink)
0
I agree with Marcov, when I used subversion with tortoisesvn it was easy to use.  With GIT, I found that l only really use a handful of commands but GIT offers much better merging.  I don't think svn offers rebasing? 
 
The GIT GUI client looks similar to tortoisesvn, but I never bothered to learn it.  I download and installed gitk which is a visual repository browser and I like that quite a bit.  At the end of the day once you invest a little time and learn something it becomes second nature after a while.
#10
marcov
Super Member
  • Total Posts : 252
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: online
Re: Version Control for MPLAB C Code 2018/08/14 04:47:31 (permalink)
0
No rebasing, though maybe that will come in the future. Over the SVN versions, the merge and changeset storage system has been changed, and more three-point scenarios exist. And of course you have less wildly diverging branches to begin with with SVN's centralist approach. While GIT merging is still better (and originally fundamentally so), there has been quite some catch-up over the years. SVN development is slow however.
 
I think I did a non-trivial manually rebase maybe twice in 12 years SVN.
 
btw, another bit where GIT doesn't live up to the hype is mergetracking. In a large project we had a setup like FreeBSD, a trunk (-CURRENT) for new development for the next major version, and a release branch (-STABLE) from which point releases are branched.  One needs a good overview what has been merged from CURRENT to STABLE, and all proposals were non workable (like only in order merging, doing manual administration, or committing _each_ commit in a separate branch, and then do a lot of double work to merge them to CURRENT and STABLE).
 
 
post edited by marcov - 2018/08/14 05:21:40
#11
moser
Super Member
  • Total Posts : 504
  • Reward points : 0
  • Joined: 2015/06/16 02:53:47
  • Location: Germany
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/14 05:55:18 (permalink)
+1 (1)
I'm working with only a few developers. A few years ago we wanted to introduce a version control system for our development with MPLAB X. We wanted one centralized server hosted by our company, and we were choosing between subversion and Git. 
 
We decided for Git, because we found it better to be able to have the full repository on each system. We are often out in the field, with no connection to our central server, and in those situations we wanted to be able to have a look at any older version. As Git always has any old version always available and even allows to continue development without connection to the central server, we decided for Git. Subversion is more in need to have a connection to the server, for those actions. And in industrial buildings you often have extremely bad mobile connections.
#12
marcov
Super Member
  • Total Posts : 252
  • Reward points : 0
  • Joined: 2006/10/08 01:59:40
  • Location: Eindhoven, NL.
  • Status: online
Re: Version Control for MPLAB C Code 2018/08/14 07:08:54 (permalink)
0
We usually prepare or stuff in the office or eating/catering areas, and only then march to the working floor to program.
 
Contrary to 10 years ago, getting a bit of wifi in the office block is usually fairly easy, and 4G is mostly backup for extreme cases. But I live in a country with high 4G penetration, ymmv.
#13
glenntrimble
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2018/06/18 14:26:12
  • Location: 0
  • Status: offline
Re: Version Control for MPLAB C Code 2018/08/14 07:37:06 (permalink)
0
I prefer Git (distributed) to SVN (central). All of the editors and IDEs I use are Git aware and integration is very good. Git enables "cheap" branches, which basically means you can create a branch locally for features or even just experiments. You can easily pull changes (all or selected ones) back into the main branch. You have flexibility to design your own workflow or adopt others. You can even use Git locally for your work even if your workplace uses SVN. This is what I do, so I get to take advantage of all of Git's capabilities and then I can use SVN to check into the corporate repo.
 
Git is worth looking into. You can compare with SVN or others, but I would encourage anyone to take a look at its features and workflows from a good video demonstration. There is even a talk that Linus Trovalds (Git's creator) gave at Google on youtube.
#14
Jump to:
© 2019 APG vNext Commercial Version 4.5