SCC software

[Tom Bress]

QUOTE (jgcode @ Aug 13 2008, 07:29 PM)

Hence the reason I am looking to go to Perforce and run it off my server and use check in/check out. I just makes sense to me. Having been stung by the above two points (hey its all a learning curve for me) .

Even though I am a lone developer I have put my code repository on a server. That way, no matter what computer I'm on, I can get a working copy of my repository, make changes, and commit them back to the server. I do this using edit/merge instead of check in/check out. I just make sure that I commit my changes often, which is good SCC practice anyway.

[gmart]

QUOTE (jdunham @ Aug 13 2008, 04:50 PM)

So If I don't want to check out the callers, because I don't want to recompile just yet, can I get any work done, or will I constantly be asked to save changes every time one of the callers leaves memory?

You will be asked to save the caller when the caller is in memory. You won't need to save it since LabVIEW will automatically apply the change the next time you load. You will want your final released version saved since automatic recompiling will cause performance to be impacted. This behavior is not specific to using SCC.

[jdunham]

QUOTE (gmart @ Aug 13 2008, 05:34 PM)

You will be asked to save the caller when the caller is in memory. You won't need to save it since LabVIEW will automatically apply the change the next time you load. You will want your final released version saved since automatic recompiling will cause performance to be impacted. This behavior is not specific to using SCC.

Yes! So the problem is if I have a typedef, and it's used in 70 calling VIs, I'm going to open and inspect all of the callers to see whether changes are needed. Let's say I need to change four of the callers. When I close the other 66 VIs, I have to be very careful and decline to save the changes. If I go ahead and save the callers, then when I check my code back into SVN, it's very hard to remember which four of the VIs had real human-initiated changes.

If I just check all 70 VIs into source control, and then my co-worker tries to check in the 3 he changed, they will have conflicts. He'll ask me where my changes are, and I'll rack my brain to remember which ones matter. That just doesn't work. We can use LVdiff, but you can waste 5-15 minutes per VI on that, and it's easy to make a mistake.

So instead, we make sure to check in all the recompiles with a separate check-in. The commit log has special text, and we have a tool that can tell us whether a given VI has real changes or just recompiles. We have written special merge tools to figure out whether there are real conflicts, because SVN thinks that many of the VIs are conflicted.

Since merging is a pain, we only do it once a week or so, and without this system and this tool we would have to manually resolve hundreds of conflicts, many of which are just an artifact of LabVIEW's VI storage system.

Even with our special tricks, I still have the problem that if I actually try to use the code (maybe I want to be radical and test my changes), those unsaved VIs will keep popping up save dialog boxes every time a panel is closed. That's so frustrating that pretty soon I will have to bite the bullet and save all the VIs. I try pretty hard to save my work as I do it, so at this point *hopefully* I can check in my true changes. After checking them in, I will recompile everything and check that in with the separate checkin. Then I can get my testing done, crossing my fingers that I don't have to back out the changes.

The alternative which I use sometimes is to change the typedef and check that in, then save all, and check in everything, and then find the callers which need changing and save those. This has the same problem that if the implementation is not so great and needs a lot of changes, and backing out of old versions, then I have a big conflict resolution mess on my hands when I go to merge with my co-workers.

So some of our tools make this easier, but pretty often (like now) I feel that the time spent with these hassles nearly offsets the amazing productivity gains we get by using LabVIEW in the first place. When you throw in all the tools we had to write to make real automated builds with good svn-integrated versioning, I wonder if we should have ported to a different language long ago.

OK, ranting aside, my purpose in writing this was to see if other people are having the same problem and if there are any innovative solutions we could share, and secondly to see if anyone at NI (gmart, I guess that's you, thanks for listening!) has the faintest glimmer that this is a problem that could benefit from better internal tools. It's not so much the SVN source code integration (well that would be great), but a way of telling whether a VI has real changes versus typedef-induced recompiles, and support for turning off the automated saving in this very-frequently-occuring situation.

<Zippy> Are we off-topic yet? </Zippy>

[Francois Normandin]

QUOTE (jdunham @ Aug 14 2008, 12:45 AM)

<Zippy> Are we off-topic yet? </Zippy>

If you ask the original poster for his opinion... this discussion opens up many questions I'll need to address when starting my SCC. I'm happy the topic shifts a little.

[James N]

Our department uses Subversion and TortoiseSVN with about 10 developers. Love it! I would use it if I were alone on a deserted island (aside from the inherent technical challenges on a deserted island).

Another Side Topic (if I may):

How do people handle LabVIEW versions in their SCC? I don't think this has been discussed here.. I didn't read every post completely.

I'm primarily talking about the migrating a Reuse Library to newer versions of LabVIEW while minimizing the affect to older LabVIEW code which must be maintained and/or is still being developed.

I don't really think I want multiple directories in my repository, such as "LabVIEW8.2", "LabVIEW8.5", etc., branching the library with each new LabVIEW version. I know there's no reason to mass compile a library just for the sake of mass compiling it, but as new VIs are added or older VIs are modified and saved in newer versions of LabVIEW.. this will affect down-level users.

Thoughts..

-James

[crelf]

QUOTE (James N @ Aug 14 2008, 10:56 AM)

Our department uses Subversion and TortoiseSVN... I would use it if I were alone on a deserted island (aside from the inherent technical challenges on a deserted island).

Ditto!

QUOTE (James N @ Aug 14 2008, 10:56 AM)

How do people handle LabVIEW versions in their SCC? I'm primarily talking about the migrating a Reuse Library to newer versions of LabVIEW while minimizing the affect to older LabVIEW code which must be maintained and/or is still being developed.

That's an easy one - use VIPM.

[Jim Kring]

QUOTE (James N @ Aug 14 2008, 07:56 AM)

I don't really think I want multiple directories in my repository, such as "LabVIEW8.2", "LabVIEW8.5", etc., branching the library with each new LabVIEW version. I know there's no reason to mass compile a library just for the sake of mass compiling it, but as new VIs are added or older VIs are modified and saved in newer versions of LabVIEW.. this will affect down-level users.

QUOTE (crelf @ Aug 14 2008, 09:12 AM)

That's an easy one -

use VIPM

.

Thanks for the plug on this, crelf! By the way, we have a page that describes how to use VIPM in conjunction with source code control, here:

• Using VI Package Builder with Source Code Control
  

[crelf]

QUOTE (Jim Kring @ Aug 14 2008, 12:19 PM)

QUOTE (crelf @ Aug 14 2008, 12:12 PM)

That's an easy one -

use VIPM

.

Thanks for the plug on this, crelf!

No thanks needed - it's a great product and I wouldn't plug it if I didn't beleive that.

[jdunham]

I also want to mention that Subversion's awesomeness also includes efficient binary deltas for file changes. What that means is that if you're someplace with a slow internet connection, and your co-worker fixes a harsh bug in your biggest disk-hogging GUI VI, then many times your SVN update will still be really fast, because SVN will only need to send the newest part of the file to you. I don't know how perforce does this, but some other systems either have to send the whole file, or can only do this with text files.

Also, SVN works pretty well off-line. If you are on a plane, you can still revert to the last server version without an internet connection.

[Yair]

QUOTE (jdunham @ Aug 14 2008, 07:45 AM)

but a way of telling whether a VI has real changes versus typedef-induced recompiles, and support for turning off the automated saving in this very-frequently-occuring situation.

Have you tried Options>>Environment>>Do not save automatic changes?

[jdunham]

QUOTE (Yair @ Aug 14 2008, 10:53 AM)

Have you tried Options>>Environment>>Do not save automatic changes?

No, but I sure will give it a try. That's why I posted to the forum. Have you been using this successfully with an SVN workflow?

[Yair]

QUOTE (jdunham @ Aug 14 2008, 09:07 PM)

Have you been using this successfully with an SVN workflow?

No. Our usual workflow has a single developer working on any module at any one point in time and we have users with different levels of experience with both LabVIEW and SVN. As a result I prefer having the developers save and commit all the VIs when changing a typedef so that we know that we have a single version and that when you open it nothing should recompile. Also, our software is often deployed on a single computer, so we don't really have versioning issues.

For the same reason (and simplicity) I also prefer commiting executables. Just the other day a client wanted me to revert an application to an older version to demonstrate that there wasn't a problem with the recent code changes. Instead of having to dig up a CD or check out all the relevant code, I just reverted the executable to the relevant version, something that took about 10 seconds. That's where SVN's efficient binary diff which was mentioned earlier comes into play.

The reason I do this is that hard drive space and network bandwidth are cheaper than headaches. That said, this works for our specific situation. It's definitely not for everyone and it might not even work for us in the future.

By the way, for those still not convinced about using SCC, here are two good reasons:

1. Easy backup.

2. Easy synchronization. If you have more than one developer, you must have some sort of synchronization. At least in TortoiseSVN, this is very easy - two mouse clicks in Windows Explorer and your entire hierarchy is synchronized.

[James N]

QUOTE (crelf @ Aug 14 2008, 11:28 AM)

Thanks for the plug on this, crelf!

No thanks needed - it's a great product and I wouldn't plug it if I didn't beleive that.

I guess these's something to this thing call VIPM... hmmm. I suppose we'll have to break down and take a look at it sometime.

Yeah, I kinda figured VIPM would be one of the responses to my question. As it should be.

Anybody else not in cahoots with JKI?

-James

[crelf]

QUOTE (James N @ Aug 14 2008, 04:31 PM)

Anybody else not in cahoots with JKI?

Not that I'm sure that this is what you're insinuating, but for the record: neither I nor my employer is in cahoots with JKI. We certainly do have an interest that VIPM is top-notch, but that's because we depend on it to help us achieve LabVIEW development environment configuration management.

[James N]

QUOTE (crelf @ Aug 14 2008, 03:56 PM)

Not that I'm sure that this is what you're insinuating, but for the record: neither I nor my employer is in cahoots with JKI. We certainly do have an interest that VIPM is top-notch, but that's because we depend on it to help us achieve LabVIEW development environment configuration management.

I was just ribbing you. I'm would never mean to suggest any unethical business practices are occuring. Please don't take it that way.

I agree, if someone produces a great product or does a great job, by all means, praise that effort publicly.

I was just looking for ideas from those who haven't mastered the chainsaw, but are still plugging away with axes.

-James

[Justin Goeres]

I'm dropping in a bit late to this discussion, and most of what I would've said has already been covered. There's just one thing I feel like adding, though.

The original thrust of the discussion was source code control vis-a-vis LabVIEW source files, but something to bear in mind when choosing/deploying a versioning system is that projects typically consist of lots of different types of files, and nearly all of those files can benefit from version control. That's why it has never really bothered me that SVN/TSVN doesn't integrate with the LabVIEW project environment. I see it as a tool for managing all my project-related documents, not just source code. If virtually every file I use for project work can benefit from versioning, then I should have an ex-LabVIEW versioning workflow in my head anyway. I don't feel like I need the process duplicated in the development environment.

In fact, a friend of mine in a totally unrelated field actually used Subversion & TSVN to manage all the revisions of his Master's Thesis and related support documents. The only thing he knows about source files is that they end in things like .c, .h, .vi, etc. and that he never wants a job where he has to touch them .

Other Notes: Even back when I was operating independently, TSVN performed beautifully for me even as a single developer (with an occasional assistant or collaborator). Even the threat of merge conflicts just forces clear communication between developers, which is a very good thing. What's more, Subversion/TSVN are pretty light-weight, so it was always a snap to install them on a customer's computer to do a project checkout on-site when necessary.

[crelf]

QUOTE (James N @ Aug 15 2008, 09:41 AM)

I was just ribbing you. I'm would never mean to suggest any unethical business practices are occuring. Please don't take it that way.

Not at all I know that you were slightly taking the piss, but I needed to add that little disclaimer to clarify to anyone esle reading the thread.

[NeverDown]

I wish there were an integration with LabView and Accurev. That source control tool makes Perforce and SVN look like my grandfather's source control.

[crelf]

QUOTE (NeverDown @ Aug 15 2008, 04:51 PM)

That source control tool makes Perforce and SVN look like my grandfather's source control.

I don't know about your grandfather's SCC, but my grandfather's SCC is freakin' awesome!

PS: just posting about how one thing is better than another provides very little value to the community if you don't tell us why. We're all here to learn from each other, so please share what you know. Perhaps a feature comparison? Maybe a list of a few features that Accurev has that SVN doesn't?

[nhollenback]

QUOTE (normandinf @ Aug 12 2008, 09:30 AM)

Well, if NI uses Perforce and it's free for 1 or 2 users, than I might as well start fresh with it. Should our team grows to more than 1 developer , it doesn't seem to be prohibitively costly to buy licenses...

thanks for the tips.

I've have exposure to Perforce and currently use Subversion/Tortoise. The latter route is much, much, more intuitive. Additionally (as you see here and will find on www.thinkinging.com and www.expressionflow.com) plenty of resources exist in the LabVIEW community. If I were at a company that provided the support for Perforce and managed it, then I'm sure I would embrace the tool. My friends at NI who use Perforce, like it. However, I don't have those resources.

If you go the Subversion/Tortoise route you can be up and running in a few hours. Though I recommend taking a few days to learn the tools thoroughly.

Subsequently, the real cost of the tool is not just the purchase price.

[LAVA 1.0 Content]

QUOTE (NeverDown @ Aug 15 2008, 10:51 PM)

I wish there were an integration with LabView and Accurev.

QUOTE (crelf @ Aug 15 2008, 11:21 PM)

PS: just posting about how one thing is better than another provides very little value to the community if you don't tell us why. We're all here to learn from each other, so please share what you know. Perhaps a feature comparison? Maybe a list of a few features that Accurev has that SVN doesn't?

Well they got a very nice website.

This 'customer success story' indicates there is support via the MS SCC interface.

However on the website there are no other references

Ton

[gmart]

QUOTE (Ton @ Aug 15 2008, 11:39 PM)

Well they got a very nice website.

This 'customer success story' indicates there is support via the MS SCC interface.

However on the website there are no other references

Ton

I found a download page for the AccuBridge for Microsoft SCC integration here - http://www.accurev.com/download_ab_2008_2.htm#note3

Assuming that is their support for the Microsoft SCC interface (pretty good chance), in theory, it should allow usage of Accurev from within LabVIEW.

[NeverDown]

QUOTE (crelf @ Aug 15 2008, 10:21 PM)

I don't know about your grandfather's SCC, but my grandfather's SCC is freakin' awesome!

PS: just posting about how one thing is better than another provides very little value to the community if you don't tell us why. We're all here to learn from each other, so please share what you know. Perhaps a feature comparison? Maybe a list of a few features that Accurev has that SVN doesn't?

Sorry about that. Busy couple weeks, but if you're really interested in learning about why a scc like Accurev can improve your life (if you're working on new and maintenance releases in parallel for e.g.) or have to worry about your 10 buddies across the hall or pond overwriting your hard work, the demo is 2 minutes and this paper I found on the website details some pretty nifty features you just won't find in a branch and label type scc tool. But of course this is all for not unless you're handy with APIs, and we don't have time for our own integrations at the moment. But believe me, we've got our eye on this.

http://www.accurev.com/competitive/accurev...on-analysis.pdf

http://www.accurev.com/demonstration.html

Also, a few cool short video comparisons:

http://www.accurev.com/scm-comparisons/acc...subversion.html

[crelf]

QUOTE (NeverDown @ Aug 18 2008, 09:22 AM)

Sorry about that. Busy couple weeks, but if you're really interested in learning about why a scc like Accurev can improve your life... ...we don't have time for our own integrations at the moment. But believe me, we've got our eye on this.

I'm a little confused - do you work for Accurev?

[gmart]

QUOTE (crelf @ Aug 18 2008, 08:10 AM)

I'm a little confused - do you work for Accurev?

Careful, some may accuse half the LAVA group of working on the Subversion code base