Re: Version Control Strategies For Block-Based Forths?
  Home FAQ Contact Sign in
comp.lang.forth only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: Version Control Strategies For Block-Based Forths?         

Group: comp.lang.forth · Group Profile
Author: Jean-François Michaud
Date: Sep 19, 2008 09:37

On Sep 19, 9:18 am, Jean-François Michaud comcast.net> wrote:
> On Sep 19, 8:51 am, John Passaniti JapanIsShinto.com> wrote:
>
>
>
>> Let's start with what I'm not interested in.  I'm not interested in a
>> debate on different version control systems or on the usefulness of
>> version control in general.
>
>> What I am interested in is what *existing* strategies may have been used
>> in the past (or are used now) for doing version control using Forths
>> that stored source using *true* blocks.
>
>> Note carefully that I make two qualifications here:  First, I'm only
>> interested in *existing* strategies because I'm looking for something
>> that has been proven by others, not an abstract discussion about what
>> possibly could be done.  Second, I'm asking about Forth systems that are
>> based on *true* blocks, not blocks implemented on top of files since the
>> trivial answer in that case would be to version control the files
>> holding blocks.
>
>> I appreciate that such a version control system might be ultra-minimal
>> and not offer features like branching, tagging, differencing, and
>> merging, etc..  It might only offer manual roll-back of a specific block
>> to a prior state, or possibly a grand snapshot of all blocks captured at
>> a particular point in time.  Whatever-- I'm just looking for past
>> strategies.
>
> Are you looking for past strategies or current strategies (or both)?
> You context seems to imply you're interested in both but in each
> individual reference, you only want one or the other.
>
> Regards
> Jean-Francois Michaud

In any case, modern versioning tools usually store the deltas of the
modification instead of a full snapshot of the file. A full snapshot
could otherwise be too space consuming. A version number is associated
to each delta and the extraction of a "version" involves taking the
original file and rolling through each successive delta in turn up to
the desired version. This is more complex to implement but its
certainly a space saver since only the deltas are stored post original
check-in of the file. A check-in/check-out concept is usually
necessary to prevent concurrent tampering. A "multi" function to pull
all version X for a set of blocks is built on top of the function that
allows you to pull a specific version. Rollback is just a question of
deleting the deltas post a certain version.

A simpler approach is to simply store the entire block while tying a
version number to it. Pulling the version is as simple as looking up
the associated pairs (version and block). This is simple to implement
but will rapidly become bulky space-wise; check-in/check-out is
necessary here as well. The same "multi" function applies under the
bulky solution. Rollback is the same as previously mentioned except
that here we delete whole blocks instead of deltas.

Regards
Jean-Francois Michaud
no comments
diggit! del.icio.us! reddit!