try the commit.
Am I close?
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
hanges RID's of Blobs. A rebuild doesn't do that.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
n Windows, where characters like
" * : < > ? | \
cannot be used in filenames ('[' and ']' are OK, B.T.W.).
Richard, could you please add '>', '<' and '|' to the replacement
set (or allow me to add them .) ?
Regards,
s!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2013/10/10 Jan Nijtmans :
> 2013/10/10 Martin Gagnon :
>> It happens that the only difference between 7 and 8 is the Makefile for
>> mingw which now define: -D_USE_32BIT_TIME_T
>
> This define should only be used for a 32-bit build, never for 64-bit, so
> this is indeed
heck in
Makefile.mingw whether "gcc" produces 32-bit or 64-bit executables,
that's why I came up with this #undef. I only have a 32-bit mingw
compiler (or 64-bit cross-compiled mingw-w64), so I cannot
really test it.
Anyway I'll have another look.
Thanks!
Jan Nijtmans
___
2013/10/11 Jan Nijtmans :
> 2013/10/11 Martin Gagnon :
>> I tried to fix this by making sure that every source include config.h
>> before any other includes, but I got stuck when I go the error from
>> sqlite3.c
Thanks! Fixed now. I was able to reproduce your problem us
other than patching SQLite?
Jan Nijtmans
gcc -Os -Wall -Lsrc/../compat/zlib -Isrc/../compat/zlib -DBROKEN_MINGW_CMDLINE=1
-o fossil.exe wbld/add.o wbld/allrepo.o wbld/attach.o wbld/bag.o wbld/bisect.o
wbld/blob.o wbld/branch.o wbld/browse.o wbld/captcha.o wbld/cgi.o wbld/checkin.o
wbld/c
2013/10/11 Jan Nijtmans :
> Yes, that looks better. And it indeed makes things simpler.
> Why didn't I think of that ;-) ...
>
> Unfortunately, it only fixes one of the two problems, and it breaks
> the normal MinGW build. See below for the log.
I finally figured
re of its own includes, no
special options should be needed. But working around
Microsoft's time_t tricks this looks like the best solution
here.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2013/10/11 Jan Nijtmans :
> It should be the same whether sqlite3.h is included or not
I tested the MinGW compile with the latest SQLite 3.8.1
beta. It works fine. Actually, including before
or after doesn't make any difference: The
only system include in is ,
and this include is not
ery much in the field,
it was written to assist the Tcl project in implementing email
hooks, like you are doing. It's not being used there yet, otherwise
I am sure that this redirect bug already would have been found
by someone. Many thanks!
Regards,
Jan Nijtmans
___
ord (for the
fossil repository) is not stored, so with every sync a
"login failed" error appears and I have to type the
password. After typing the correct password, the sync
succeeds.
So, if this little thing could be fixed as well, it would be perfect!
Thanks!
Jan Nijtmans
2013/10/28 Jan Nijtmans :
> >fossil sync https://jan.nijtmans:*@www.fossil-scm.org/fossil
> via proxy: http://130.139.104.40:8080
.
> So, if this little thing could be fixed as well, it would be perfect!
Follow-up: If I do the same without specifying the passwor
n "yes, just this time" and
> "always now and all future times", specifically, "yes for the duration of
> this
> command", since Fossil often performs multiple HTTP/HTTPS exchanges
> during a pull/push/sync.
Yes, I agree, but that's not "jan-
2013/10/29 Ron Wilson :
> Thanks for your fix for proxying HTTPS session.
I assume that's directed to Jan Danielsson, not to me
(although my name is Jan too..)
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@list
tunnel" branch
(proxying https over an http tunnel),
but I never checked whether trunk had
the same problem with plain "http"..
Are you using a proxy?
So, I guess I owe Jan Danielsson an
apology. Sorry!
Is there someone who knows how to fix
this? (I'm not c
for saving the password was implemented in 1.26:
<http://fossil-scm.org/index.html/info/6d6740dcca7d1b4c>
I tried this version too, and it works exactly the same.
My conclusion is that this isn't a regression. It never worked as I
(intuitively) would expect it to work, and it ap
ctions?
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ing related to the further dialog.
So I think that only the --once option should prevent prompts,
otherwise prompts may come on any moment: wrong/unthrusted
certifcates, wrong password, sync failure (try again.) .
That's my 2 cents, plus another 2 from 劉芳亭 and 2 from Andy,
that makes 6 ;
to go here.
> But it will not affect me, since I never use it that way.
Thanks for all feedback! I appreciate it!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
should
still be there.
Something like this?
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
without a saved url, auto-sync
doesn't make much sense. But I agree it's a separate issue.
Let's not give "fossil clone" a --once option, I don't think I would
ever use it.
Andy, many thanks for all your work! I will do some more testing,
but I think it really is an
It's not a
big deal, the way it is now is already better than it was!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
merge of those two
branches didn't have any conflicts,
and everything works fine.
So, +1 from me. No more remarks.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ine.
An alternative could be to do the reverse: Output a last line like:
=== timeline complete ===
when there are no more entries. Would you prefer that?
However, I would like to be able to tell the difference, whether
the loop stopped because the limit was reached or there
a
2013/11/5 Jan Nijtmans :
> fossil clone [--once] http://u...@url.org
> fossil sync [--once] http://u...@url.org
> fossil pull [--once] http://u...@url.org
> fossil push [--once] http://u...@url.org
>
> 1) When not cloning, if a password is necessary
> and ther
2013/11/12 Jan Nijtmans :
> Something is wrong on trunk:
> $ ./fossil sync http://jan.nijtm...@www.fossil-scm.org/fossil
> missing or incorrect password for user "jan.nijtmans"
> with previous fossil, and corresponding to test description:
> $ fossil sync http:
more eyes
having a final look at it.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2013/11/13 Andy Bradford
:
> Thus said Jan Nijtmans on Tue, 12 Nov 2013 16:52:57 +0100:
>
>> I think it works fine, but I would appreciate more eyes having a final
>> look at it.
>
> Here's another observation. Now that I got around the proxy problem (the
> proxy
items than to hide them, just by removing
the "hidden" tag later.
I could imagine an "Unhide" button on the timeline,
which makes the "hidden" items visible. Didn't
implement that yet, but it's easy.
Regards,
Jan Nijtmans
__
added the "hidden" tag is still visible in the timeline,
so you can always get the SHA1 from there.
Thanks for your feedback! I'll try to add a "Unhide" button to the timeline,
it looks like that will make operating the "hidden" tag more clear.
nting any nodes from "trunk"
ever to be hidden.
Many thanks to Martin, Andy, Matt and Ron for your feedback!
Any more feedback? If not I would like to merge this to trunk.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-us
; http://www.fossil-scm.org/index.html/artifact/a366fc950d92e1b7d063855450561128adb149bc?ln=1758
>
> It gets set on line 1758, but then never used; consequently it appears
> that the -u|--unhide option in the commandline timeline doesn't work.
I didn't manage to get the SQL ri
lution for your use: If
you share the repository with others, everyone will see the same
nodes hidden, but other people might be interested in other subsets.
Some filtering method on present tags? .
Regards,
Jan Nijtmans
___
fossil-users mailin
'bug' (IMHO) that can be created in other
ways, e.g. by shunning or when (not) syncing private
check-ins. Apparently it's not so easy to fix, as it's not
trivial when an arrow is expected to be drawn an when
not. For hiding the "mistake" branch (that's actually
wha
2013/12/13 Mark Janssen :
> What is the state of the tkt-hool-change branch? I tried using it for my own
> local repo and I can't get the http ticket hook to trigger.
Looks like an uninitialized variable. Should be fixed now.
I think it's ready to be merged to trunk.
Thanks!
Re
something wrong, like
an incomplete commit. Please try again ;-)
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
d to properly fill all the urlData
> fields instead of having to memset the structure before.
I'm not sure on that, in other situations it might be that some fields
are pre-filled with defaults, to be used as default. I'll leave
that to Joe and/or Richard t
length ;-(
<http://fossil-scm.org/index.html/info/a60d2976ff>
Again, Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
the same as
it is now, except that the bug you found is fixed.
Thanks!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2013/12/14 Andy Bradford :
> Thus said Jan Nijtmans on Sat, 14 Dec 2013 11:06:15 +0100:
>
>> Then the ordering of the tags can be kept the same as it is now,
>> except that the bug you found is fixed.
>
> Yes, thanks for the suggestion. I think is is better now:
>
2013/12/13 Mark Janssen :
> Thanks for the quick fixes :) Everything works great now.
@Joe/Richard: Any reason to hold back merging this to trunk?
If not, I'm happy to do the merge.
Regards,
Jan Nijtmans
___
fossil-users mailing list
foss
s even be allowed? If not, a simple change to skip when the
> tagid is TAG_USER will suffice.
According to the fossil documentation:
> Each manifest has a single U-card.
So, I think you are right: this should be disallowed. If every manifest must
have an U-card, it doesn't make se
2013/12/16 Jan Nijtmans :
> @Joe/Richard: Any reason to hold back merging this to trunk?
>
> If not, I'm happy to do the merge.
No-one objected, so merged to trunk now.
Happy Christmas days to all!
Jan Nijtmans
___
fossil-user
in a single action.
Done that for your commit. If you want to see it, press
the "Unhide" button.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
t check-in will actually have rid=1):
fossil update rid:1
You could also tag the first initial checking with anything
you like, then you can use that tag in the future:
fossil tag add "mother" rid:1
fossil update mother
Regards,
Jan Nijtmans
_
less useful and there is no way to unhide it except by
> manually adding unhide to the URL:
Fixed here:
<http://fossil-scm.org/index.html/info/fd0507e949>
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-user
2013/12/23 Jan Nijtmans :
> 2013/12/23 Andy Bradford :
>> Hello,
>>
>> When clicking on the genealogy links from the /info page for a hidden
>> check-in (e.g. family, ancestors, descendants, branch), the timeline
>> does not display the hidden content
t;timeline-utc" option work). Before
merging this to trunk I would like some
more pairs of eyes having a look at it.
Anyone?
Many thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.o
SQLite version might lag somewhat behind, requiring
SQLite 3.8.2 for fossil just was a little bit too soon. But
I'm happy to remove this workaround in a year or so,
it shouldn't be kept forever (added a note on that).
Every Fossil version should be clear on which minimum
SQLite version it s
able
in the hook GET/POST is the uuid, from that the
server can derive anything else it needs to
know by accessing the fossil repository.
Other people already used this successfully, so
feel free to try it and post your feedback here.
Thanks!
Regards,
Jan Nijtmans
is received is parsed in order
to be able to update the various tables. After this parsing,
the needed information is available, this is used to
trigger the "Transfer Commit Script" if it was a commit
or the "Transfer Ticket Script" if it was a ticket c
enough.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
with every new Fossil release.
As soon as the Cygwin enhancements are
adopted by SQLite (in whatever modified form),
--disable-internal-sqlite doesn't give any advantage
on Cygwin any more. But as long as that
doesn't happen, I hope that --disable-internal-sqlite
will be kept as-is.
Reg
ould be possible to make a Fossil release at any time,
independent from SQLite. As long as Fossil doesn't use any
SQLite features which are not available yet in the latest SQLite
release, either the latest SQLite amalgamation could be shipped
with it, either the latest SQLite t
6-w64-mingw32- \
FOSSIL_ENABLE_SSL=1 openssl all
Then have some 10 minutes patience, a new "fossil.exe" will
appear in the top directory.
Or, you can simply download fossil-w32-2013094349.zip
from here: <http://www.fossil-scm.org/download.html>
The fossil.exe in th
2014/1/6 Jan Nijtmans :
> (4) Immediately after the fossil 1.28 release, add a runtime-check
> for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add
> "WITHOUT ROWID" to whatever SQL statement it is useful.
> Unconditionally!
Implementation here:
is always better
than an implicit version check.
In other words, "require-sqlite_strglob" would have been a better
name for this Fossil tag.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http:/
those two situations.
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
will be release with the
best-tested-and-most-stable SQLite version.
Of course, more bug-fixes could be merged to
SQLite's "branch-3.8.2" branch, but I don't see
any which are relevant to Fossil.
Regards,
Jan Nijtmans
___
fossil-
2014/1/9 Mark Janssen :
> I tested it with ticket changes from the web interface.
That's indeed what I suspected. I have a different fix
in mind, I'll come back on that later.
Thanks!
Jan Nijtmans
___
fossil-users mailing list
table SQLite automatically.
I hope this is an important argument for keeping
the --disable-internal-sqlite option.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2014/1/9 Richard Hipp :
> Jan - would you like to start the "branch-1.28" containing the SQLite 3.8.2
> release?
<http://fossil-scm.org/index.html/timeline?r=branch-1.28>
Regards,
Jan Nijtmans
___
fossil-users mai
result: 2 errors out of 18914 tests
* Failures: merge-utf-24-23 merge-utf-24-32
This is no big deal: Fossil 1.26 and 1.27 had the same
failures, I am convinced that those 2 are test-case errors.
Regards,
Jan Nijtmans
___
fossil-users m
2014/1/9 Jan Nijtmans :
> I have a different fix
> in mind, I'll come back on that later.
<http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook>
Does this work for you?
Regards,
Jan Nijtmans
___
fossil-users mailing
t hurt either. Anyway, It will miss the 1.28
release, but it should be merge-able to trunk not too long
after that.
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
han enough time to think how this should be
fixed the 'correct' way, which satisfies everyone (I hope).
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
e. Doing this through Tcl's http::formatQuery
command is a lot more expensive.
Anyone interested in writing a TH1
encodeURIComponent() function? I guess
more parts in fossil could benefit from that.
Regards,
Jan Nijtmans
___
fossil-users m
2014/1/11 Richard Hipp :
> I don't think this should hinder the release.
That's great news. So the valgrind error in the /tar page and
the two failing test-cases (which simply could be disabled) are
the only things which should be handled? I wouldn't know
anything else. Thanks!
to do this either with the official fossil binary or with a
> little sql hackery? What things are likely to break if I go down this path?
I don't think anything will break. Fossil cannot handle rid=0 checkouts
in all commands (yet), but "commit" works fine and after the first comm
pinions? Does the documentation need modification?
Of course, any package maintainer can either patch
their own main.mk or just use --disable-internal-sqlite,
but still. I think that Fossil should follow it's own
recommendations in production builds.
Regards,
Jan Nijtmans
_
it should be on or off, that's not my main point.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2014/1/13 Jan Nijtmans :
> In that case, I think that "build.wiki" (and the comment in
> SQLite) should be adapted accordingly. I have no opinion
> whether it should be on or off, that's not my main point.
Of course, I meant "makefile.wiki"
2014/1/13 Jan Nijtmans :
> Of course, I meant "makefile.wiki"
<http://fossil-scm.org/index.html/info/cde4759d5e>
Thanks! That was exactly my question.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@l
2014/1/13 Mark Janssen :
> I am not sure if this is an issue with my MinGW install, but latest trunk
> fails to build on MinGW. I think it's useful if the official release can
> also be built on MinGW.
<http://fossil-scm.org/index.html/info/354288db9c>
Thanks!
Branch "branch-1.28" currently contains SQLite 3.8.2
with 5 additional bug-fixes: All the ones mentioned
above except the last one. Of course, this needs
approval from Richard. Any more bug-fixes that
should go in the branch? Any bug-fixes that I missed?
Thank you very much for your attenti
:
<http://sourceforge.net/p/mingw/bugs/2125/>
After 3 month this MinGW bug is still not fixed. I'm using
MinGW-W64 for my normal builds, although I have a patched
"MinGW" environment too. It might very well be that latest
MinGW still lacks LABEL_SECURITY_INFORMATION,
any
on appears there.
(Already fixed by Joe in SQLite trunk, I just cherry-picked it)
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2014/1/14 Jan Nijtmans :
> And the last one which doesn't affect fossil
> at all because fossil doesn't use fork():
> <https://www.mail-archive.com/sqlite-users@sqlite.org/msg81284.html>
>
> Branch "branch-1.28" currently contains SQLite 3.8.2
&g
getUTCSeconds())*1000);
}
}
The standard styles included in Fossil don't have such a clock
(but it would be a nice addition... hint .)
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
gives local time, which is
(when not using "fossil ui") different.
Ideal would be if there was a third setting (apart from
server localtime and UTC time) : client localtime. But
some javascript would be needed to implement that, it's
not trivia
sqlite3 can deal with.
sqlite3_strglob() uses exactly the same Globbing rules as Fossil's
strglob(), most likely both are written by the same author ;-)
See:
<http://www.sqlite.org/src/artifact/6325ac2ec10833cc?ln=591-601>
Regards,
Jan Nijtmans
ission on the HOME directory, permission on the
configuration file is enough. Now the permission checks on Windows
and UNIX are made equal.
Thanks!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists
2014/1/24 j. van den hoff :
> any ideas?
<http://fossil-scm.org/index.html/info/d8a588ba76>
Looks like this has been missing always.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm
tial SQLite version check), and that works fine too.
2014-01-27 Richard Hipp :
> I think URL like:.../tree?ci=trunk will fail without 3.8.2.
This is the url which uses "WITHOUT ROWID" in trunk, but
thanks to the SQLite version check it d
be several months (>4) old.
For Fossil 1.28, requiring SQLite 3.8.2 (dec. 2013) just was
a little bit too early. But since changing the initial SQLite
version check is easy, it's not really a problem. Actually,
I expected this kind of question to arrive ;-)
Regards,
t is highly appreciated!
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
xplain how, maybe the check in db.c line 844
should use R_OK in stead of W_OK. It would mean that
the configuration db cannot be written, but for a
"fossil server/ui" I wouldn't expect this file to be
written anyway.
Feedback appreciated
trunk.
See:
<https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13898.html>
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
2014-02-04 Jan Nijtmans :
> Currently, the "jan-httpsproxytunnel" has a single
> left bug: when checking certificates, the host
> being compared is the one from the proxy while
> it should be the end-point host. As soon as
> that bug is fixed (should be easy for you), I
&g
2014-02-05 16:02 GMT+01:00 Jan Nijtmans :
> My attempt to fix this bug is here:
> <http://www.fossil-scm.org/index.html/info/6673f163ea>
>
> Jan (Danielsson), could you please verify that this is
> correct? If so, then I think this could be merged to trunk.
> For me it
2014-01-12 0:09 GMT+01:00 Mark Janssen :
> On 11 Jan 2014 20:09, "Jan Nijtmans" wrote:
>> Anyone interested in writing a TH1
>> encodeURIComponent() function? I guess
>> more parts in fossil could benefit from that.
>
> Of course it would be easier if th1 had
James Turner
Thanks! Fixed here:
<http://fossil-scm.org/index.html/info/0681b39b82>
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
tay compatible with Windows XP. Starting with Vista everything works.
Yes it's a regression in MinGW, see:
<http://fossil-scm.org/index.html/tktview?name=18cff45a4e>
and
<https://sourceforge.net/p/mingw/bugs/2125/>
Regards,
Jan Nijtmans
_
2014-02-20 14:46 GMT+01:00 Jan Nijtmans :
> 2014-02-20 14:39 GMT+01:00 Samuel Debionne :
>> Hello all,
>>
>> Compiling Fossil with the latest MinGW32 (that includes MinGW Runtime >
>> 4.0) seems not to require _USE_32BIT_TIME_T.
> Yes it's a regression in Mi
is DT_UNKNOWN
As far as I know it is never considered. I simply have no idea how
wide-spread it is.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
t;
?
It looks like _DIRENT_HAVE_D_TYPE is set for MSC
(win/include/dirent.h) and on WinGW-w64, but not bare
MinGW. I have no idea whether's it's worth or not.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fos
build" is not an operation touching that.
The only operations this is expected giving a speedup is
in "fossil extra" or "fossil addremove": Functions which
traverse the checked-out filesystem.
Regards,
Jan Nijtmans
___
2014-02-21 12:43 GMT+01:00 Jan Nijtmans :
> The only operations this is expected giving a speedup is
> in "fossil extra" or "fossil addremove": Functions which
> traverse the checked-out filesystem.
Measured on Cygwin64, on checked-out/built fossil repo (mtime
201 - 300 of 488 matches
Mail list logo
