Production Revision Feature

I'd like to see dBase implement a production revision feature that could/would
place an updated revision number inside each form,CC, etc, that could be used
for version tracking and a "check for updates" function.

I see there being an automatic setting, and perhaps a dialog box that asks the
developer if the revision number should be incremented when saving changes. 
This dialog box could also have a change summary entry area that could be
written to a production log file for that form,cc, etc.

On a related note, it would be handy to have a editor function that could allow
the developer to "post" a note to a log file related to the form or
file type being worked on.  If this were triggered by a menu option or control
key combination and resulted in a dialog box appearing already populated with
the date, the present "revision number" (see above) of the file in
use, the present cursor line number, and a copy of the line content prior to
changes.

Furthermore, an option that could allow not just one backup to be saved, but
sequential backups as development progresses.

The revision numbers should be able to be accessed through an internal function,
potentially without requiring a 'set proc to' so that the developer could
compare latest generation wfo's and co's to those installed on a client's
machine.

JM

Hi John,
Have you looked at my work on this?
If not take a look at the newsgroup alldbase.versioning
news://news.alldbase.com/alldbase.versioning
-- 
Rich...
www.autotraker.com
AutoTraker Inc.


"John Marshall" <john.marshall@nospam.com> wrote in message 
news:awgMbbXxHHA.1756@news-server...
>
> I'd like to see dBase implement a production revision feature that 
> could/would place an updated revision number inside each form,CC, etc, 
> that could be used for version tracking and a "check for updates"

> function.
>
> I see there being an automatic setting, and perhaps a dialog box that asks

> the developer if the revision number should be incremented when saving 
> changes.  This dialog box could also have a change summary entry area that

> could be written to a production log file for that form,cc, etc.
>
> On a related note, it would be handy to have a editor function that could 
> allow the developer to "post" a note to a log file related to the
form or 
> file type being worked on.  If this were triggered by a menu option or 
> control key combination and resulted in a dialog box appearing already 
> populated with the date, the present "revision number" (see
above) of the 
> file in use, the present cursor line number, and a copy of the line 
> content prior to changes.
>
> Furthermore, an option that could allow not just one backup to be saved, 
> but sequential backups as development progresses.
>
> The revision numbers should be able to be accessed through an internal 
> function, potentially without requiring a 'set proc to' so that the 
> developer could compare latest generation wfo's and co's to those 
> installed on a client's machine.
>
> JM
> 

Hi John. QAID 4856 was submitted as a request for this issue as well.
I put in a me too for you and re-submitted.

Thanks, Kathy
QA
dBI

"John Marshall" <john.marshall@nospam.com> wrote in message 
news:awgMbbXxHHA.1756@news-server...
>
> I'd like to see dBase implement a production revision feature that 
> could/would place an updated revision number inside each form,CC, etc, 
> that could be used for version tracking and a "check for updates"

> function.
>
> I see there being an automatic setting, and perhaps a dialog box that asks

> the developer if the revision number should be incremented when saving 
> changes.  This dialog box could also have a change summary entry area that

> could be written to a production log file for that form,cc, etc.
>
> On a related note, it would be handy to have a editor function that could 
> allow the developer to "post" a note to a log file related to the
form or 
> file type being worked on.  If this were triggered by a menu option or 
> control key combination and resulted in a dialog box appearing already 
> populated with the date, the present "revision number" (see
above) of the 
> file in use, the present cursor line number, and a copy of the line 
> content prior to changes.
>
> Furthermore, an option that could allow not just one backup to be saved, 
> but sequential backups as development progresses.
>
> The revision numbers should be able to be accessed through an internal 
> function, potentially without requiring a 'set proc to' so that the 
> developer could compare latest generation wfo's and co's to those 
> installed on a client's machine.
>
> JM
> 

Thanks Rich.  

Looks like this might work.  I have to say, I've been preoccupied with that
activation key over the web project and it's almost complete.  At that point
I'll attempt to stich it into that online payment module.  As this project
grows, it has become clear that such versioning is critical both for deployment,
but also as I (we) attempt to write functional 'check for updates' modules.  

Along those lines, you might also consider building into your cc a
"revision" level parameter that would hold back certain updates that
require data file changes before deployment.  In other words, at a certain
point, specific versions and updates may only apply to certain revisions - let's
say your application is about to release a version 6.xx - In this case all 5.xxx
revisions may want to stay 5.xxx + 1, separate and apart from the 6.xxx
revisions.

Just a thought.

JM


AutoTraker Inc. Wrote:

> Hi John,
> Have you looked at my work on this?
> If not take a look at the newsgroup alldbase.versioning
> news://news.alldbase.com/alldbase.versioning
> -- 
> Rich...
> www.autotraker.com
> AutoTraker Inc.
> 
> 
> "John Marshall" <john.marshall@nospam.com> wrote in message

> news:awgMbbXxHHA.1756@news-server...
> >
> > I'd like to see dBase implement a production revision feature that 
> > could/would place an updated revision number inside each form,CC, etc,

> > that could be used for version tracking and a "check for
updates" 
> > function.
> >
> > I see there being an automatic setting, and perhaps a dialog box that
asks 
> > the developer if the revision number should be incremented when saving

> > changes.  This dialog box could also have a change summary entry area
that 
> > could be written to a production log file for that form,cc, etc.
> >
> > On a related note, it would be handy to have a editor function that
could 
> > allow the developer to "post" a note to a log file related
to the form or 
> > file type being worked on.  If this were triggered by a menu option or

> > control key combination and resulted in a dialog box appearing already

> > populated with the date, the present "revision number" (see
above) of the 
> > file in use, the present cursor line number, and a copy of the line 
> > content prior to changes.
> >
> > Furthermore, an option that could allow not just one backup to be
saved, 
> > but sequential backups as development progresses.
> >
> > The revision numbers should be able to be accessed through an internal

> > function, potentially without requiring a 'set proc to' so that the 
> > developer could compare latest generation wfo's and co's to those 
> > installed on a client's machine.
> >
> > JM
> > 
> 
>