Interesting, it still works for you because you have a source file and “built”
file… with scripts its sorta redunant to require a built file, but some of you
are starting to convince me that I may have to create that kind of procedure,
always use make on everything and only distribute what is in the the “build”
dir after inserting version info however I want.
another thing I am thinking about doing, just thinking out loud here, is
combining RCS with fossil just to get the auto file versioning, because I also
like to have intermediate versions without commiting every little thing to the
repository. So for example, I could take a file that is already in the fossil
checkout, and work on it a bit. check it in and out of RCS (locally), do that
a few times…each time its bumping up the version number for me. When I’m ready
to make a single commit to fossil then the version will already be manually
updated by RCS and as well I will have those local versions to go back to in
between commits if I want to.
or I could just make sure to manually update the version number before commit
and get in the habit. Seems like at my old job with clearcase we had to
manually update version numbers in the source, but I can’t remember now its
been a while.
> On Aug 15, 2017, at 1:42 PM, j. van den hoff <veedeeh...@gmail.com> wrote:
>
> On Tue, 15 Aug 2017 19:57:34 +0200, Steve Schow <st...@bstage.com> wrote:
>
>> Related to this question, anyone have any workflow suggestions for
>> accomplishing this aside from remembering to bump the number manually in the
>> file before every important checkin or commit?
>
> my workaround is roughly like this:
>
> put an invariant `include' directive into your source file where the included
> file (called, e.g., `version') is a) not tracked by fossil and b) contains
> the current hash as delivered by `fossil info'. under linux/unix/macosx I
> specifically use
>
> fossil info|awk '/^checkout/{print substr($2,1,10)}'
>
> to get the hash itself.
>
> I update the `version' file during the make run. personally, I am using this
> approach not so much with source code but mostly with LaTeX or AsciiDoc
> documents where I want the version info in the formatted (pdf or html)
> output. works just fine. (actually I also check that `fossil changes' does
> not report anything. otherwise I add a trailing `+' to the hash indicating
> that the document is currently not yet checked in). of course the temporary
> file (`version') might be avoided if instead of the `include' some sort of
> `exec' of a subprocess is available directly substituting the hash into a
> variable.
>
> hth
> joerg
>
>>
>>
>>> On Aug 15, 2017, at 11:46 AM, Stephan Beal <sgb...@googlemail.com> wrote:
>>>
>>> 1) no.
>>>
>>>
>>> 1 - Is there any way to embed a substitution parameter into a source file
>>> that Fossil can replace with version info at time of checkin? (similar to
>>> RCS).
>>>
>>> thanks
>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
