Hi Paul,
thanks very much for your quick response.
>> fossil and sqlite solve that somehow by being compiled :-) -- they just
>> compile the information from those manifest files in their final
>> executable, but thats not a reasonable approach for scripts that are
>> executed by an interpreter.
>
> Actually, both fossil and sqlite use their build interpreter ('make' and
> 'tcl' respectively) to process the manifest files into source code. What
> stops your interpreter from doing the same? It could perform all the
> functions you require, perhaps using additional info made available
> through the manifest.
Well, usually scripts checked in some version control system are simply
ready to run (executable bit set) as they are and don't require a
'preprocessing' step to generate some kind of executable (in contrast to
C/C++ programs like sqlite and fossil) . The source *is* the executable so
to say.
That means you cannot distribute this executable versioned unless you either
distribute the manifest files altogether with the script or you somehow
change it after checkout/update/commit by some helper scripts to include the
version inside. If you distribute your script to someone else I find it
rather unconvinient to give hime some "detached version information" like
the manifest files that for sure will be lost, not noticed or not unpacked
properly on the other side.
Of course I can also imagine checking in only some 'skeleton' for the script
and let make or other tools create the real script from this skeleton and
the manifest and whatever on demand as you propose above, but then changes
in the script cannot be done in-place for the next check in. You have to
edit the skeleton and create the script from it each time. It simply adds
two (IMHO unnecessary?) steps in the development workflow if you would like
to have a version embedded in the script. (Note there are also no commit
hooks in fossil to automate that, this would have been another possible
approach)
> Personally I've always considered 'in source' markers as a bad hack,
> rooted in now ancient tools (SCCS/1972 and RCS/1982). I'm not against the
> idea per se, but I would like to understand your requirements better.
> Could you elaborate?
I don't like general keyword expansion either, but for the special case
'scripts' (maybe also for easy versioned plain text documents like concepts,
rfcs or similar) it could make sense. That's why it should be a well
configurable optional feature (as for example in mercurial).
> Could you elaborate?
Hope this was now understandable enough, please ask if there are still
things unclear.
Thanks
Tino
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
