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
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
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
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
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
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,
6 matches
Mail list logo