Re: Coding in Column 1

On Fri, 2015-09-18 at 15:51 -0500, Vernon Hamberg wrote:

I think the fact you are using Git has you in a direction that might
work - Git is a version control system, not a change management system,
so far as I know. Part of what Git does (and Subversion) is to keep
track of changes, as diffs - someone else, please help me, as I'm just
on the edge of knowing this.

Git stores the whole files, compressed into archives and assigns a
checksum style number to allow retrieval based on commit.

Git diffs are performed against the files (live against "last" or
between any two git commit id's, so you could - if you wanted - get a
list of all changes over the complete life span of a project; how much
use that would be is, however, open to debate).

So we don't really NEED to put in markers if we use this diff-erential
method.

The only problem I can see, and has happened maybe twice, is that some
changes listed in the diff listing are not _just_ the actual changes.
Sometimes depending on how the code has changed diff throws out spurious
"changes" when the lines didn't actually change, but rather other
changes confuses git (usually when code is very similar, then
duplicated, then some lines modified) and makes it mark lines as
deleted/added when in actual fact other lines were changed or added.

It also takes a while to get used to diff marking "changed" lines as
deletes (before) followed by adds (after).

The above said, git seems to have no problems when changes are more in
line with standard development over time as opposed re-writing and
duplicating massive chunks in one go yet recording a set of commits at
each partial stage of new development/ (I'm documenting some ideas I'm
playing around with, and git is being used to document the changes in a
way its not strictly designed to handle.)

A change in our thinking, yes.

BTW, you don't HAVE to go to the 1+ coding style - you flag it using the
**free in line 1 position 1 of your source member, otherwise it's all
our familiar way of coding from 8-80.

We can move gradually. And find our way.

It will be nice if the RDi team have some suggested ways to handle this
change - let's see what the help text has to say!!!

Vern

On 9/18/2015 3:44 PM, Buck Calabro wrote:

On 9/18/2015 3:24 PM, Kurt Anderson wrote:

I was curious what the community thinks about getting rid of the 'mod mark' concept (putting a ticket/request/whatever # in columns 1-5)?

The idea was worth trying, but in my experience there are some flaws:

Deleted lines - comment them specifically so we can put the ticket
number on them?

Changed lines that have been changed again - do we keep a mod mark
history or is the last one 'good enough'? If it is good enough, then
what is the value of any previous mod marks?

Added lines - how do you tell the line has been added to the code and
not changed?

Copied lines (like copying a block as a template for a new section of
code) - what happens if I forget (it happens!) to manually mod mark
these lines properly?

All in all it means that I need to perform manual labour which the
computer is perfectly capable of doing without the keypunch errors I
make, in order to satisfy a tradition which at best can only come close
to answering the question 'what lines were touched to implement this
ticket?'

Far better is a real change management tool. I don't have one either,
but I've started to rely on Git and I'm thinking I might be able to plug
in a ticket system like Jira too, but in the interim, plain English
comments seem to work out at least as well as the mod marks ever did.