Would it be too difficult to put the branch tag (i.e the tag with asterisk from
'fossil br li' output) in the first line of manifest.tags?
We use the combination of uuid and branch tag for versioning.
S.
Original Message
From: Jan Danielsson
Sent: Monday, 4 January 2016 16:03
Subject: Re
Hello,
drh and sgbeal brought up the following points:
1) Make sure an existing [managed] manifest.tags isn't overwritten.
2) fossil add needs to be made manifest.tags-aware.
3) Tarballs and zips need to be made manifest.tags-aware.
4) fossil clean needs to be made manifest.tags
On 04/01/16 02:02, Richard Hipp wrote:
> On 1/3/16, bch wrote:
>> Indeed. I thought maybe the \n of the checkin-card (is this the right
>> characterization ?) bug/fix might fix what I've been experiencing, so
>> I updated to the latest. I'm nearly always running the tip of TRUNK.
>
> Any idea wha
On 1/3/16, bch wrote:
> Indeed. I thought maybe the \n of the checkin-card (is this the right
> characterization ?) bug/fix might fix what I've been experiencing, so
> I updated to the latest. I'm nearly always running the tip of TRUNK.
>
Any idea what version Joerg is running on his server?
--
On 01/01/16 18:43, Jan Danielsson wrote:
[---]
>Optimally the tagged version _is_ the source version. [...]
I'm home sick, so I started working on this in the branch
jan-manifest-tags.
I'd like some feedback on the settings semantics. What I want to
accomplish is that any existing sett
Indeed. I thought maybe the \n of the checkin-card (is this the right
characterization ?) bug/fix might fix what I've been experiencing, so
I updated to the latest. I'm nearly always running the tip of TRUNK.
On 1/3/16, Richard Hipp wrote:
> On 1/3/16, bch wrote:
>> The continuing saga of syncin
On 1/3/16, bch wrote:
> The continuing saga of syncing netbsd-src:
>
> I've got a fossil processing kicked off by: fossil sync --verily
> (against: http://netbsd.sonnenberger.org/timeline)
>
> that has now consumed 594 minutes of CPU time, and produced no network
> traffic (as measured by tcpdump)
The continuing saga of syncing netbsd-src:
I've got a fossil processing kicked off by: fossil sync --verily
(against: http://netbsd.sonnenberger.org/timeline)
that has now consumed 594 minutes of CPU time, and produced no network
traffic (as measured by tcpdump)... when I ktruss(1) it, it's only
8 matches
Mail list logo