PLUG+ - Possible Presenters

[Nate_Moehring]

This page lists names of people who have shown an interest in presenting at a future ALVUG meeting, and the topic they are considering.  Please feel free to add your name to this list. 

• LV Idea Exchange education/advocation
• Actor Framework - Orbital Sciences - Ryan Griffin
• Continuous Integration - Medtronic - Brian/Damion/Philip
• Plugins using Packed Project Libraries - Michael Lacasse/Philip Timson
• Network Streams - Orbital Sciences - Martin Meyer
• Hardware Abstraction Layers - Medtronic - Brian/Damion/Philip
• Handling Configuration Data - G System Solutions - Michael Klessons
• Bob Tripp - FlexAble Systems - USB SDK
• Source Code Control - G System Solutions - Michael Klessons
• Advanced LabVIEW FPGA - Intel - Gary Wolford
• Class-based GUI manager - Imaginatics - Michael Ashe
• NI Vision module - Imaginatics - Michael Ashe
• Software Engineering tools - Lowell Observatory - Paul Lotz
• Active Objects - Orbital Sciences - Nate Moehring
• Network Shared Variables for PC to PC communication? - Kelly Bersch
• VI Scripting - G System Solutions - Michael Klessons

[klessm1]

i am thinking about possibly presenting using mucerial with tortoise hg and possibly kiln plugins as a source code control system as opposed to using svn. there isnt much chatter about it in the community. i am using it for a couple projects, but need to really research how to get the most out of it. it may be a great tool for open source labview development. main roadblocks are how it treats binary files and how to integrate labviews merge tool to take advantage of mucerials strengths. more research needed, but may be able to present down  the road a bit. sorry about lower case i am posting from my phone.

[Nate_Moehring]

If there are some really distinguishing features compared to Tortoise SVN, it might be a good presentation to give.  But if it's similiar, then I'm not sure attendees will feel like they got very much usable information from it, partially because Amiri gave a presentation on SVN just a few meetings ago.  But maybe, you can be the judge of that, or others can chime in on this topic.  I'm just happy to have volunteers to present, I trust your judgment on what would benefit an advanced audience.

Thanks,

Nate

[klessm1]

Mercurial is quite different then Subversion. If I find it benificial (still researching) I was thinking of presenting on how it could be sucessfully used in a LabVIEW development team then just how to use Tortiose HG. Tortiose HG has a similar feel to Tortiose SVN so it is pretty easy to learn, but the source code control concepts behind it are much different.  Mercurial is a distributed SCC while Subversion is central server based.  When linked with kiln you have a central repository management system with a tight link to a great issue tracking system (fogbugz).  Kiln is basically a way to share your repositories with other users in a central server.  It can manage groups of repositories associated with specific projects (grouping, branching, merging).   I could probably cover a little on fogbugz as well.  It is pretty well suited for smaller operations when not wanting to go with the entire Jira suite.

Since Mercurial is a local database, it does not have the concept of a locked file.  Which is really good in the text world, but not the greatest in LabVIEW land.  Although  I contend that most well architected projects should not have more then one team member touching the same code at the same time.  In corner cases you may have only one or two vi's at the most.  If I can get LabVIEW merge integrated with mecurial then I think it may be a viable solution.

Here is a link to some info on Mercurial if anyone is interested:

http://mercurial.selenic.com/wiki/UnderstandingMercurial

Here is a link to some info on kiln and fogbugz:

http://www.fogcreek.com/kiln/

http://www.fogcreek.com/fogbugz/

[Nate_Moehring]

Issue tracking integration is something I would like to learn more about.  We use issue tracking software but the links to SCC are only in the checkin comments, it would be nice to have better integration.

We use exclusive checkout exclusively.    We have a large code base and even though we have issue tracking software and assign incidents to people, it's not uncommon that two people want to change the same VI for different reasons.  But having the merge tool integrated into SCC might alleviate the need for exclusive checkouts, we just haven't investigated it, the need isn't high enough.

Visual SourceSafe is client based.  The file repository stays on the server, but there is no server software that runs or that clients connect to.  The clients access the data through standard Windows file sharing.  VSS works great on small networks, but as soon as the network has any number of hops, and as the database grows, VSS slows down to a crawl.  I don't know how much of this is because of the thick client interface, but it seems ridiculously slow, and using that as my point of reference, would be shy about any SCC software that is not server based.  Just my thought...

[klessm1]

I wouldn't use VSS if my employer forced me

It is the worst highly used SCC software in the market.

No true branching or merging.

No atomic commits.

Very slow when going through any type of network outside a LAN.

Limited database size.

Data corruption issues.

Does not support changesets.

Difficult for offsite contractors to work on projects (user permissions and network access)

I could go on and on

Anyway, Mercurial is pretty much the opposite of VSS.  Your repository doesn't exist on a network drive to share with others, it exists on your local hard drive until you push to a web server (like Kiln or your own website).  The pushes are smart so you are only pushing changesets after the initial push into the repository.  The pulls are also smart so you only pull the changesets that you do not have. Mercurial scales from  a single person to very large very scattered teams.  The open source community relies heavily on distributed SCC like GIT and Mercurial (Linux kernel development is done using GIT).

I attached the Mercurial handbook if people feel like doing a little reading.  The first couple chapters kind of sum up what mercurial is all about.  All of their examples are in command line, but the Tortoise HG client takes care of all of that for you.

I know quite a few text coders that absolutely love mercurial, but due to LabVIEW's binary nature it really hasn't made headway in our arena.

I could present on issue tracking integration, but I would have to pick two programs to pair up.  And there are a ton out there.  I have used Seapine's Surround and TestTrack for SCC and issue tracking.  I am using Kiln and Fogbugz right now.  Fogbugz also integrates with SVN...  I haven't delt much with Jira, but have heard good things about it.

[Nate_Moehring]

I hope you didn't get the impression that I like VSS.  I do think VSS is very easy to use, and that's its best selling point, but other than that I've been advocating for our company to leave VSS ever since I came here 5 years ago.  I don't trust it.

[klessm1]

i didnt get that impression. i used is for eight years at medtronic and it was a pain. i just wanted to clarify the differnces between a tool like vss and a tool like mercurial.  some communities actually talk the same about svn when compared to mercurial or git.  it is that benificial to their situation. now if it as benificial to ours is the question i am trying to answer.

[Imaginatics]

I agree with many of Michaels comments concerning VSS's problems. The one caveat I would add is that some of the issues can be alleviated if you use a 3rd party client to go between the local user and the VSS repository.  I am thinking specifically of "Source OffSite".  It speeds things up over a network considerably, makes things a lot safer too. You no longer have the danger of a client crashing/corrupting the database.   Nate, if you cannot convince your company to abandon VSS, then at least try to get them to consider Source OffSite.