05-28-2015 12:40 PM
I want to be able to develop on two different PC's the same Labview project. The machine that actually runs the program doesn't have a network connection. Is there an easy way to transfer projects back and forth? If I choose File>Save As... and try duplicating the project, it gets messy and doesn't really work anyway because the location of your dependencies starts changing and you'd have to manually copy folders. If version control software is the only real way then what's the most painless one to use with Labview? Thanks.
05-28-2015 02:04 PM
@Flohpange wrote:
If version control software is the only real way then what's the most painless one to use with Labview? Thanks.
It probably depends on what you are most comfortable with. SVN, and Perforce are two that generally work well with LabVIEW because they can support the Lock, Commit paradigm instead of the merge which most SCC focuses on. This technique is less successful with LabVIEW because of the binary file format of the code. But how is this a solution if you don't have a network connection?
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
05-28-2015 02:37 PM
Develop on a USB flash drive. If you are using version control, remember to commit your changes when you get to a computer with access to the repository.
I find SVN with the Tortiose shell to be the best.
05-28-2015 04:33 PM
I used to use a USB key to develop at work (a University) and also at home. Remembering which version was which (and which was "the latest") was something of a nightmare.
For that past few years, i've taken advance of the University's Subversion Server, with my PCs running the (free) Tortoise Subversion Client. I still need to remember to connect to the Repository (via the Web) and Update when starting an editing session, and to Commit when I finish, but this has saved my rear end numerous times. Plus if I make a mistake, I can use Subversion to "go back to the previous working version and try that again".
Bob Schor
05-28-2015 07:32 PM
Any SVN solution ignores the user's comp isn't on a network. Developing on the USB is honestly his best solution. I'm not sure why this would make anything difficult about remembering versions. It's the same as having things on your HD
05-28-2015 07:40 PM
@natasftw wrote:
Any SVN solution ignores the user's comp isn't on a network. Developing on the USB is honestly his best solution. I'm not sure why this would make anything difficult about remembering versions. It's the same as having things on your HD
I find that using SVN with a USB drive works fine. Set it up just like any other working copy. Just make sure that you commit before you go to the workstation without the connection (and probably without SVN also) and commit again when you get back.
05-28-2015 09:26 PM
That's a solution to a different problem. Yes, it'll provide source control on the networked computer. But, it has absolutely nothing to do with finding a way to get the project between the two computers. Let's try an analogy. It's a good idea not to program in a sauna. Just like avoiding this bad practice, we should use source control to avoid another bad practice. But, the two aren't related to how we'll get the project to another computer after we avoid these bad practices.
05-28-2015 10:26 PM
I think I agree with Natasftw, particularly if you do all of your development work from the Flash Drive. I may be restating an earlier opinion (I apologize in advance if so), but if one of your Development machines is networked, you can "have your cake and eat it, too" by making the Flash Drive be the SVN "Working Copy". Let's say you have the Latest Version on the Flash Drive, but nothing (yet) in Version Control.
The code stays on the Flash Drive during development. Modifications are only made to Flash Drive (Working Copy). When plugged into Networked PC, commits are done first, then code, then commit, then unplug. If anything happens to Flash Drive (like you lose it), simply plug a new drive into Networked Computer and do a Checkout.
Now that I think about this, I've actually done something like this once or twice, but was always very nervous doing development on a machine without access to SVN ...
Bob Schor
05-29-2015 12:01 AM
I don't get it? Isn't that what I was saying all along?
05-29-2015 12:04 AM
@Bob_Schor wrote:
I think I agree with Natasftw, particularly if you do all of your development work from the Flash Drive. I may be restating an earlier opinion (I apologize in advance if so), but if one of your Development machines is networked, you can "have your cake and eat it, too" by making the Flash Drive be the SVN "Working Copy". Let's say you have the Latest Version on the Flash Drive, but nothing (yet) in Version Control.
- Plug in to Networked Computer. Build Repository to hold Working Copy (on Flash Drive). Get Working Copy installed in SVN Repository.
- Disconnect Flash Drive from Networked Computer. Current State -- Working Copy has been committed to SVN.
- Plug Flash Drive into Isolated Computer. Make modifications to Working Copy. Unplug.
- Plug Flash Drive into Networked Computer. Before making modifications, Commit (adding notes about changes made on Isolated Computer).
- Modify Working Copy (Flash Drive) on Networked Computer. Commit, with notes about Networked Computer modifications. Unplug Flash Drive.
The code stays on the Flash Drive during development. Modifications are only made to Flash Drive (Working Copy). When plugged into Networked PC, commits are done first, then code, then commit, then unplug. If anything happens to Flash Drive (like you lose it), simply plug a new drive into Networked Computer and do a Checkout.
Now that I think about this, I've actually done something like this once or twice, but was always very nervous doing development on a machine without access to SVN ...
Bob Schor
Oh yeah. You get so used to being able to back up your stuff when you want that it's scary when you can't.