Re: [fossil-users] tags manifest

[Jan Danielsson]

On 04/08/16 00:08, Warren Young wrote:
>> This means that the same
>> information is available in two different places
> 
> Only two?  Aren’t you the lucky one. :)

   Not that lucky, unfortunately.  :(  That was mostly referring to
cases such as sqlite and even fossil itself.  In our case it refers to
how some of the more recent repositories have been set up.  There are
old monolithic repositories which acted as "catch-all" repositories back
in the day and which we have been unable to break up for various
reasons.  They have many different components and versions in the same
repositories.  Then again, some of them are stuck in CVS and Subversion,
but my hope is to someday split them up as much as can possible be done
and convert them to fossil repositories..

> In my current main projects, the release version number appears in:
> 
> - the top-level build system file (configure.ac, CMakeLists.txt, etc.)
> - the most recent section at the top of the ChangeLog
> - the source file feeding “./myprogram -v” or the About screen
> - the binary package description file(s) (e.g. *.spec for RPM)
> - the Fossil release tag
> - the comment on the Fossil checkin creating the release tag
> 
> We drive everything from the first item on that list, except that the 
> ChangeLog remains manually-updated.  In that sense, we have “only” two places 
> to change the version number, too.
> 
> The formal release version number in our system has two parts: the 
> human-facing version number (e.g. 1.2.3) and the binary package release 
> number (e.g. -1) which combine to give the formal release number, 1.2.3-1.  
> These two parts may be in the same top-level file (e.g. CMakeLists.txt for a 
> CMake based project) or in separate files (e.g. configure.ac and *.spec.in 
> for an Autoconf + RPM based project).
> 
> We use the binary package release number to distinguish two different Fossil 
> checkins both tagged someproject-1.2.3.  The checkin comment for the first 
> tag will say “Release someproject v1.2.3-1”, and the second “…-2”.
> 
> The Fossil tag checkin and its checkin comment are generated by a mkrel 
> script we wrote which parses the version number out of one of the generated 
> files, such as *.spec file in an Autoconf + RPM based project, which as I 
> have said is generated from *.spec.in and configure.ac.
> 
> Other files come off of this, such as a version.h file for a C++ project, 
> generated from version.h.in by Autoconf, which gets it from configure.ac.
> 
> Because we want the binary package release number in the Fossil release tag’s 
> checkin comment, generated by the mkrel script, Fossil doesn’t get involved 
> until nearly the end of this process.  My initial thought from that 
> observation is that this means we can’t really replace our current scheme 
> with your scheme. If you had to redesign our scheme to use your new feature, 
> how would you go about it?

   Yeah, so you just perfectly summarized why versioning is a massive
pain in the you-know-what, and that tools even today are lacking in
helping manage version numbers.  And it gets really fun when people try
to be clever and have "funny" schemes like "the version converges
towards pi.".  (Which I myself thought was funny and clever until I
started writing tools for managing version numbers..).

   I can't answer your question without dedicating some time to it, and
I can't say that I would come up with an good manifest.tags-solution for
your specific case.  That's one of the things I realized after a few
failures -- whatever scheme you come up with, it has its limitations.

   There's much I can relate to in the procedures you described, so I
definitely understand where you're coming from.

> I don’t mean to dismiss your efforts, Jan.  It solves a real problem, and I 
> wish it was available before we started solving these problems on our own, 
> many years ago.  I’m willing to offer a weak sort of endorsement for 
> trunkifying it, since I haven’t played with it, but I can see that it’s 
> useful already.

   No worries, I didn't take it as a dismissal; but you're highlighting
something I should have been clearer about:  I was primarily aiming to
solve one particular problem for one, as I see it, fairly typical case.
Looking at the open source projects I follow closely, such a scheme
could be used for the majority of them.  That said, there are plenty of
cases where its use would be very limited.

>> Someone(tm) needs to make sure they match.
> 
> Or, as we have both discovered, some *thing*.  This is a task for automata, 
> not humans.

   Exactly.

>> Each new released version is tagged using a -
>> tag.
> 
> Tagged how?  Manually?

   Yes, but we have some tools to assist in that as well.  I have a
script which automatically tags "next version" (for fossil projects):

   $ revup major
   mytest-1.0.1 -> mytest-2.0.0
   $ revup minor
   mytest-1.0.1 -> mytest-1.1.0
   $ revup
   mytest-1.0.1 -> mytest-1.0.2

   ... but it has been kind of flaky, 

Re: [fossil-users] tags manifest

[Warren Young]

On Aug 3, 2016, at 10:24 AM, Jan Danielsson  wrote:
> 
> This means that the same
> information is available in two different places

Only two?  Aren’t you the lucky one. :)

In my current main projects, the release version number appears in:

- the top-level build system file (configure.ac, CMakeLists.txt, etc.)
- the most recent section at the top of the ChangeLog
- the source file feeding “./myprogram -v” or the About screen
- the binary package description file(s) (e.g. *.spec for RPM)
- the Fossil release tag
- the comment on the Fossil checkin creating the release tag

We drive everything from the first item on that list, except that the ChangeLog 
remains manually-updated.  In that sense, we have “only” two places to change 
the version number, too.

The formal release version number in our system has two parts: the human-facing 
version number (e.g. 1.2.3) and the binary package release number (e.g. -1) 
which combine to give the formal release number, 1.2.3-1.  These two parts may 
be in the same top-level file (e.g. CMakeLists.txt for a CMake based project) 
or in separate files (e.g. configure.ac and *.spec.in for an Autoconf + RPM 
based project).

We use the binary package release number to distinguish two different Fossil 
checkins both tagged someproject-1.2.3.  The checkin comment for the first tag 
will say “Release someproject v1.2.3-1”, and the second “…-2”.

The Fossil tag checkin and its checkin comment are generated by a mkrel script 
we wrote which parses the version number out of one of the generated files, 
such as *.spec file in an Autoconf + RPM based project, which as I have said is 
generated from *.spec.in and configure.ac.

Other files come off of this, such as a version.h file for a C++ project, 
generated from version.h.in by Autoconf, which gets it from configure.ac.

Because we want the binary package release number in the Fossil release tag’s 
checkin comment, generated by the mkrel script, Fossil doesn’t get involved 
until nearly the end of this process.  My initial thought from that observation 
is that this means we can’t really replace our current scheme with your scheme. 
If you had to redesign our scheme to use your new feature, how would you go 
about it?

I don’t mean to dismiss your efforts, Jan.  It solves a real problem, and I 
wish it was available before we started solving these problems on our own, many 
years ago.  I’m willing to offer a weak sort of endorsement for trunkifying it, 
since I haven’t played with it, but I can see that it’s useful already.

> Someone(tm) needs to make sure they match.

Or, as we have both discovered, some *thing*.  This is a task for automata, not 
humans.

> Each new released version is tagged using a -
> tag.

Tagged how?  Manually?

> The build system iterates through each line of manifest.tags

I don’t see what your build system is getting from manifest.tags that it 
couldn’t already get from the T card in the current manifest file.

>   Thoughts?

Your vague use of  makes me wonder if you’re using this in any 
Fossil repositories that host multiple related projects that nevertheless build 
to separate outputs, such as the client and server for a distributed system, 
giving two separate binary packages, each possibly with different version 
numbering.

Does your build system use this project name to detect which binary package(s) 
to build?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tags manifest

[Robertson, Joseph M.]

I do the opposite.

Coders check in code, but the build system manages both the version id files 
and the labeling, so they are always in sync.
(we are not using fossil as our vcs at work)

My steps are:
Check out code
Increment versionids in .h or .java files
Build
(verify using human eyeballs and quick tests)
Checkin work products and .h/.java id files
Label sources and work products and .h/.java id files.

This process should work for any vcs, whereas yours only works for fossil.


Joe


-Original Message-
From: fossil-users [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf 
Of Jan Danielsson
Sent: Wednesday, August 03, 2016 11:24 AM
To: Fossil SCM user's discussion
Subject: [fossil-users] tags manifest

Hello,

   Since I've finally got a few days off, I've done some updates to the 
jan-manifest-tags; merge with trunk, made some bugfixes, and thought I'd 
reintroduce the branch (since it's been a while).

   The basic idea is the following:  It's common practice for projects to tag 
new release versions of their software.  Separately from that, there's a 
version number somewhere in the source tree (like #define VER_MAJ 1, #define 
VER_MIN 2, etc).  This means that the same information is available in two 
different places and Someone(tm) needs to make sure they match.  The idea for a 
tags manifest-like feature came about when I was working in a high-assurance 
project a long time ago and it happened once or twice that due to human errors, 
the two versions didn't match.  (not-so-high-assurance..).

   Tags manifests allows build systems to be able to extract the tagged version 
information from manifests generated by fossil.  This has the positive 
side-effect that the build system will work in tarballs and zipfiles generated 
by fossil, as they will contain the manifest files (provided the server has the 
appropriate manifest settings..).

   One addition (as per feedback) was to include the current branch at the top 
of the manifest.tags.  It uses the special "branch=" prefix.
Note that this is only done when operating in an open working tree.
I.e. the branch=... will not be available in generated tarballs and zipfiles, 
so don't make your build system rely on the "branch="-entry if you want you 
want the build system to work in exported tarballs or zipfiles.

   How we use it:

   Each new released version is tagged using a - tag.  
Our build server checks out a clean copy of a tagged version.  The build system 
iterates through each line of manifest.tags and looks for -X.Y.Z 
(where X, Y, and Z are numbers).  Once found, it either uses the version 
numbers to generate a header file, or a -DVERSION=... argument to the compiler. 
 For non-release builds, such an entry will not be found in manifest.tags, and 
it will use a special version number to indicate it's a development build.

   Other uses include using special (propagating) tag names (like
"experimental") to make the build system take special actions.

   We've been using a version of the branch for a pretty long time now, and I'm 
starting to feel that it's ready for trunkification.

   For those who are afraid of new features messing with your current
setup:  The jan-manifest-tags branch is explicitly designed to not interfere 
with your current setup.  You need to take action for a change to occur.  If 
you use "set manifest on" or "set manifest off" it will work exactly like it 
always has.  I.e. if you don't care about this feature, you - as an end user - 
will not notice it's there (apart an updates settings field and help text).

   Thoughts?

--
Kind Regards,
Jan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

-- 
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use 
by the addressee(s) named herein and may contain legally privileged and/or 
confidential information. If you are not the intended recipient of this 
e-mail message, you are hereby notified that any dissemination, 
distribution or copying of this e-mail message, and any attachments 
thereto, is strictly prohibited. If you have received this e-mail message 
in error, please immediately notify the sender and permanently delete the 
original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT 
INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform 
Electronic Transactions Act or the applicability of any other law of 
similar substance and effect, absent an express statement to the contrary 
hereinabove, this e-mail message its contents, and any attachments hereto 
are not intended to represent an offer or acceptance to enter into a 
contract and are not otherwise intended to bind the sender, Sanmina 
Corporation (or any of its subsidiaries), or any other person or entity.

-- 
CONFIDENTIALITY
This 

[fossil-users] tags manifest

[Jan Danielsson]

Hello,

   Since I've finally got a few days off, I've done some updates to the
jan-manifest-tags; merge with trunk, made some bugfixes, and thought I'd
reintroduce the branch (since it's been a while).

   The basic idea is the following:  It's common practice for projects
to tag new release versions of their software.  Separately from that,
there's a version number somewhere in the source tree (like #define
VER_MAJ 1, #define VER_MIN 2, etc).  This means that the same
information is available in two different places and Someone(tm) needs
to make sure they match.  The idea for a tags manifest-like feature came
about when I was working in a high-assurance project a long time ago and
it happened once or twice that due to human errors, the two versions
didn't match.  (not-so-high-assurance..).

   Tags manifests allows build systems to be able to extract the tagged
version information from manifests generated by fossil.  This has the
positive side-effect that the build system will work in tarballs and
zipfiles generated by fossil, as they will contain the manifest files
(provided the server has the appropriate manifest settings..).

   One addition (as per feedback) was to include the current branch at
the top of the manifest.tags.  It uses the special "branch=" prefix.
Note that this is only done when operating in an open working tree.
I.e. the branch=... will not be available in generated tarballs and
zipfiles, so don't make your build system rely on the "branch="-entry if
you want you want the build system to work in exported tarballs or zipfiles.

   How we use it:

   Each new released version is tagged using a -
tag.  Our build server checks out a clean copy of a tagged version.  The
build system iterates through each line of manifest.tags and looks for
-X.Y.Z (where X, Y, and Z are numbers).  Once found, it
either uses the version numbers to generate a header file, or a
-DVERSION=... argument to the compiler.  For non-release builds, such an
entry will not be found in manifest.tags, and it will use a special
version number to indicate it's a development build.

   Other uses include using special (propagating) tag names (like
"experimental") to make the build system take special actions.

   We've been using a version of the branch for a pretty long time now,
and I'm starting to feel that it's ready for trunkification.

   For those who are afraid of new features messing with your current
setup:  The jan-manifest-tags branch is explicitly designed to not
interfere with your current setup.  You need to take action for a change
to occur.  If you use "set manifest on" or "set manifest off" it will
work exactly like it always has.  I.e. if you don't care about this
feature, you - as an end user - will not notice it's there (apart an
updates settings field and help text).

   Thoughts?

-- 
Kind Regards,
Jan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] How to host fossil repositories on web server that supports only FastCGI interface?

[Ron W]

On Wed, Aug 3, 2016 at 6:08 AM, John Found  wrote:

>
> Well, I was actually wrong. fcgiwrap actually *can* wrap bash cgi scripts
> (and also, perl, etc.)
> So, the problem is solved and I can recommend using fcgiwrap tool for
> hosting fossil repositories
> on high performance web servers without CGI support, like nginx and rwasa.


Another, possibly better, option occurred to me. If the webserver supports
it, configure it to "pass through" to Fossil and run Fossil in server mode.
Essentially, the webserver would be acting as a proxy server for the base
URL for Fossil. ( I recall seeing something about how to configure Fossil
to operate from behind a proxy)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] How to host fossil repositories on web server that supports only FastCGI interface?

[John Found]

On Tue, 2 Aug 2016 19:46:12 +0300
John Found  wrote:

> On Tue, 2 Aug 2016 14:43:11 +0300
> John Found  wrote:
> 
> > Indeed, I found very similar tool "fcgiwrap": 
> > https://github.com/gnosek/fcgiwrap
> > Will try to use it to wrap fossil in CGI mode, as long as the SCGI mode of 
> > fossil 
> > is very similar wrapper, only built-in. One layer less is always good IMHO.
> > 
> 
> But fcgiwrap can't wrap bash scripts. Only binaries, only hardcore. :)
> So, is it possible to use fossil in CGI mode without wrapping it with bash 
> CGI script?
> 

Well, I was actually wrong. fcgiwrap actually *can* wrap bash cgi scripts (and 
also, perl, etc.)
So, the problem is solved and I can recommend using fcgiwrap tool for hosting 
fossil repositories
on high performance web servers without CGI support, like nginx and rwasa.

-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users