Jump to content

Source code control...


Recommended Posts

Hi All,

We're a small company doing a mixture of things, and we use labview to write control software for various automated systems that we supply to our customers. I'm actually relatively new to the company (but have labview experience from my PhD), but I know that source code control has often been mentioned, but never implemented (and, from the stories of my colleagues, it probably should have been!). One of the reasons for this is that, prior to my joining, there has only been one "major" labview application and it was maintained by only two staff members. Now I've joined the team there are 3 of us able to use labview, and we're about to embark on a complete overhaul of that one major application (a complete bottom up re-write of the architecture and a major cleanup of most of the processing algorithms and things that went with it). So, again the topic of source code control has come up. None of us has used it before (at least with labview) although we're familiar with the basic concept, and we don't know where to start - particularly in terms of what software we need. Bearing in mind we're a small team (and from within a small company), we don't want to be spending thousands on licensing of some super dooper massively complex system. What we need is something that prevents "code collisions", probably through checking in and out of code etc and maintains a decent backup of the projects code repository and revision history etc.

Can anyone point me in the direction of where to start? Or recommend a suitable piece of software and how to go about starting it up? If we're going to implement source control, ideally I want it in there from the get go on this project, but we do have a pretty tight timeline so I can't spend months learning a whole new thing just to get this implemented...

Anyway, as I say, if anyone can point me in a useful direction to get us going I'd really appreciate it!

Thanks in advance for any help!

Paul

Link to comment

Hi

As I am on line I will pop up a quick reply to this question, if you want a good free source control system that is used by a large number of people (respected developers) who hang around the Lava forums you need to look no further than subversion people often refer to it as SVN there are a lot of question and answers in the Lava "Source Control" forum there is also an entry in the LAva Wikki

Again do a goggle search subversion and LabVIEW and you will come up with a lot of links.

I myself use ClearCase as a source control tool but this is very expensive and needs a lot of setting up. It is an extremely good tool, but a lot of the great extra's you get this it can only really add benefit when working with text rather than binary files.

you might also want to look at a Problem reporting / tracking type system like Bugzilla to help keep and eye on what is happening with Bugs

Dannyt

Link to comment

Thanks for the reply, I have just noticed that there's a whole forum section on this!! So have started to have a trawl through there - am downloading SVN/tortoise SVN as I type to try to set it up on the server whilst no one's here (so as to minimise disruption!)

Paul

Link to comment

QUOTE (Ic3Knight @ Jun 2 2009, 06:09 PM)

Thanks for the reply, I have just noticed that there's a whole forum section on this!! So have started to have a trawl through there - am downloading SVN/tortoise SVN as I type to try to set it up on the server whilst no one's here (so as to minimise disruption!)

Paul

Just to stick my nose it....

I recently installed Perforce and if you stay within the "demo" requirements : five workspaces and I think 3 users, then it's free.

It has LabVIEW project integration (You can configure SCC on a per-project basis) and it's pretty fast.

I like it a lot, I'll be sticking with it.

Shane.

Link to comment

QUOTE (shoneill @ Jun 2 2009, 08:31 PM)

Just to stick my nose it....

I recently installed Perforce and if you stay within the "demo" requirements : five workspaces and I think 3 users, then it's free.

It has LabVIEW project integration (You can configure SCC on a per-project basis) and it's pretty fast.

I like it a lot, I'll be sticking with it.

Shane.

Unfortunately, I think the perforce "trial/demo" is 2 users only, and we'd be 3... meaning an instant cost of abour £1500, not huge, but not easily justifiable either...

Anyone point me in the direction of an easy step by step SVN setup? with the repository on a windows server machine?

Cheers!

Paul

Link to comment

QUOTE (Ic3Knight @ Jun 2 2009, 01:41 PM)

Unfortunately, I think the perforce "trial/demo" is 2 users only, and we'd be 3... meaning an instant cost of abour £1500, not huge, but not easily justifiable either...

Anyone point me in the direction of an easy step by step SVN setup? with the repository on a windows server machine?

Cheers!

Paul

Just to see what Subversion's all about, you can set up a simple repository using the "file:\\" access mode rather than a server. While this is not considered best practice except for personal repositories, it's incredibly easy. Just install the TortoisSVN package and open the help file, search on create. It will tell you how to create a repository and then access it using simple file access rather than access thru a server. Later, if you like what you see, you can install a server and access the repository you already created. BTW, I use this with two and three person teams (we seldom if ever work on the same code at the same time) and it has not caused problems yet, although we are in the process of finally getting IT to set up a real SVN server and doing it the right way.

Mark

Link to comment

QUOTE (ASTDan @ Jun 3 2009, 07:13 PM)

Ok,

So I played around a bit, set up a repository on our server which I can happily access via svn:\\. Now I have a problem though! I just moved an existing project into the repository by "importing" the top level folder into the repo and then checked out a working copy back onto my PC. Now, for some reason, every single file within my project has been set to "read only"... None of the files have any subversion properties set, I tried "getting a lock" on the file, but that didn't help either... I can manually (through explorer) set a file to read/write to save changes, but when I commit that file back into the repo and then update my working copy, it reverts to read only!

What am I missing?!

Any help greatly appreciated!

Paul

Link to comment

QUOTE (Ic3Knight @ Jun 4 2009, 08:30 AM)

Now, for some reason, every single file within my project has been set to "read only"... None of the files have any subversion properties set, I tried "getting a lock" on the file, but that didn't help either... I can manually (through explorer) set a file to read/write to save changes, but when I commit that file back into the repo and then update my working copy, it reverts to read only!

The files are read only because you don't have the lock on the file. If you get the lock (which it sounds like didn't work) then the files become not read only, allowing you to edit the files. Then you perform a commit which can unlock the file (if the check box for keep locks is off) this will commit changes and allow anyone else on the team to get the lock and edit the file.

If someone has the lock (and their local copy is not read only) then you won't be able to get the lock, and your local copy will be read only preventing you from making changes, until the other member on your team is done editing their copy. You will then be forced to update before getting the lock. Then you can continue to edit the file, picking up from where your other member left off.

Only under rare circumstances should you ever change the file from read only manually with explorer. If you do this and edit the file, then you won't have the lock but will have a different version of the file than what is on the server, which is why performing an update reverted back to the original. You can only perform a commit if you have the lock on some thing.

Link to comment

QUOTE (hooovahh @ Jun 4 2009, 02:32 PM)

The files are read only because you don't have the lock on the file. If you get the lock (which it sounds like didn't work) then the files become not read only, allowing you to edit the files. Then you perform a commit which can unlock the file (if the check box for keep locks is off) this will commit changes and allow anyone else on the team to get the lock and edit the file.

If someone has the lock (and their local copy is not read only) then you won't be able to get the lock, and your local copy will be read only preventing you from making changes, until the other member on your team is done editing their copy. You will then be forced to update before getting the lock. Then you can continue to edit the file, picking up from where your other member left off.

Only under rare circumstances should you ever change the file from read only manually with explorer. If you do this and edit the file, then you won't have the lock but will have a different version of the file than what is on the server, which is why performing an update reverted back to the original. You can only perform a commit if you have the lock on some thing.

I was under the impression that, by default, SVN does not use a "locking" model, but rather a "copy-modify-merge" method... in which case I should be able to modify anything in my working copy without issue and then (subject to their not being any conflicts) simply commit my changes. At present, its not that I can't commit things, but I can't physically save them.

If I open a VI from my working copy and then modify it, and then try to save it, I can't - it says the file already exists and that I don't have permission to over-write it. What I expected it to do was let me save it and then show me in the overlay that it was modified...

I don't understand why the files are being set to read only when there is no "need-lock" property set on them, and even obtaining a lock doesn't appear to do anything...

Any other thoughts?

EDIT -- Ok, so I just deleted the working copy, and re-checked it out, everything now works as I expected it too...

Cheers

Paul

Link to comment

LabVIEW does not work with a "copy-modify-merge" method. That method is for text based code. Binary files such as a LabVIEW vi are source controlled by lock/unlock, single person changing code at one time method.

How this differs is that in C+ for example, multiple functions would be in one file. Perhaps your entire program would be one giant text file. In LabVIEW by contrast, you have many little files that separate each function called a 'subvi'. With the one text file situation it is very reasonable to have multiple coders working on different parts of the code, different functions, etc within one big file. Therefore you implement a merging method. LabVIEW on the other hand, one function is typically one file, thus locking that one file for changes does not interfere with the work of the other coders. They are working on the other functions they locked. Then as each person gets the updates LabVIEW uses the new changes subvis. This is very similar to the SCC merging the changes to two text files and each coder recompiling.

Link to comment
Link to comment

QUOTE (mesmith @ Jun 4 2009, 10:56 AM)

Agreed. We have been using SVN without locking on a large LabVIEW system for 5 years. The main thing is to think twice before committing a lot of recompiled VIs (like when you change a typedef). That makes it more likely to have a collision with another coworker's changes.

Link to comment

QUOTE (jdunham @ Jun 4 2009, 02:28 PM)

We have been using SVN without locking on a large LabVIEW system for 5 years.

I'm not sure if the size of the system has anything to do with the selection between the models, more the size and structure of the team. There are puh-lenty of arguements for both methods - we (VIE) chose to implement the lock-unlock method as it allows us an extra layer of checking.

Link to comment

QUOTE (crelf @ Jun 4 2009, 01:19 PM)

I'm not sure if the size of the system has anything to do with the selection between the models, more the size and structure of the team. There are puh-lenty of arguements for both methods - we (VIE) chose to implement the lock-unlock method as it allows us an extra layer of checking.

Oh yeah, and we may even migrate to locking someday. The point was "don't let anyone tell you that the merge model can't be used with LabVIEW", even if they work for a very well-respected LabVIEW integrator.

Hopefully the OP has figured out that the choice of locking or merging is the major one to make when rolling out a SCC system. But as long as they don't use VSS, they will probably be OK.

Link to comment

Hi All,

Thanks for the comments. The Jury's still out for me on the "lock-or-not" argument. I'm going to have a sit down with the other two guys who will potentially be working on the code on monday and we'll make a decision then. For the moment, I'm still just playing with SVN. I've got a project that only I will be working on as well, so I've set that up in SVN, currently for merge rather than lock, so I'll see how I get on with that too...

While I'm here - I did try to use the pushok plugin to integrate into labview, but I ran into a problem, perhaps someone here can shed some light:

So, I set up a labview project with a folder hierarchy and a few subvis for testing etc. I put that on my SVN repository. I then configured SCC within labview to use the pushok plugin and told it where the repository was and where to put the working copy etc. I then check out a working copy, open up the project and go to edit one of the VIs, it asks me to lock the file, so I do, no problems so far...

Next up, I go to another PC on the network and set it up as above with the pushok/tsvn "stuff" and set up labview in the same way. I check out a full working copy, open up the project and then try to edit the same VI I have "locked" on the first PC. I get a dialogue asking me to get a lock, I click ok, then it tells me the file is already locked (good!) but then I get a couple of errors -

post-14639-1244188380.png?width=400

When I click continue, the same error pops back up, and then the VI I'm trying to edit can be freely edited.... and saved... but then obviously I can't commit the changes from this PC since SVN sees it as locked by the first PC, which is good... but what are these errors about!? Anyone come across anything similar?

Cheers again!

Paul

Link to comment

Hi All,

Thanks for all the feedback. Just wanted to say we decided today to run a needs:lock based SVN, and we're going to use the JKI tool for integration into labview... If I remember, I'll post back here with any thoughts on how it works in the not too distant. For the mo, it seems to do exactly what it says on the tin - it integrates the tortoise svn commands into a menu within labview... which is just what we wanted!

Thanks again!

Paul

Link to comment

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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