In case you didn't notice it yet, the current version of the Recipe
Executive can obtain files from a CVS repository (this requires the
"cvs" command, Vim doesn't do it all by itself!).
Because of the chicken-egg problem you still need to start with a CVS
command:
cvs -d:pserver:
anonymous@...:/cvsroot/a-a-p checkout Exec
This creates the "Exec" directory and puts the source files in there.
After that Aap can refresh itself with this simple recipe:
refresh:
:refresh {origin = cvs://} .
Put this recipe as "main.aap" in the Exec directory and do "./Main.py"
(the "main.aap" recipe is the default and "refresh" is the default
target since it comes first). CVS will think about it and refresh the
changed files for you.
However, I have been reconsidering the names of the targets, commands
and attributes to be used for accessing a Version Control System (VCS).
The basic things to offer to a user are:
refresh: obtain the latest version from the VCS
checkout: obtain a file to work on (lock the file)
commit: write changes back to the VCS (keeping it locked)
checkin: write changes back to the VCS (unlocking it)
unlock: unlock without writing changes
The locking isn't done for systems that don't support it, such as CVS.
"refresh" and "checkout" do the same thing then. "commit" and "checkin"
are also equal for CVS.
Additionally, there needs to be a target for sending out a new release
to the world. I thought of several names for this:
distribute
release
publish
Currently I think "publish" is the best. "distribute" is clear but
long. "release" is confusing: VCS systems use it to undo a checkout
(release a lock).
To make consistent use of these names, I intend to use the same name for
the command that does the work and for the attribute that specifies how
to do it. For a start, this would mean changing the "origin" attribute
to "refresh".
A few examples to see what this all means:
SOURCE = main.c version.c
:attr {refresh =
ftp://ftp.foo.org/pub/foo/%file%} $SOURCE
refresh:
:refresh $SOURCE
This says that the source files can be obtained from an ftp server
(%file% is replaced by the file name). The "refresh" target does the
work of obtaining the files (this happens always, since ftp has no
reliable way to tell if a file actually changed). The "refresh" target
here actually does the same as what would be done automatically, thus it
could be omitted.
Since "checkout", "commit", "checkin" and "unlock" use the same VCS,
only one of them needs to be used as an attribute. I think using
"commit" is best.
SOURCE = main.c version.c
:attr {commit =
cvs://:ext:$FOOUSER@cvs.foo.sf.net:/cvsroot/foo}
checkout:
:checkout $SOURCE
commit:
:commit $SOURCE
checkin:
:checkin $SOURCE
unlock:
:unlock $SOURCE
The difference between "commit" and "publish" is that "commit" mostly
only involve source files and "publish" may also include generated
files, such as executables. "commit" is for using a Version Control
System while "publish" may upload to an ftp site.
SOURCE = main.c version.c
TARGET = prog
ZIPFILE = prog.zip
PUBLISHED = $SOURCE $TARGET
:attr {publish =
scp://$FOOUSER@ftp.foo.org/foo} $ZIPFILE
$ZIPFILE: $PUBLISHED
:sys zip $ZIPFILE $PUBLISHED
publish: $ZIPFILE
:publish $ZIPFILE
Instead of using the ":attr" command to add the "publish" attribute and
then using it for the ":publish" command further on, it's possible to do
this at once by specifying the attribute with the ":publish" command:
:publish {publish =
scp://$FOOUSER@ftp.foo.org/foo} $ZIPFILE
Putting the "publish" attribute at the ":publish" command looks a bit
strange, but it's consistent with how parameters are specified.
Comments?
--
Sometimes you can protect millions of dollars in your budget simply by buying
a bag of cookies, dropping it on the budget anylyst's desk, and saying
something deeply personal such as "How was your weekend, big guy?"
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar --
Bram@... --
http://www.moolenaar.net \\\
/// Creator of Vim --
http://vim.sf.net --
ftp://ftp.vim.org/pub/vim \\\
\\\ Project leader for A-A-P --
http://www.a-a-p.org ///
\\\ Help me helping AIDS orphans in Uganda -
http://iccf-holland.org ///