On 8/6/2016 12:02 PM, Jan Danielsson wrote:
On 05/08/16 02:51, Ross Berteig wrote:
Many thanks; this saved me a lot of time, as a non-native tcl
speaker. And as such, I also would like someone to quickly look over
the additions I've made. It seems to work, but I have a feeling I have
have
On 8/3/16, Jan Danielsson wrote:
>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.
>
>Thoughts?
I am not completely happy with the format of the manifest.tags file.
The current format is:
branch=jan-man
On 05/08/16 02:51, Ross Berteig wrote:
[---]
> I just created test cases for fossil set manifest that verify that the
> files manifest, manifest.uuid, and manifest.tags appear and disappear as
> the setting is changed. I did not verify that any of the files have the
> right content.
Many thanks
On 04/08/16 20:44, Warren Young wrote:
>> That's one of the things I realized after a few
>> failures -- whatever scheme you come up with, it has its limitations.
>
> That’s part of what I mean, but I’m not just talking about simple
> limitations. The second and third applications of the code in
On 8/4/2016 2:33 PM, Ross Berteig wrote:
I just built it and ran the existing test suite over it on Windows. It
passes all existing tests. I didn't spot any test cases for the new
feature
I just created test cases for fossil set manifest that verify that the
files manifest, manifest.uuid,
On 8/3/2016 9:24 AM, Jan Danielsson wrote:
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
On Aug 3, 2016, at 7:48 PM, Jan Danielsson wrote:
>
> And it gets really fun when people try
> to be clever and have "funny" schemes like "the version converges
> towards pi.”
It’s funny that you should mention that. On reading the announcement of the
upcoming “pi” release of SQLite, I began h
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 refer
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, CMakeL
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,
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 versi
11 matches
Mail list logo
