or
added security, check out the files to a RAM disk.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 2/1/17, Rainer J.H. Brandt wrote:
>
> building fossil 1.37 via "make -f Makefile.classic" failed
First question is why are you using Makefile.classic rather than
"./configure; make"?
--
D. Richard Hipp
d...@sqlite.org
___
sil does not care. You might want to close some of the branch
heads just to keep your repository tidy, but that is an aesthetic
concern that (while important to human readers) does not affect the
integrity of the repository.
I got a little confused with your description. If you can share your
repository,
On 2/6/17, Richard Hipp wrote:
>
> That is correct, and it is by design. Fossil allows any number of
> branches to share the same name.
On second thought, perhaps it would be worthwhile to enhance Fossil so
that it issued a warning if you include a --branch argument on "fossil
co
policy: Let's keep the [b21df7ec] check-in open as a test
case for branches where recent leaves are closed but there exists an
older leaf that is still open.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ks more bugs in the future.
>
> I could upload my repo by I believe it is more effective to follow the
> steps I have provided as evidence of the issue. If you have any confusion
> please walk through the example with the web ui open, it should clear your
> confusion up.
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ntly on that
branch - type "fossil update BRANCHNAME" to go there" or similar?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
state, after every
command. Then provide a command like:
fossil set newbie-hints off --global
That will turn off all the extra verbiage after users get comfortable
with the system.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailin
On 2/7/17, john lunzer wrote:
> There is a risk
> of drowning important information which would do the opposite of helping
> "newbies".
Agreed. Finding the right balance is tricky.
--
D. Richard Hipp
d...@sqlite.org
___
fossil
robably have to be fixed on the Fossil end. I'm guessing the
git people will not be receptive to fixing it on the git side.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.o
On 2/12/17, Thomas Bilk wrote:
>
> I guess there was a regression introduced somewhere between [8b03934e]
> and [fb4b87d9].
Would you be willing to bisect for us?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fos
intf("from %s\n", zMark);
>>
>> Still, this will need a restructuring of the export flow.
>> This may also become a run-away problem, once we start chasing the
>> parent commit-chain through potential merges etc.
> ____
do that, but I couldn't find it in
> the docs. Any help or pointers to the relevant docs would be most
> appreciated.
>
> Thanks,
>
> Zoltan
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.o
On 2/17/17, Rafal Bisingier wrote:
>
> Shouldn't Fossil at least warn user trying to commit a child wit
> timestamp earlier than parent?
I think it does that, now. The timewarps all happened a while ago.
--
D. Richard Hipp
d...@sqlite.org
On 2/17/17, Richard Hipp wrote:
> On 2/17/17, Rafal Bisingier wrote:
>>
>> Shouldn't Fossil at least warn user trying to commit a child wit
>> timestamp earlier than parent?
>
> I think it does that, now.
Confirmed: That fix went in 7 years ago:
https:
ctive commit.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
l developers do as well. If you really
need a 32-bit binary, you can always build your own use the source
tarball, right?
Or, perhaps you are simply asking that the downloads be relabeled from
"x86" to "x64"?
--
D. Richard Hipp
d...@sqlite.org
__
-12-22 23:48:56',6930
Here we see some a few long gaps back in the 20th century, but at the
top of the list is the great sourceforge outage of 2011.
I don't know if the above has any practical use for most people (or I
would make it a new URI on the Fossil webserver) but it seems like
So
(for me at least) the choices are 32-bit Windows builds, or 64-bit
builds that lack "https" capabilities.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cg
ned files. Knowledgeable users are free to visit
https://www.fossil-scm.org/fossil/uvlist if they like, but that is not
a page that we especially want to call to the attention of newbies.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fos
n. Later I
thought I might reuse the field for some other purpose, so I have
never purged it. It is usually NULL, is it not?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
the SHA3 standard
(example: Keccak[196]) be supported? K196 is desirable in that its
hash length is 48 bytes, only 8 bytes longer than SHA1.
Feedback is welcomed and encouraged, though let's keep the discussion
on fossil-dev and off of fossil-users if possible. Thanks.
--
D. Richard Hipp
d
ional database as its backing store. Git and Hg, in contrast,
both use bespoke pile-of-files database formats which, I suspect, will
be more difficult to adapt.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossi
o boast that Fossil
transitioned away from SHA1 painlessly, quickly, and efficiently and
without breaking any legacy.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi
and 256 as those values are already assigned to other hashes.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
mmand line arguments will
continue to work just as if no hash algorithm change had ever
occurred.
(8) The above is just a plan. Everything is subject to change.
(9) Your feedback is encouraged and appreciated.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-use
On 2/26/17, Richard Hipp wrote:
> I propose that the next release of Fossil be called "Fossil 2.0"
An alpha version of Fossil 2.0 is now live on the main fossil website:
https://www.fossil-scm.org/
That same Fossil instance also runs SQLite: https://www.sqlite.org/src
On 3/1/17, sky5w...@gmail.com wrote:
> More 2.0+ requests...
Fossil 2.0 will say focused on one thing: SHA3
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-
On 3/1/17, Sean Woods wrote:
> Do you keep updating Fossil 1.x? Will changes to the Fossil 1.x line be
> ported to 2.x?
No. Fossil 2.0 is a drop-in replace for Fossil 1.x. If you find a
problem in historical Fossil 1.x, then the solution is to upgrade to
Fossil 2.0.
--
D. Richard
ating only SHA3 hash names.
(3) There is a new "sha3sum" command made available for your convenience.
Further documentation updates are likely prior to the release, but at
this point the code is feature complete and ready for testing. Please
repo
On 3/1/17, Tony Papadimitriou wrote:
>
> I believe DRH asked for feedback. And that was my feedback.
Thank you. Your responses are very useful to me.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-s
On 3/1/17, jungle boogie wrote:
> Hi All,
>
> Getting some failures from trunk.
Harmless compiler warnings should now all be fixed. Please try again
and report back what you find.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mai
ontent is added by means other than a check-in
(examples: cluster artifacts added by the server on a sync, Wiki
pages, ticket attachments, or unversioned content files) then use the
hash algorithm that was used by the most recent check-in.
--
D. Richard Hi
actually generate SHA3-256 hashes.
Please report any problems or concerns to this mailing list, or directly to me.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin
SHA3-256.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
all of trunk
from https://www.fossil-scm.org/fossil/tarball?uuid=trunk and untar
it, run ./configure; make, and then copy the new "fossil" binary to
somewhere on your $PATH. Works every time, regardless of what version
of Fossil is currently installed.
--
D. Richar
On 3/4/17, jungle Boogie wrote:
> On 3 March 2017 at 05:45, Richard Hipp wrote:
>> Fossil version 2.0 is now available on the Fossil website
>> (https://www.fossil-scm.org/download.html) and its mirrors.
>
> How about including sha1 and sha3 hases for the downloads?
&
out soon.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
re having to deal with this. If there was anything I
could do about it, I would.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ssil-scm.org/fossil/uv/download.html page soon. Please
try out the new code and provide feedback.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fo
On 3/6/17, Warren Young wrote:
> On Mar 5, 2017, at 4:01 PM, Richard Hipp wrote:
>>
>> Please try out the new code and provide feedback.
>
> I build with parallel make almost all the time, and I got this error when
> updating one of my fossil-scm.org trees likely last upd
On 3/7/17, jungle Boogie wrote:
> ..\src\sqlcmd.c(217) : error C2039: 'fNoThHook' : is not a member of
> 'Global'
Please try again with the latest check-in.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
*and*
> add the new more generic --hash option?
Fixed on trunk. Thanks.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
off date
(yet to be decided).
(5) There are no known attacks (other than exhaustive search which is
still computationally prohibitive) against the Hardened-SHA1 algorithm
that is now in use in Fossil in place of SHA1.
--
D. Richard Hipp
d...@sqlite.org
___
stance.
hash-policy is suppose to be automatic for most users.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
created will use a SHA3 hash
and the whole repository will be inaccessible to older clients.
Adding a method to change the hash-policy later won't help that.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@l
On 3/9/17, Warren Young wrote:
> On Mar 9, 2017, at 2:54 PM, Richard Hipp wrote:
>>
>> On 3/9/17, Warren Young wrote:
>>> Our newbie may be setting up a repo that
>>> they know needs to be accessible to Fossil 1.x clients, and they can’t
>>> force
>
ult "auto" to immediately promote to "sha3".
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Fossil version 2.1 is now available from the download pages. Please
let me know if you find any problems.
The next check-in to the self-hosting Fossil repository will likely
use a SHA3 hash.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing
en next time you do a commit from that check-out, the repo will will
automatically start doing all new commits as SHA3. If you do not care
aboud SHA1 vs SHA3, then you can safely ignore the second step.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-us
until you
request otherwise.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ed the first time you push a new SHA3 commit.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ence is that Fossil
2.1 will read and write the latest repositories whereas Fossil 1.x
will not.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
hat is
more likely to survive an update? What are your scripts doing? Would
it be better to run SQL queries directly against the repository
database? Are new fixed-output-format commands needed in Fossil to
extract information that is important to scripts?
--
D. Richard Hipp
d...@sqlite.o
doing a rebuild, but
it is not strictly necessary.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
as High at the office for a while, until user gets back and
syncs, at which point the priority changes to "Medium".
If two edits append to the same field, then the text is appended in
timestamp order. This means remarks appended by user B while she was
in flight get intercolated
On 3/16/17, Richard Bukovansky wrote:
>> If two edits change the same field, the last edit wins.
>
> I see. Not exactly what I was expecting, but OK.
What were you expecting? Is there a better way?
--
D. Richard Hipp
d...@sqlite.org
___
/download.html) and get the
latest official release tarball, if you want to be more conservative.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
strategically, specially given, how the last
> presidential elections in the U.S. were won, is a really tall order :-/
>
> Anyways, Thank You for reading. That was just the background story
> that answers the question, how can something as primitive as
&
nks() logic should probably not apply to directories
> outside a checkout (such as /tmp).
>
I wonder if you could provide a more concrete example of the problem,
perhaps in a the form of a "fossil test-file-environment" command that
gives an in
> My employers don't acknowledge my existence much less my opinions.
> _______
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-u
144.217.165.151
2607:5300:201:3000::/64
Those servers are all hosed by OVH at https://www.ovh.com/us/ - to
whom I have written multiple time and who seem utterly unconcerned.
Be sure to say bad things about OVH on all your social media posts.
--
D. Richard Hipp
d...@sqlite.org
___
s especially impossible when using SHA3-256.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
a real terminal.
>2. "Paginates commands" setting is true.
>3. Executed command is indicated in "Commands to paginate" setting.
>
> *Fossil standard error must not be paginated.*
>
>
> Now I'm waiting for your advices/i
s? (See
https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki for the
documentation on how to create a server instance for Fossil.)
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
be able to set the policy to "auto" because
it will immediately and automatically flip to "sha3".
That is the way "auto" is designed to work.
How were you expecting it to work? How can the documentation be improved?
--
D. Richard Hipp
d...@sqlite.org
uesting a captcha. Do you have an
example that I have overlooked?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
e difficulty there is that when the older version of Fossil that is
running the "update" was written, we didn't know about version 2.1 and
so there wasn't any way for us to add an error message about needing
2.1. :-)
--
D. Richard Hipp
d...@sqlite.org
___
; Below that there are several lines of underscores and bars, I'm assuming
> this is an ascii-based captcha or some other method of obscurity, since I
> can't find any clear 8-digit hexadecimal sequence.
Correct. The CAPTCHA is an ascii-art rendering of the 8-digit hex key.
--
D. Ri
ing the diff. For diffing, the file is broken up
into individual lines, and every line is given a 32-bit hash that
helps to speed up locating the differences. The lower 13 bits of the
hash are the length of the line in bytes. The upper 19 bytes are the
actual hash.
--
D. Richard Hipp
d..
hange you would like to see? Perhaps by sending patch?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
t symbol
> correctly in a "converted" file.
>
> Is there any solution to this?
>
You could use the three-character ASCII sequence "(C)" instead of the
one-character © symbol. Or, you can simply spell out the word
"Copyright". I do the latter.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
o. Can you show us a test case?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
can run
fossil test-echo *
to see what the command-line gets expanded to by the shell. I haven't
(yet) found a variation on this that does not expand the *.
Anybody else?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
not change anything.
However, we have deliberately started using SHA3 artifacts on Fossil
itself, so at this point it is necessary to run Fossil 2.0 or later in
order to access the complete Fossil repository.
--
D. Richard Hipp
d...@sqlite.org
___
On 4/12/17, Stephen De Gabrielle wrote:
>
> did anyone come up with a solution to SSL on Mac problem?
Can you remind us what the "SSL on Mac" problem is?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-us
g on the Web site about submitting bugs,
> so
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
d...@sqlite.org
_
or -lcrt0.o
Are there any mac developers who can trouble-shoot this for me?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
urpose. You only
> need to statically link OpenSSL.
I've uploaded a new Mac build that statically links only OpenSSL.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:80
pdated in an attempt to remind me to do it the same way on the
next release.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
fossil-scm.org/fossil/artifact/da39a3ee5e6b4b0d
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
e to type "make" in order to build that
older version, but if the timestamps are some point in the past, then
that make will not work.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.
ric hosting provider. For $5/month you can get a
virtual machine that you can ssh into and set up. This does require
some admin skill, but not that much, especially with Linode which does
most of the hard work for you. Set up a webserver and create CGIs for
each Fossil repo that you want to host.
--
pt is also used to draw the timeline graph. There is no way
around that. Either you enable Javascript, or you do without the
timeline graph.
I wonder if you can be more specific about what your non-javascript
users are having problems with?
--
D. Richard Hipp
d...@sqlite.org
__
. But there are spiders that use UserAgent strings that
are copied from Firefox and Chrome.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
there will never be any links to the
honeypot. But, that will make the interface more annoying to the vast
majority of people who do in fact use javascript.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm
enabled, and the interface really is much nicer when you use
javascript. Really.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 5/3/17, The Tick wrote:
>
> the current code
> does not work when using mintty.
Have you tried the latest trunk version of Fossil?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm
On 5/3/17, The Tick wrote:
> On 5/3/2017 12:41 PM, Richard Hipp wrote:
>> On 5/3/17, The Tick wrote:
>>>
>>> the current code
>>> does not work when using mintty.
>>
>> Have you tried the latest trunk version of Fossil?
>>
>
> I used fo
current version of foo.js from the master fossil repo?
fossil uv sync
fossil uv export foo.js foo.js
OR: fossil uv cat foo.js >foo.js
>
> I'm sure it's easy, but the documentation does not give me guidance on this
> simple use-case.
&g
ult to infinity (and thus be turned off by default).
Would something like that work for you?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 5/10/17, sky5w...@gmail.com wrote:
> Cool,
> Does this behave identically if I have:
> http://localhost:8082/setup_settings
> [±] autosync //<-- ON or OFF?
>
Yes. Unversioned content does not autosync. You have to explicitly
runt "fossil uv sync".
--
D.
is.
I have just now checked in a change to moves the "revert" command off
of the "fossil help" menu, so that you now only see it when you do
"fossil help --all".
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
f you do an abort?
You are correct. I should make a policy of not commiting changes
before breakfast and/or coffee :-\
I moved my change into a hidden "mistake" branch.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-user
e the same as it was several
check-ins ago, better to do something like this:
fossil artifact $hash >$filename
In other words, look up the cryptographic hash for the version of the
file you want, then just overwrite the local copy with this historical
copy.
--
D. Richard Hipp
d...@sqlite.org
ository has not been updated.
>
> How to solve these problems?
>
> Olivier
> _______
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard
On 5/15/17, Roy Keene wrote:
> Maybe it should open /dev/null and /dev/urandom before chroot()'ing ?
That would be difficult to implement.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.
operations are read-only. So breaking them up into separate
transactions won't really help anything. Write operations (receiving
a push) are usually very quick.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
}
>
> Issue: code does not insure reading past end of z, due to calling code
> in '%...s' miscalculation of default value for N.
> Impact: intermittent app-crashes
> ___
> fossil-dev mailing list
> fossil-...@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
ro-terminated?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
101 - 200 of 3341 matches
Mail list logo
