2017-11-30 12:03 GMT+01:00 Johan Kuuse :
> Hi,
>
> Patch removing unused variables in finfo.c.
Thanks!
<http://www.fossil-scm.org/index.html/info/c699e9fedf918eb8>
Regards,
Jan Nijtmans
___
fossil-dev mailing
2017-10-30 1:44 GMT+01:00 Richard Hipp:
> Version 2.3 has been out for a while. The change log for 2.4 looks
> like it is about the right length. I propose to do an official
> release soon. Objections?
+1. Everything is fine, I don't have any outstanding issues.
Regards,
2017-08-24 17:09 GMT+02:00 Martin Gagnon:
> I tried to compile the top of branch-2.3 and found that I get the
> following linking error:
Thanks for reminding me. Was too quick Should be fixed now.
Regards,
Jan Nijtmans
___
foss
t can continue normally. The self-hosting
fossil service can continue to use SQLite 2.20 beta.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ith fossil, both ways.
Regards,
Jan Nijtmans
>
> On 3/31/17, Jan Nijtmans wrote:
>> 2017-03-30 21:24 GMT+02:00 Richard Hipp:
>>> On 3/30/17, Jan Nijtmans wrote:
>>>> Ping .Could this be decided for Fossil 2.2? Please?
>>>
>>&g
2017-03-30 21:24 GMT+02:00 Richard Hipp:
> On 3/30/17, Jan Nijtmans wrote:
>> Ping .Could this be decided for Fossil 2.2? Please?
>
> libfossil is a non-trivial undertaking. Because of the way Fossil is
> currently architected, libfossil is basically a ground-up rewrite
Ping .Could this be decided for Fossil 2.2? Please?
Thanks,
Jan Nijtmans
-- Forwarded message --
From: Roy Marples
Date: 2017-02-26 23:03 GMT+01:00
Subject: Re: [fossil-dev] [fossil-users] Proposed roadmap for Fossil 2.0
To: fossil-...@lists.fossil-scm.org
On 26
> multiple branches with the same name, then you probably deserve
> whatever it is that happens.
> (2) The /brlist definition is easier to compute
I concur. A closed branch should be a branch in which all leaves are
closed. That's what I would expect.
Regards,
Jan Nijtmans
_
Op 18 okt. 2016 8:00 a.m. schreef "Stephan Beal":
> Fyi, the "too many bounces" problem is now apparently hitting gmail
users. AFAIK gmail never bounces.
Yeah, I got it too ...
Regards,
Jan Nijtmans
___
fossil-dev
case, just a "nice to have" with certain gcc versions.
>
>
> [1] = use memcpy() instead of *ptrDeref=foo.
Something like this?
<http://fossil-scm.org/index.html/vinfo/6ef54dfaf7fd90a4?sbs=1&w>
Thanks!
Jan Nijtmans
__
indeed be made faster than custom
byte-level checks, so this is definitely the way to go. The way it
is now (runtime-initialization of a constant table) could be
improved upon further, I'll be happy to have a look at this
after 1.35 is out.
Thanks!
Jan Nijtmans
2016-06-10 16:01 GMT+02:00 Richard Hipp:
> Any objections to cutting the Fossil 1.35 release sometime early next week?
Not at all! A look at at least the "reparent" and "andygoth-import"
branches would be appreciated.
Regard
2015-10-21 14:13 GMT+02:00 Martin Gagnon:
> On Wed, Oct 21, 2015 at 3:26 AM, Jan Nijtmans wrote:
>> 2015-10-20 19:51 GMT+02:00 Joe Mistachkin :
>>> I've moved the backout off trunk so the issues that remain, if any, can
>>> be fixed prior to the release.
&
2015-10-20 19:51 GMT+02:00 Joe Mistachkin :
> Jan Nijtmans wrote:
>>
>> It turns out that the cause of this problem is the following commit:
>> <http://www.fossil-scm.org/index.html/info/9431fec1ea098fea>
>> so I backed it out. My local trunk build doe
e was trivial to be understood, no
harm whatsoever was done.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
change. In this case, your change works fine and looks good to me.
Joe apparently agreed with this change, I agree as well. Well done!
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.o
GIT's
".gitignore". It's a choice whether you want to use ignore-glob like that
or not.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
on of fossil.exe since
zlib1.dll then always needs to be re-distributed with it.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
2015-04-29 11:43 GMT+02:00 Jan Nijtmans :
> 2015-04-29 3:37 GMT+02:00 Andy Bradford :
>> Thus said Richard Hipp on Tue, 28 Apr 2015 13:00:13 -0400:
>>> Why does "fossil clean --emptydirs" prompt for confirmation before
>>> removing an *empty* directory?
e directory name matches "empty-dirs", it should be kept,
otherwise it should be removed without asking for comfirmation.
I'm willing to implement that (unless some-one is faster
than me ;-)
Regards,
Jan Nijtmans
___
fossil-dev mailing lis
y dotfiles committed, so it makes
perfectly sense to make this setting versionable such that
all clones inherit it as well. That's exactly what versionalble
settings are meant for.
Thanks for the suggestion!
Regards,
Jan Nijtmans
___
fossil
2015-03-19 9:07 GMT+01:00 Jan Nijtmans :
> 2015-03-18 18:41 GMT+01:00 Richard Hipp :
>> Perhaps the right way to handle this case is to modify
>> https://www.fossil-scm.org/fossil/info/2e4de226a7?ln=1066-1110 so that
>> if
>>
>> (1) The operation is "push"
nored.) This would permit any repository to push into a
> freshly created repo and the freshly created repo would take on the
> identity of the repository that is doing the push.
I like this idea. Thanks!
Regards,
Jan Nijtmans
___
f
e Chiselapp "I have two trunks" problem.
Indeed, the --create option can be used as alternative to
--docker, solving case 1). For 2) this is not a solution yet.
Thanks! I will try this approach when fossil 1.33 is out, for
now at least there is a working 1.32 fossil image with a
solut
t
project-id and server-id. This repository is not usable
as-is. But as soon as "docker server" is started,
that's when the project-id and server-id is
generated. Without the --docker option all fossil
docker containers in the whole world would
have the same project
2015-02-24 10:09 GMT+01:00 Jan Nijtmans :
> Both branches are IMHO ready to be merged to trunk, that's
> the best way to get them tested by more people.
Any objections, merging the "svn-import" branch to trunk?
Regards,
Jan Nijtmans
_
to the "svn-import" branch.
Any more remarks by anyone?
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
much space (compared
with other things that need to be stored for each commit)
I would prefer automatic tagging to be on be default.
My 2c.
Thanks for all the great work, Martin and Baruch!
Regards,
Jan Nijtmans
___
fossil-de
28 matches
Mail list logo
