[mdlug] Version control: tools and training

[Dr. Robert Meier]

Dave,

Version control is a wide field.
This is a first summary.
Further details  will follow.
Your response beforehand will help direct details.

There are many proprietary tools available for industrial software 
management.
My experience has been mostly with IBM Rational (in the 90s
called Smart) and I can recommend it for its ease-of-configuration,
line-level resolution, support of plug-ins/custom scripts.

There are many open source tools available for industrial software 
management.
My experience has been mostly with svn, git, and cvs.
I can recommend all of the above especially:
	svn - centrally mastered with support for field-editing
	git - distributed master with support (via svn bridge)
		for central control
	cvs - centrally mastered, scriptable, with svn interface

There are two basic divisions for version control and nearly all
tools support both, but usually are heavily biased toward one side.
The better tools (including those named above) will interface
(e.g. via bridge, virtual agent, ...) seamlessly with their
opposite number.

1. (svn, rational)
	central master - One host has the master copy of all files.
	editing - files are "checked out" for editing
		usu. each file can be simultaneously checked out by
			only one user
		better tools (rational, svn) support "merging"
			when two editors conflict
	branches - identify SEQUENCES of fileset changes
	labels - identify STATES of fileset changes
	security - central reading and writing restrictions
2. (git)
	distributed master - Each file master may be on different host.
    	editing - files are copied (individually or en-masse) for edit
	security - separate from revision (since file master is mutable)
		usu. rules applied to pulls toward "master" host
	temporary repo - contain SEQUENCES of fileset changes
	archive repo - contain STATES of fileset changes
		
Training is available online for both approaches.

Hopefully helpful,
--
Bob



On 02/21/2017 08:34 AM, Dave McMillan 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
>