SVN for use with LabVIEW

[LV_Pro]

Hi all,

    We are in the preliminary stages of implementing a software source control here where I am working, to the best of my knowledge Apache SVN. Can y'all direct me to some sites showing pitfalls, hints and kinks, etc., particularly with using it with LabVIEW. Any experiences you have had would also be very helpful.

Thanks, and a Happy New Year!

[Mark_Yedinak]

i have been using it for years and it has worked fine for us. I work with a team of developers and we often work on the same application. Merging with LabVIEW is a pain in the butt and you will want to avoid doing this. We generally try to assign specific modules to a developer to work on so we don't have people working in the same code at the same time. Storage space increase when checking in LabVIEW code because you need to copy all of the code since it is binary and SVN cannot simply store deltas as it can with text based languages. One thing you absolutely MUST do is mark all of your code to separate the compiled code from the source code. If you don't do this you end up with too many files getting commited that weren't truly modified. A simple typedef change can force lots of files to be committed even though they were't actually modified.

Recently we started moving most of our reuse libraries to packed project libraries. When we did this we created a separate repository for the development and maintenance of the PPLs. The application code is kept in a separate repository and we place the actual PPls in a well known directory. The PPL repository builds the PPLs to the well known folder and the application code references the well known folder for the built PPLs.

We also try to maintain the same folder hierarchy the same across the developers workstations. Otherwise LabVIEW wants to browse to the new location for the code. Specific folder names is not crucial for the top level folders but the depth is since LabVIEW uses relative paths to get to the code. Everything in the repository will be named the same but where the developers check the code out shuld be basically the same. What we do is check all of our code out to a folder named "Test Automation". Then all of the path stuff works. If one developer checks it out to "Test Automation" and another checks it out to "Test Automation/My Code" you will end up with code churn when you commit because paths to code are not going to be the same.

[LV_Pro]

Thanks Mark, this will give me a starting place for writing a usage document. Now getting everyone on board ...

[bharathp10]

 LV CHAMPION forgot to kudo.

[Hooovahh]

Yes avoid merge.  SVN can be setup to be merge (where everyone just commits over each other) or a lock paradigm where no one is allowed to edit code unless you requested the lock.  There can only be one lock at a time, and not having a lock sets the files to read-only.  I'm a compulsive saver so I might open some code start editing, and then attempt a save only to see I don't have the lock.  From that window I can try to lock my file at which point I either can, or it tells me someone else has it locked.  This only works if you can talk to the server.  Other SCC systems don't rely on this but I like having a gate keeper (assuming network or VPN access).  You can of course break locks too, or temporarily set a VI to not read only just to test a quick change but you won't be able to commit it back without the lock.  With code modules, and libraries segregating the application, this doesn't usually become an issue.  Except for those that like to just lock the whole project and all files at which point everyone starts yelling at them for locking their code.

Oh and I just use the TortoiseSVN client.  ViewPoint and JKI have a couple add ons but the explorer shell is all I really need.

[Ben]

---

@Hooovahh wrote:

....  With code modules, and libraries segregating the application, this doesn't usually become an issue.  ...

---

Let me emphasize using Libraries and adding "use multiple projects'".

Use a small project for the top-level VIs and the direct support functions for the top level. Do NOT include the libraries that make up the bottom of your application. Let them show-up in dependencies. Use "sub-Projects" for the support functions. If you divvy the application up right and have all of the code in libraries, and sub-Projects, developers can develop the code using the sub-Projects and add remove from the libraries without conflicting with the top-level project.

Using that approach developers are free to save anything in the sub-Project they are working on without concern of having to fight over who gets to update the top-level Project.

Not to clarify...

"Sub-Project" - I use this term to designate a project that contains only a limited number of libraries associated with a part of the application. An example could be "DAQ.Proj". Any and all DAQ related stuff is in the Project.

The top level VIs can still aces the VIs in the sub-Projects but they only show up in dependencies.

When we meet to discuss changes and who will do what, we break up the work based on which of the projects will be involved in the code changes. Code changes involving "DAQ.proj" are all handled by one developer (for example) and they can commit any time they want (provided they do not commit broken code!).

When the rest of the team is ready for an update they update the source code from the DAQ folder, check for errors due to API changes and keep moving.

Of course the above approach assumes that you are not using auto-populating folders. They have to be shut-off to avoid the issue of cross-linking.

Works great for us and we seldom run-into conflict between multiple developers.

Ben

[crossrulz]

---

@Ben wrote:

---

Let me emphasize using Libraries and adding "use multiple projects'".

---

I have been doing something similar on my current project.  The only real difference is I am building these "subprojects" into Packed Project Libraries (PPLs).  So then any dependencies are on the PPL, not the actual libraries.  Makes it a little more convenient to do updates for the top level, especially at the released state (you can just update the PPLs instead of rebuilding the entire application).  Granted, it will mean more files at the release state.  But I would rather have my Hardware Abstraction Layer (HAL) be a plugin architecture anyways (recently ran into issues containing the HAL in the application).

I am not a fan of having loose dependencies, so you can consider this the compromise to Ben's suggestion.

[Mark_Yedinak]

We are heavily using packed project libraries in our code base. Our system is used to test printer firmware and includes our own test executive. All of the step types are plugins using PPLs. We load these unto the PC running the test dynamically from our database so it it easy to deploy new step types as well as deploy updated versions of them. In addition to the step types virtually all of our re-use libraries are also PPLs. We have a rather detailed application framework with many of its components implemented using PPLs. Our printer classes and communication interfaces all use PPLs too. Our current count is over 120 PPLs. We have a single repository for developing and working on the PPLs themselves and then mainline applications simply reference the PPLs. Using this approach we find it easy to segment our development efforts to avoid two developers working on the same area of code at the same time.

In addition, we do not rely on auto dependencies but rather strictly include the re-use libraries as the PPLs in the top level application projects.

[Ben]

---

@crossrulz wrote:

---

...

I am not a fan of having loose dependencies, so you can consider this the compromise to Ben's suggestion.

---

"

...

I'll linger here beneath the Sun, because my land is best!

...

"

Fair enough!

Ben

[Gregory]

This article has lots of info (not just on SVN) to get you up and running:

http://delacor.com/every-developer-needs-a-time-machine/

The second video shows you how to get SVN configured with some helpful LabVIEW specific bits.