[AccessD] Access versioning / tracking changes

Michael Bahr jedi at charm.net
Sat Sep 10 11:52:03 CDT 2011


> Michael,
>
> I pretty much understand all of that.  So what you are saying is that
> there is no way to really
> check out a version with everything except a specific change.  That really

revision not version, all changes up to and including that revision.

> makes sense given the
> possibility of interactions between lines of code.
>
> Actually even having the ability to look at changes at revision levels
> would be useful.

It is very useful BUT only source code which is text-based.  As someone
already mentioned FMS has this ability but it is a manual task after
GETting an earilier revision and comparing the two.

Another feature the SCM tools have is the ability to "branch" or run
developement in parallel to the main trunk.  Think of a tree, which has a
main trunk and branches.  The SCM tools allow you to branch then merge if
necessary back into the main trunk.

For example, you have a deliverable product and one of your customers
wants a specific feature that no onw else wants.  You branch your project
and add the new features and more forward from there without disturbing
the main product.  Now if the main product continues with its developement
then you can merge the specific revisions into the other branch to keep
the core application up to date.  However since you have a binary
file/application you would have to do the merging manually.  Then test and
do regression testing.

Mike...

>
> John W. Colby
> www.ColbyConsulting.com
>
> On 9/9/2011 1:21 PM, Michael Bahr wrote:
>> John, there are some concepts that you need to understand; version and
>> revision.  Revisions are incremental changes since the last offical
>> release or version.  Rollback "destroys" previous revisions.  You can
>> always checkout an earlier revision without destroying the other
>> revision
>> but, you still wind up with lost changes.
>>
>> SCM tools operate on text-based files or source code.  They have a
>> built-in ability to "compare" any two revisions for changes and display
>> the results, similair to standalone that compare text files.  Access is
>> binary so you can not compare anything.  That is your problem.  As
>> others
>> have mentioned there are some plug-ins available that could extract the
>> tables/queries/reports but it still binary.
>>
>>> I use a somewhat simple two table change request database for tracking
>>> changes to my Access
>>> projects.  I have to admit I find it problematic to track changes to a
>>> level that allows backing out
>>> any specific change while leaving the rest.  This has resulted in
>>> "rolling
>>> back" to a specific level
>>> when a problem comes up.  And yes they do test but things do happen.
>>>
>>> I have a CR table where the client places their change requests with
>>> explanatory text.  It has the
>>> typical requested date / requesting person / date to test / date tested
>>> etc.  A child table holds
>>> what I do with explanatory text and a test regimen to test that it
>>> work, a
>>> text for what they found
>>> in test (if problems).  I can add another record as a response to that
>>> testing problem etc.
>>>
>>> The problem I run into is that any significant change may involve a
>>> change
>>> to N queries, additional
>>> fields or entire tables, code modules and so forth.  A change may be
>>> trivial or it may be an entire
>>> subsystem.  I have never found a way to really document in sufficient
>>> detail what I did to implement
>>> the change that would allow me to back out just that change, at least
>>> of
>>> the change is very complex.
>>
>> Never gonna happen.  You will still loose everything after that change
>> provided that there are later revisions.  Even with text-based source
>> code
>> you can not just get a portion of a revision, it is the whole revision
>> or
>> nothing.  A possible solution would be to commit one requirement at a
>> time
>> instead of several.  Still will not solve your problem.
>>
>>>
>>> If I get two or three changes in and then one four changes back is
>>> found
>>> to be a problem such that
>>> they want to roll it back, I often times cant.  If we roll back all the
>>> changes since (go back to a
>>> previous version) then we lose all of the actual work done since.
>>
>> Can not be helped.  Then either the testing was incomplete or the
>> requirements were faulty or the understanding of the requirement was
>> faulty.
>>
>>>
>>> I have never worked in a large design team and witnessed how this is
>>> generally done.  I am wondering
>>> how you guys handle this stuff.  Any words of wisdom?  Tools?  tips?
>>>
>>> Can we have a discussion on this?
>>
>> You should have some requirements that the customer must provide testing
>> parameters/data so you can test and understand their changes.  If they
>> decide that those changes do not work then they must understand the
>> risks.
>>
>> Mike...
>>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>





More information about the AccessD mailing list