On 25/04/15 16:30, boB Stepp wrote:
And what would be the best approach to integrating Git with these
efforts? Just how often does one commit one's code to the version
control system? Or do I have some GCEs (Gross Conceptual Errors) here?
Going back to first principles.
What is often called Version Control or Configuration Management
actually encompasses two distinct disciplines:
1) File versioning
2) Release management
File versioning is where you save multiple versions of files as
you go so that you can revert to a previous version. This could
be because you've made some bad changes that you want to back
out or it could be because you have a production version that
is not current and it has developed a bug. It also supports
branching which is where you develop parallel streams of
development. This could be to support different platforms etc.
Its also an important tool to manage multiple developers working
on the same files - but that is less of an issue for you.
Release management is about organising groups of files into
releases and versioning the whole release. Thus release 1.0
contains:
v1.4 of File A
v3.7 of FileB
v2.2 of Fi;le C
and so on.
A release should ideally also keep the toolset with which
the release was created (older compiler versions/OS etc) but
often that is simply stored as a text file with the necessary
details recorded.
That way you can call up release 1 at any time. As with files
you may have branched parallel developments of releases as well
as individual files. For example you may have 2 production
releases, a system test release and one or more development
releases active at any time. You may need to recreate any
of those releases at any given moment.
So, to decide what to do about Config Mgt you need to decide
whether you want to focus on version control or release control?
Or both. The tools tend to be focused on one or the other.
If you are just starting out I'd recommend a basic version
control setup because its much simpler and you can use the
reporting tools and batch files to manually handle releases
initially. If you do a lot of releases with multiple files
then you should maybe jump into a release capable tool right
away.
CM tools are like editors and they tend to have rabid supporters.
I've used over a dozen of them over the years, mostly commercial
and many costing thousands of dollars, but there are capable open
source ones nowadays that can certainly do all that you want.
Many of the modern tools are focussed on multi-developer, parallel,
distributed, developments; as is typical of open source projects.
If you are a small team/individual working on a single
release stream in a single site things are much simpler.
My experience in that area is limited to SCCS/RCS for file based version
control and CVS and SVN for release management. But my needs are fairly
simple...
Also many tools can be integrated with editors like Eclipse,
Netbeans, Visual Studio, emacs and vim. This makes basic functions
much easier to use - literally a mouse click away.
But the first decision is what exactly do you want to use the
tool for?
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
