[mdlug] Version control: tools and training

[Jeff Hanson]

My customer uses Perforce which is cross-platform with GUI and command-line
tools.  It has a free license that is limited by number of users and
workspaces (systems it is installed on per user account).  Licenses for
larger number of users is not free.  I find it is relatively easy to use
and understand.  You set up a directory on all systems for "work" then add
it to the Perforce repo.  Files are "checked-in" to the repo.  Other
clients can obtain any version checked-in of any file (there are access
controls also).  To edit a file you check it out first otherwise it's
read-only on your system.  It can merge source files from multiple users
(simultaneous edits) but not non-text files.

Perforce recently acquired Seapine Software who developed the
cross-platform TestTrack bug tracking system.

Perforce has tutorials on its web site.


On Tue, Feb 21, 2017 at 8:34 AM, Dave McMillan <skyefire at skyefire.org>
wrote:

>
>     This... is going to be rather off-topic, but this is the most likely
> group I know of to ask about this.
>
>     I work for a Detroit-area industrial-automation company that's never
> really been a software development house, but now finds itself becoming one
> unexpectedly.  So I've been tasked with finding a way to bring us into the
> 21st century. :-\
>
>     So, I have a small group of "developers" that are essentially
> self-taught, and have spent their careers doing mostly one-off software
> projects and managing their own versions and backups independently (if at
> all), often mostly inside their heads.  Plus a larger number of "debuggers"
> that have less programming skill, but get much more time on the active
> machines, who will be the people who do most of the bug-finding and
> reporting, and installing/testing updates and bugfixes pushed out by the
> developers.  And customers that want levels of traceability and
> documentation that, frankly, we've *never* done.
>
>     Just to ice the cake, this being industrial automation means that a
> lot of our source code is tied up in proprietary languages that are
> recorded in proprietary binary formats and not generally accessible by
> 3rd-party tools like (for example) git.  So I'm in the position of possibly
> being forced to maintain an entire *ecosystem* of different version-control
> systems with brand-specific branches for different pieces of equipment.
>
>     And did I mention that while *some* software has to be
> centrally-controlled, other parts of the *same* software have to be
> field-editable on a machine-by-machine basis?  And I have to track *all* of
> that.
>
>      So, right now, my biggest concern is less the *tools,* than the
> *training.*  Whatever tool (or tool set) we end up choosing (and there I'm
> at the mercy of the beancounters), I think my *bigger* problem is the total
> lack of any in-house *culture* for version control, multi-person
> developer/debug teams, and obsessive tracking/documentation/etc.  And I,
> frankly, am just as clueless. So, I'll put it to people who (hopefully)
> know more about this kind of thing than I do:  where do I *start*?  Are
> there training programs, or certification courses, or even just a *really
> good* O'Reilly book that I can use to get myself off square one?  And does
> anyone know of any sort of training curriculum for bringing this sort of
> cultural shift into an existing "herd of cats" development team?
>
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug
>