User Library Management

[PaulG.]

... I don't use passwords at all ... If a user wants to get in and muck around with the code... that's on them. I can't protect them from their own stupidity.

Here! Here!

Passwords. Arghhhh! I hate the damn things.

I have some code here written by a previous developer. Once in a while I'll stumble upon a vi that can only be opened with a password. And of course, I don't know the password. I have to delete the vi and recreate it the best I can.

Trust me. Judging by what I can read from this guy he wasn't that clever.

And I am the crazed psychopath who inherited his code. Fortunately for him I don't know where he lives.

[Cat]

Assuming you've done that correctly and you expect there to be more apps to follow, I would probably create a single parent directory containing directories for each of the individual applications that make up the system. I'd also add a Shared directory for code used by multiple apps. When you find something in one app you want to use in another app, extract it from that project directory and put it in your Shared directory. (Be careful not to break the links in your original app!) Then, once you've moved the code to the shared directory, remove it from your original app's project to indicate that app no longer "owns" that code.

This is pretty much the road I've started down. I've got a Shared directory, but haven't had the nerve to move much in there due to the linking issue. So that takes care of Big Project and all it's various tools applications. But it's still internal to the Big Project tree. I guess I have to be really gutsy and put it external to any project. While maintaining the links to about 3000 vis in 20 different apps...

Thanks! This has been really helpful.

[Daklu]

I've got a Shared directory, but haven't had the nerve to move much in there due to the linking issue.

You're not stuck still using 8.2 or 8.5 are you? (I know the military is slow to adopt new technology.) If so, I'll just say keep your troubles manageable and leave the code where it is. I've had much better success moving code with 8.6 and 2009.

[Cat]

You're not stuck still using 8.2 or 8.5 are you? (I know the military is slow to adopt new technology.) If so, I'll just say keep your troubles manageable and leave the code where it is. I've had much better success moving code with 8.6 and 2009.

I've got 8.6.1 (I'll probably get permission to upgrade to those 2009 disks sometime in 2011). I started the process of reorganizing yesterday, and so far it's been going okay. Of course I copied EVERYTHING off to an external drive first. Which was good, since I did end up having to pull a few files off of it when old versions snuck into the new directories. Today I'll take a deep breath and start moving stuff to the Shared directory.

And then I get to figure out what to do with my executables tree. But that will be for another thread. I've hijacked this one long enough.

[Daklu]

Another option occurred to me last night. Some scc repositories allow you to set up symbolic links to files in other repository files. If your scc system allows it that would definitely be a less risky option.

[Cat]

Another option occurred to me last night. Some scc repositories allow you to set up symbolic links to files in other repository files. If your scc system allows it that would definitely be a less risky option.

My apps are more interwined than I remembered, so just moving directories is taking longer than I expected. I haven't started moving common code to the Shared directory yet.

I do not have a "scc system". That's part of the problem, eh? It's just me writing code, so it really hasn't been an issue in the past.

[crelf]

I do not have a "scc system". That's part of the problem, eh? It's just me writing code, so it really hasn't been an issue in the past.

You just listed #1

http://thinkinging.com/2007/06/17/top-5-bad-excuses-for-not-using-source-code-control/

[Daklu]

My apps are more interwined than I remembered, so just moving directories is taking longer than I expected. I haven't started moving common code to the Shared directory yet.

I'm not a religious man, but I'll pray for you. May the gods of Labview have mercy on your soul.

(I hope you at least created a backup before attempting this?)

[Cat]

You just listed #1

I know! #4 has been my real excuse.

I guess I should wander around this subforum and see what might work well for a single developer...

[Cat]

I'm not a religious man, but I'll pray for you. May the gods of Labview have mercy on your soul.

Gee. Thanks... I'm sure I'll need it.

(I hope you at least created a backup before attempting this?)

Up one side and down the other. I'm very anal-retentive about backing up; it's the only way I've survived so far.

[PaulG.]

I do not have a "scc system".

Neither do I. My most recent attempt (out of a couple) was last year trying to get TortoiseSVN to work with just me as the developer. For some reason Subversion refuses to play nice with me and I gave up. I was the only developer and made backups every single day and archived the old ones so it didn't matter, right? Well I've been listening to the LV gods and have decided it still needs to get done. So yesterday I started playing with Mercurial. Today I installed TortoiseHG. Already I've had better luck with this setup than I ever had with SVN. And so just a few hours ago I ceremoniously uninstalled Subversion from my system (YES! )

Seems like a good time for me since I'm reorganizing and building more reuse libraries. We shall see how it goes. I'm optimistic.

[jgcode]

I have some code here written by a previous developer. Once in a while I'll stumble upon a vi that can only be opened with a password. And of course, I don't know the password. I have to delete the vi and recreate it the best I can.

Trust me. Judging by what I can read from this guy he wasn't that clever.

Well, if your company is using passwords internally then of course they need to be managed.

Too late now for you tho!

Even if you do not like them, there is still the use case of distributing code external to your company (i.e as a product) and the need to protect your IP that needs to be addressed.

Passwords seems like the only viable option (at this stage)

Nope, I don't use passwords at all. I do lock the libraries, but no passwords. Nothing I distribute to users contains confidential IP they are not allowed to see. If a user wants to get in and muck around with the code... that's on them. I can't protect them from their own stupidity.

If the time comes when I do need to use passwords, I would likely start with random passwords. If someone needs to see a block diagram I can always rebuild that module with a specific password for that user.

I had a play with just locking, but I found it wasn't that great for what I was after:

• It seems I can edit a VI if the library is locked without a warning (so a library member does not inherited that property from the library) - I have to lock the VI
• I cannot alter these settings at build time - meaning I have to manually lock everything then build, which is a pain during edit-time
• Adding passwords is easy because I can do this at the top level folder and it is inherited down the chain in the build spec

Do you have any experiences getting around this?

Cheers

-JG

[Daklu]

I had a play with just locking, but I found it wasn't that great for what I was after:

• I cannot alter these settings at build time - meaning I have to manually lock everything then build, which is a pain during edit-time

Do you have any experiences getting around this?

Yeah, all of them unsuccessful so far. I had thought locking was available via scripting. (My 2009 scripting plugin has been broken for a several months.) You're the scripting guru, isn't that property exposed?

(Probably ought to be on the idea exchange, eh?)

[Ton Plomp]

...So yesterday I started playing with Mercurial. Today I installed TortoiseHG. Already I've had better luck with this setup than I ever had with SVN. And so just a few hours ago I ceremoniously uninstalled Subversion from my system (YES! )

One of the nice things of a Distributed Version Control System (DVCS) like Git or HG/Mercurial is that you can easily commit your code on a daily basis.

When working in a multi-developer team it can be quite scary to commit code, since it will end up with everyone. But by using a DVCS you can commit your code locally, and start developing a new feature and polishing the old code without sending it out while you can still go back to an intermediate version.

Paul, please share your insights on the LabVIEW wiki page on Mercurial

Ton

[jgcode]

Yeah, all of them unsuccessful so far.

Damn. I am running into cases where passwords will be a pain, but I really like that I set it all from the build spec.

I am thinking that maybe using a universal password for each library/vi in the release.

That way I get the nice effect of "warning! - this is a reuse library enter a password"

They then will be able to enter it - but then it is on their head.

You're the scripting guru, isn't that property exposed?

Ah, negative! I only have my ninja yellow belt

(Probably ought to be on the idea exchange, eh?)

I reckon