Re: [fossil-users] rebuild scale-ability/data written/repo size ratio

[Warren Young]

On Oct 28, 2016, at 3:45 AM, Karel Gardas  wrote:
> 
> make it more scale-able and allow its real usage also for projects of
> bigger size.

How many projects are there bigger than SQLite, percentage-wise?

Has anyone done something like produce a SLOC histogram for all projects on 
GitHub or Sourceforge, so that we can say something like, “SQLite is in the top 
2nd percentile for open source C projects based on SLOCCount’s line counting 
algorithm”?

I’m intrigued enough to want to do the project, but I don’t think I really want 
to clone the entirety of GitHub onto my HDD in order to find out, even if it’s 
just one project at a time.  That sounds like a great way to blow through my 
Comcast data cap.

> Let's talk about some real numbers to illustrate the situation.

Yes, let’s. :)

> $ time /opt/fossil-head/bin/fossil clone
> http://netbsd.sonnenberger.org/ netbsd-src.fossil
> 
> It takes:
> 
> real323m2.323s
> user42m0.262s
> sys 13m18.003s

Okay, but compared to what?

If you compare to the checkout time from NetBSD’s main CVS repository, you 
aren’t comparing apples to oranges, since you’re transferring only the tip of 
the trunk.  You have to go back to the CVS server for any history.  I suspect 
if you checked out each CVS revision one at a time, it would take a lot longer 
than pulling the whole project history with Fossil.

If you want to compare with some other DVCS, post those numbers.

> rebuild alone
> takes around 250 minutes on the same hardware and with the same
> fossil.

Would a --skip-rebuild option for fossil clone solve your major problem, then?

Rebuilding is strictly optional.  It just makes Fossil operations run faster 
post-clone.

Also realize that cloning is a one-time activity per development machine, for 
anyone active enough in the project to maintain their local clone.

A cute option would be if --skip-rebuild would look for a local at(1) command, 
then offer to schedule the rebuild for a later time, after you’ve left off work 
for the day.

Although there may be casual clients who clone, do something with the source, 
throw the clone repo away when done, then clone again a year later when they 
need the source again, we should not optimize Fossil for that case.

We’ve already discussed shallow clones, which would make Fossil more like CVS 
in terms of clone size.  See the “Fossil 2.0” document Mr. Boogie linked to.

> - commit, this is a little bit harder. One file modified and commit takes:
> real4m0.765s
> user1m55.442s
> sys 1m11.892s

That seems like a much more important problem to solve.  4 minutes per commit 
is simply *painful*, and it may happen multiple times per day, rather than once 
per development box.

Here, I occasionally see commit times of 10 seconds or so, and that’s painful 
enough already.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] rebuild scale-ability/data written/repo size ratio

[Nikita Borodikhin]

Hi Karel,

I have quite a big repository (3.4G) imported from svn by a custom tool.
It also took several minutes to commit, and most of the time was spent in
md5 hash computation.  It is extra precaution to ensure checkout file
integrity, which can be turned off with repo-cksum setting.

With that setting off, it takes 4 to 6 second to commit.

My hardware is ext4 on Samsung 850 Pro 512 SSD, i7-3770

Nikita

On Fri, Oct 28, 2016, 10:03 Warren Young  wrote:

> On Oct 28, 2016, at 3:45 AM, Karel Gardas  wrote:
> >
> > make it more scale-able and allow its real usage also for projects of
> > bigger size.
>
> How many projects are there bigger than SQLite, percentage-wise?
>
> Has anyone done something like produce a SLOC histogram for all projects
> on GitHub or Sourceforge, so that we can say something like, “SQLite is in
> the top 2nd percentile for open source C projects based on SLOCCount’s line
> counting algorithm”?
>
> I’m intrigued enough to want to do the project, but I don’t think I really
> want to clone the entirety of GitHub onto my HDD in order to find out, even
> if it’s just one project at a time.  That sounds like a great way to blow
> through my Comcast data cap.
>
> > Let's talk about some real numbers to illustrate the situation.
>
> Yes, let’s. :)
>
> > $ time /opt/fossil-head/bin/fossil clone
> > http://netbsd.sonnenberger.org/ netbsd-src.fossil
> >
> > It takes:
> >
> > real323m2.323s
> > user42m0.262s
> > sys 13m18.003s
>
> Okay, but compared to what?
>
> If you compare to the checkout time from NetBSD’s main CVS repository, you
> aren’t comparing apples to oranges, since you’re transferring only the tip
> of the trunk.  You have to go back to the CVS server for any history.  I
> suspect if you checked out each CVS revision one at a time, it would take a
> lot longer than pulling the whole project history with Fossil.
>
> If you want to compare with some other DVCS, post those numbers.
>
> > rebuild alone
> > takes around 250 minutes on the same hardware and with the same
> > fossil.
>
> Would a --skip-rebuild option for fossil clone solve your major problem,
> then?
>
> Rebuilding is strictly optional.  It just makes Fossil operations run
> faster post-clone.
>
> Also realize that cloning is a one-time activity per development machine,
> for anyone active enough in the project to maintain their local clone.
>
> A cute option would be if --skip-rebuild would look for a local at(1)
> command, then offer to schedule the rebuild for a later time, after you’ve
> left off work for the day.
>
> Although there may be casual clients who clone, do something with the
> source, throw the clone repo away when done, then clone again a year later
> when they need the source again, we should not optimize Fossil for that
> case.
>
> We’ve already discussed shallow clones, which would make Fossil more like
> CVS in terms of clone size.  See the “Fossil 2.0” document Mr. Boogie
> linked to.
>
> > - commit, this is a little bit harder. One file modified and commit
> takes:
> > real4m0.765s
> > user1m55.442s
> > sys 1m11.892s
>
> That seems like a much more important problem to solve.  4 minutes per
> commit is simply *painful*, and it may happen multiple times per day,
> rather than once per development box.
>
> Here, I occasionally see commit times of 10 seconds or so, and that’s
> painful enough already.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] rebuild scale-ability/data written/repo size ratio

[jungle Boogie]

On 28 October 2016 at 02:45, Karel Gardas  wrote:
> I'm just curious if there are people here tinkering with the idea to
> make it more scale-able and allow its real usage also for projects of
> bigger size.


There has been this discussion. I have an email with the subject of
"Fossil 2.1: Scaling" from March 2015. the
http://www.mail-archive.com/ doesn't go back that far, though.


AH, just found it on marc:
http://marc.info/?l=fossil-users=144565850643439=2

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Directory symlinks...

[Steven Gawroriski]

On Fri, 30 Sep 2016 21:25:01 -0700
"Joe Mistachkin"  wrote:

> 
> Warren Young wrote:
> >
> > Well, that's a tricky one, innit?  Fossil manages files, not
> > directories, but Fossil's view of symlinks is file-like.  So is it
> > an apple or an orange?
> >
>  
> I've checked in a fix on the dirSymlinks branch that appears to
> completely fix the issue I personally encountered.
> 
> I would appreciate wider testing of it.
> 

A bit late, but if I symlink a directory and then attempt to add it
then Fossil appears to want to add all of the files that are contained
in the specified directory. So to prevent this I symlink a normal file
then just overwrite the symlink with what I really want it to point to
(the directory).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Directory symlinks...

[Warren Young]

On Oct 28, 2016, at 3:29 PM, Steven Gawroriski  
wrote:
> 
> On Fri, 30 Sep 2016 21:25:01 -0700
> "Joe Mistachkin"  wrote:
> 
>> I've checked in a fix on the dirSymlinks branch that appears to
>> completely fix the issue I personally encountered.
>> 
>> I would appreciate wider testing of it.
> 
> A bit late, but if I symlink a directory and then attempt to add it
> then Fossil appears to want to add all of the files that are contained
> in the specified directory. So to prevent this I symlink a normal file
> then just overwrite the symlink with what I really want it to point to
> (the directory).

Actually, I don’t see that it supports adding the symlink itself.  Test case:

mkdir x
cd x
f new ../x.fossil
f open ../x.fossil 
mkdir foo
ln -s foo bar
f add bar
f ci

It complains, "nothing has changed; use --allow-empty to override”

This is with the 1.36 release version:

  This is fossil version 1.36 [c24373934d] 2016-10-24 14:59:33 UTC

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] OT: Facebook engineers preferring hg to Git

[Nathaniel Reindl]

On Oct 28, 2016, at 07:33, Richard Hipp  wrote:
> 
> Perhaps true.  But in my brief look at Rust I observed that you really
> cannot use it effectively without also having to use Git.  The two
> seem closely linked.  Is that incorrect?

It is indeed. Sadly, the examples don't help to dispel that at all.

Git is merely a first-class citizen for some of the tooling (like Cargo[0]), 
and if you dig deeply enough, you'll notice things like `--hg` flags and 
explicit mentions in, e.g., Cargo.toml of the version control system being used 
to pull in dependencies for those who choose to have that tool manage their 
checkouts for them. (Though, in my experience, some of the features are a 
little schizophrenic in their raisons d'être, and the proliferation of 
language-specific package managers is proving to be an acquired taste like IPAs 
or caviar. YMMV.)

However, there's also the option of referring to dependencies in Cargo by a 
file path on the local filesystem tree, relative to where that particular 
crate's (the Rustese word for package) Cargo.toml resides. There's more at [1].

If you're willing to roll your own crate by hand, you can even use something 
like Darcs, as the thrussh portable SSH library[2] does. The only other 
consequence outside of that is that you lose some of the ability for Cargo to 
manage your dependencies for you if you choose to rely on one that doesn't use 
Git and wish to use something other than a published stable version.

Given Cargo's opinions about version numbers[3] though, I don't think that's 
such a bad consequence. —n

0: http://crates.io/
1: http://doc.crates.io/specifying-dependencies.html
2: https://pijul.org/thrussh/
3: http://doc.crates.io/manifest.html#the-version-field
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

On Fri, Oct 28, 2016 at 3:42 AM, K. Fossil user
 wrote:
> Hi,
>
>> «  »
>
> I don't click in any links that are not known...

Right approach!
After all, all computer people have never heard about Bike
Shed...especially those tied to FreeBSD...
You have to learn a lot of stuff.



> a) I've never said that I will provide info about me or people I do know.

Let's call it "scientific approach".

> b) People who are aware about security knows what I am talking about.

Let's call it "religion".

> e) The aim of this thread -mine- is to give info, nothing else.

Let's call it "information without  evidence".

> When an expert says that you should not use inetd/xinetd whatever it is,
> there are no questions about which release it is or which OS.

Don't use chainsaw, they can hurt you.
It does not matter which model or the context.

> Generally speaking if somebody say don't use this software, and I do trust
> him, I won't try to use it, which release, OS and so on it is about.

Trust is the point you are missing so far: you trust such friend, how
can we trust him too? Why don't cc he so he can provide information
you are clearly not aware of?

> I am sorry but my computer send html : I only use WebMail ...
> Most people do use Gmail ...

I do use gmail, I do not send html, just as an example...


> If someone should choose between Git and Fossil, give me evidence that they
> would use Fossil in a long term run if you can ...
> The learning curve is high enough so people will choose ONE of them not
> both.
> e.g. Git and mercurial are the same for some people, but I don't even have
> the time to try Mercurial, so why would people try Fossil ?
> c) Fossil is not the same as Git in many areas. Git is not used as a
> webserver, it is not a single file, etc.

I must be a really strange guy: I do use fossil in production at work
and git for personal projects. While I cannot document my work here,
except thru the mailing list archive, you can search for me on github.
But, as I already stated, if you are not using fossil, not planning to
use fossil, not happy with fossil, what the hell are you posting on
the fossil mailing list?



> Seriously ?
> What did I say in the previous talk : you don't know what you are talking
> about.

No, I do.
You should go trolling somewhere else.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] rebuild scale-ability/data written/repo size ratio

[Karel Gardas]

Hello,

first of all, I know that Fossil was written with the idea of serving
SQLite project and projects of similar size well and that it does
great job in this task.

I'm just curious if there are people here tinkering with the idea to
make it more scale-able and allow its real usage also for projects of
bigger size.

Now, when git -> fossil (incremental) mirror functionality seems to be
working this may be even more interesting or tempting IMHO.

Let's talk about some real numbers to illustrate the situation. Let's
clone NetBSD src tree kindly provided by Jörg Sonnenberger by
following command:

$ time /opt/fossil-head/bin/fossil clone
http://netbsd.sonnenberger.org/ netbsd-src.fossil

It takes:

real323m2.323s
user42m0.262s
sys 13m18.003s

on my E5-2620 Sandy Bridge workstation. Of course part of this time is
spent perhaps on not so efficient network data send/receive, but
majority of time at least as observed from the output of the command
is spend on DB rebuild. I know that from the example of OpenBSD src
tree which is comparable in size with NetBSD and where rebuild alone
takes around 250 minutes on the same hardware and with the same
fossil.

So this is about time spent on rebuilt. What may be even more
important is how much data rebuild is going to write. Here I do not
have exact or perfectly exact numbers, but this is on my workstation
so I see what's going on by keeping drive meters on my eyes so let's
assume I'm not that off claiming that rebuild was writing data on
speed ~40 MB/s for 2 or even more hours. In sum this may be around 300
GBs of data written on this rebuild (rounded up). This is for
repository which final file size is:

$ ls -lha netbsd-src.fossil
-rw-r--r--   1 karelkarel   2.6G Oct 28 01:11 netbsd-src.fossil

and which results in the source tree of size of 2.7 GB.

Now just to show that this rebuild may be the biggest scalability
obstacle I'd like to compare with open/status/diff/commit operations:

- open: results in 2.7GB of data written to disk in the resulting
NetBSD source tree. It takes:
real4m38.843s
user1m44.221s
sys 1m58.553s

IMHO very nice result for the source tree of this size

- status/diff -- one random file modified: both runs for 4-5 seconds.
Also very nice results for the source tree of this size

- commit, this is a little bit harder. One file modified and commit takes:
real4m0.765s
user1m55.442s
sys 1m11.892s

IMHO not so nice, but still kind of acceptable even for development on
this source tree size. But certainly commit may be another target for
speedup hacking.

So that's it. Fossil used in those tests is:

This is fossil version 1.37 [0fa60142eb] 2016-10-26 21:45:52 UTC

and the tests were performed on ZFS mirror of two SSDs (1TB Crucial
MX200 and 1TB Samsung 850 Evo) on Solaris 11.2 running on E5-2620 with
32GB RAM -- if anybody is interested in this info for numbers
verification.

Cheers,
Karel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd

[Nathaniel Reindl]

> On Oct 28, 2016, at 02:29, Luca Ferrari  wrote:
> No, I do.
> You should go trolling somewhere else.

Just checking in. It seems that my decision to mute this thread within my 
mailer immediately after my single response was a good idea.

From my perspective, this thread has far outlasted its usefulness and has 
become an exercise in self-satisfaction for those who prefer to write words 
instead of writing code. Can we perhaps refrain from offering 
attention-addicted individuals the attention they so desperately crave?

I promise you'll look back fondly on this decision just as I have. —n
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] OT: Facebook engineers preferring hg to Git

[Karel Gardas]

On Fri, Oct 28, 2016 at 1:33 PM, Richard Hipp  wrote:
> On 10/27/16, David Mason  wrote:
>>
>> However, the value of Rust is not simply memory management.  The
>> *considerably* more expressive type system, and the much more robust type
>> checking can reduce LOC while improving both readability and safety.
>
> Perhaps true.  But in my brief look at Rust I observed that you really
> cannot use it effectively without also having to use Git.  The two
> seem closely linked.  Is that incorrect?

Rust is under heavy development and more importantly is quite new kid
on the block so OS distros usually have not picked it yet. i.e. no
packages in Ubuntu nor Debian but for example in OpenBSD you may be
lucky with "pkg_add rust" already. So please be patient and give
it/them a time. Honestly I think rust is quite nice and I'm glad that
such thing happen well yet I find Haskell even nicer.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] OT: Facebook engineers preferring hg to Git

[Richard Hipp]

On 10/27/16, David Mason  wrote:
>
> However, the value of Rust is not simply memory management.  The
> *considerably* more expressive type system, and the much more robust type
> checking can reduce LOC while improving both readability and safety.

Perhaps true.  But in my brief look at Rust I observed that you really
cannot use it effectively without also having to use Git.  The two
seem closely linked.  Is that incorrect?

-- 
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-users] sites inaccessible

[jungle Boogie]

Hi Dr. Hipp,

Probably a low concern for you at 1:30am your time but I can't connect
to fossil-scm.org or sqlite.org over port 80.

$ curl http://sqlite.org/
curl: (7) Failed to connect to sqlite.org port 80: Connection refused

$ curl http://fossil-scm.org
curl: (7) Failed to connect to fossil-scm.org port 80: Connection refused


https does work:
$ curl https://www.fossil-scm.org

Redirect to Location:
https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki




$ curl https://www.sqlite.org
http://www.w3.org/TR/html4/strict.dtd;>




SQLite Home Page





-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] export.c fail with MSVC

[jungle Boogie]

Hi All,

In my adventure to build fossil on windows with MSVC 2010, I
encountered the error below:

cl /c /nologo /MT /O2  /I. /I..\src /I..\win\include
/I..\compat\zlib /Fo.\export.obj -c export_.c
export_.c
..\src\export.c(564) : error C2143: syntax error : missing ';' before 'const'
..\src\export.c(566) : error C2065: 'zPerm' : undeclared identifier
..\src\export.c(566) : warning C4047: '=' : 'int' differs in levels of
indirection from 'char [7]'
..\src\export.c(567) : error C2065: 'zPerm' : undeclared identifier
..\src\export.c(567) : warning C4047: '=' : 'int' differs in levels of
indirection from 'char [7]'
..\src\export.c(568) : error C2065: 'zPerm' : undeclared identifier
..\src\export.c(568) : warning C4047: '=' : 'int' differs in levels of
indirection from 'char [7]'
..\src\export.c(570) : error C2065: 'zPerm' : undeclared identifier
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.


Is it this commit with the problem?
https://www.fossil-scm.org/index.html/fdiff?sbs=1=22d375733c9bb76a=e3f73d427eee82c9

Thanks,
sean

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] export.c fail with MSVC

[jungle Boogie]

On 28 October 2016 at 15:50, Martin Gagnon  wrote:
> On Fri, Oct 28, 2016 at 03:18:04PM -0700, jungle Boogie wrote:
>> Hi All,
>>
>> In my adventure to build fossil on windows with MSVC 2010, I
>> encountered the error below:
>>
>> cl /c /nologo /MT /O2  /I. /I..\src /I..\win\include
>> /I..\compat\zlib /Fo.\export.obj -c export_.c
>> export_.c
>> ..\src\export.c(564) : error C2143: syntax error : missing ';' before 'const'
>> ..\src\export.c(566) : error C2065: 'zPerm' : undeclared identifier
>> ..\src\export.c(566) : warning C4047: '=' : 'int' differs in levels of
>> indirection from 'char [7]'
>> ..\src\export.c(567) : error C2065: 'zPerm' : undeclared identifier
>> ..\src\export.c(567) : warning C4047: '=' : 'int' differs in levels of
>> indirection from 'char [7]'
>> ..\src\export.c(568) : error C2065: 'zPerm' : undeclared identifier
>> ..\src\export.c(568) : warning C4047: '=' : 'int' differs in levels of
>> indirection from 'char [7]'
>> ..\src\export.c(570) : error C2065: 'zPerm' : undeclared identifier
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio 10.0\VC\BIN\cl.EXE"' : return code '0x2'
>> Stop.
>>
>
> Should be fix now. (even 2 time since me and mistachkin commit the same
> fix in the exact same time.)
>
>   ** The Fork is probably my fault, my autosync was set to "pullonly"
>  and I had to push manually after my commit..

you fixed it!

This is fossil version 1.37 [cf2adc71e8] 2016-10-28 22:51:59 UTC
Compiled on Oct 28 2016 15:53:28 using msc-16.00 (32-bit)
SQLite 3.15.0 2016-10-14 10:20:30 707875582f
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
UNICODE_COMMAND_LINE
STATIC_BUILD


thank you!

>
> Regards
>
> --
> Martin G.


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why we should NEVER use inetd/xinetd

[K. Fossil user]

Hi,
(Some blatant talks from luca tend me to say this) :
Did I say that  I do use a FreeBSD computer ? No I did not. It does NOT mean 
that I do not use a NIX OS freeBSD included :-). [1]


> « It does not matter which model or the context. »

Ask your computer scientist, because You dare to say that I am wrong.Give to 
use his point of view. CC him so you could say that you are coherent.
> « you trust such friend, how can we trust him too? Why don't cc he so he can 
> provide information you are clearly not aware if? »

a) I've responded to that. b) Don't you trust your computer scientist ? Ask 
him... (read just above)
My job is done, do yours...c) CC : I've answered that, too...

> « I do use gmail, I do not send html, just as an example... »

I do use Gmail, Outlook, etc.A webmail send HTML. A MUA could be configured not 
to send HTML. I am not going to change the behavior of my WebMail just for you, 
when most people in real life do prefer HTML.

> « I must be a really strange guy: I do use fossil in production at work and 
> git for personal projects. »

aha : Now I do understand. I was a bit astonished when I do read some stupid 
stuffs but now I am happy:Your are not the nice guy some people expect.Very few 
people do use Fossil especially in production use.So if a guy send so nasty 
vibes inside a mailing list especially a guy who work in his job part time with 
a software (Say Fossil), I know that people would never want to use it (say 
Fossil).

But now because your are so clever (not in my point of view) why don't you 
convince FreeBSD and OpenBSD to use Fossil ?For example, tell OpenBSD that they 
should not use Git, which is a Linux DVCS.And of course because you do know 
better than most of us about it, do CC us so we can follow your steps.(May be 
we will learn something about an new approach to convince people to use Fossil)
> « But, as I already stated, if you are not using fossil, not planning to use 
> fossil, not happy with fossil, what the hell are you posting on the fossil 
> mailing list? »

a) Who said that I don't plan to use Fossil ?b) This is evidence that you don't 
read whatever I've said, especially the other day when I've written something 
about inetd.c) My subject is Fossil related, yours is not.d) What I've done/I 
do/I will do is none of your business !

Go play somewhere else.
Oh I forgot : a guy who seems to convince me that he is aware about NIX is not 
bothered by any html stuffs.(Regular expressions could be used if necessary)
Why do you use Github ? Are you afraid of not to be seen ? I do use Github and 
something else... (Git only)
Don't you know that there are some website that host Fossil ? I do ...

I am quite sure that people who do want to use Fossil, newbies, would like so 
much the way how a Fossil user, I mean YOU, think ! (Luca has Fossil in 
production ! Wow !)
Well played. (I could not imagine the impact of what you've done)

 
Best Regards

K.

 [1] For the record :

4. What Is A "Bikeshed"?
NOT bikeshed.org.

  De : Luca Ferrari 
 À : Fossil SCM user's discussion  
 Envoyé le : Vendredi 28 octobre 2016 6h29
 Objet : Re: [fossil-users] Why we should NEVER use inetd/xinetd
   
On Fri, Oct 28, 2016 at 3:42 AM, K. Fossil user
 wrote:
> Hi,
>
>> «  »
>
> I don't click in any links that are not known...

Right approach!
After all, all computer people have never heard about Bike
Shed...especially those tied to FreeBSD...
You have to learn a lot of stuff.



> a) I've never said that I will provide info about me or people I do know.

Let's call it "scientific approach".

> b) People who are aware about security knows what I am talking about.

Let's call it "religion".

> e) The aim of this thread -mine- is to give info, nothing else.

Let's call it "information without  evidence".

> When an expert says that you should not use inetd/xinetd whatever it is,
> there are no questions about which release it is or which OS.

Don't use chainsaw, they can hurt you.
It does not matter which model or the context.

> Generally speaking if somebody say don't use this software, and I do trust
> him, I won't try to use it, which release, OS and so on it is about.

Trust is the point you are missing so far: you trust such friend, how
can we trust him too? Why don't cc he so he can provide information
you are clearly not aware if?

> I am sorry but my computer send html : I only use WebMail ...
> Most people do use Gmail ...

I do use gmail, I do not send html, just as an example...


> If someone should choose between Git and Fossil, give me evidence that they
> would use Fossil in a long term run if you can ...
> The learning curve is high enough so people will choose ONE of them not
> both.
> e.g. Git and mercurial are the same for some people, but I don't even have
> the time to try Mercurial, so why would people try Fossil ?
> c) Fossil is not the same 

[fossil-users] Version 1.34 (2016-11-02) ?

[K. Fossil user]

Hi,
Fossil: Download Page
http://www.fossil-scm.org/index.html/uv/download.html
« Version 1.34 (2016-11-02) »

I was looking for the 1.34 release date when I do read this « Version 1.34 
(2016-11-02) »...
I didn't know that Fossil 1.34 is next week ... :-?

I was told that next release should be 1.36 ...  
Best Regards

K.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] export.c fail with MSVC

[Martin Gagnon]

On Fri, Oct 28, 2016 at 03:18:04PM -0700, jungle Boogie wrote:
> Hi All,
> 
> In my adventure to build fossil on windows with MSVC 2010, I
> encountered the error below:
> 
> cl /c /nologo /MT /O2  /I. /I..\src /I..\win\include
> /I..\compat\zlib /Fo.\export.obj -c export_.c
> export_.c
> ..\src\export.c(564) : error C2143: syntax error : missing ';' before 'const'
> ..\src\export.c(566) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(566) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(567) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(567) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(568) : error C2065: 'zPerm' : undeclared identifier
> ..\src\export.c(568) : warning C4047: '=' : 'int' differs in levels of
> indirection from 'char [7]'
> ..\src\export.c(570) : error C2065: 'zPerm' : undeclared identifier
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 10.0\VC\BIN\cl.EXE"' : return code '0x2'
> Stop.
> 

Should be fix now. (even 2 time since me and mistachkin commit the same
fix in the exact same time.) 

  ** The Fork is probably my fault, my autosync was set to "pullonly"
 and I had to push manually after my commit..

Regards

-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Facebook engineers preferring hg to Git

[K. Fossil user]

Hi,
You've got interesting points here. Like it ! :-)

I've never heard that Rust must use Git.Of course if you do use cargo, you 
should think about a DVCS but that does not mean that you could not use Fossil 
or something else.Just play with your own IDE and this should suffice.
IMHO people could code without cargo a rust project. However, for those who try 
to use it, it [cargo] is really helpful so I don't think that something would 
change even if I found it a bit strange if ONLY git could be used.I think in 
the Cargo.toml file you could change a part of the configuration to use 
Mercurial at least. I dunno.

 Best Regards

K.

  De : Nathaniel Reindl 
 À : Fossil SCM user's discussion  
 Envoyé le : Vendredi 28 octobre 2016 13h07
 Objet : Re: [fossil-users] OT: Facebook engineers preferring hg to Git
   
On Oct 28, 2016, at 07:33, Richard Hipp  wrote:
> 
> Perhaps true.  But in my brief look at Rust I observed that you really
> cannot use it effectively without also having to use Git.  The two
> seem closely linked.  Is that incorrect?

It is indeed. Sadly, the examples don't help to dispel that at all.

Git is merely a first-class citizen for some of the tooling (like Cargo[0]), 
and if you dig deeply enough, you'll notice things like `--hg` flags and 
explicit mentions in, e.g., Cargo.toml of the version control system being used 
to pull in dependencies for those who choose to have that tool manage their 
checkouts for them. (Though, in my experience, some of the features are a 
little schizophrenic in their raisons d'être, and the proliferation of 
language-specific package managers is proving to be an acquired taste like IPAs 
or caviar. YMMV.)

However, there's also the option of referring to dependencies in Cargo by a 
file path on the local filesystem tree, relative to where that particular 
crate's (the Rustese word for package) Cargo.toml resides. There's more at [1].

If you're willing to roll your own crate by hand, you can even use something 
like Darcs, as the thrussh portable SSH library[2] does. The only other 
consequence outside of that is that you lose some of the ability for Cargo to 
manage your dependencies for you if you choose to rely on one that doesn't use 
Git and wish to use something other than a published stable version.

Given Cargo's opinions about version numbers[3] though, I don't think that's 
such a bad consequence. —n

0: http://crates.io/
1: http://doc.crates.io/specifying-dependencies.html
2: https://pijul.org/thrussh/
3: http://doc.crates.io/manifest.html#the-version-field
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd

[Richie Adler]

Nathaniel Reindl decía, en el mensaje "Re: [fossil-users] OT: Why we should
NEVER use inetd/xinetd" del 28/10/2016 08:23:28:

> From my perspective, this thread has far outlasted its usefulness and has
> become an exercise in self-satisfaction for those who prefer to write words
> instead of writing code. Can we perhaps refrain from offering
> attention-addicted individuals the attention they so desperately crave?

Apparently I did something like that previously; the OP is in my blocklist. I
would encourage others to do the same.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil check-in [a4bb89ba081e29c5]...

[Richard Hipp]

"fossil clean -x" works better than "make clean" or "make distclean".
It seems to clear the problem.

On 10/27/16, Andy Bradford  wrote:
> Thus said "Andy Bradford" on 27 Oct 2016 21:42:34 -0600:
>
>> I always run  ``make distclean'' not ``make distclean''  but since you
>> suggest it, here's the difference on my system:
>
> Minor correction, I always run ``make clean'' not ``make distclean''
>
> At any rate, this happens on a  system that supports FuseFS (at least on
> my system) because FOSSIL_HAVE_FUSEFS  gets defined in autoconfig.h, but
> if there is  an #ifdef surrounding the option to  include "config.h" inf
> fusefs.c, then  autoconfig.h will  never get  sourced, and  neither will
> FOSSIL_HAVE_FUSEFS  when fusefs.c  is built.  So other  parts of  Fossil
> think that the  command is enabled, but fusefs.c itself  does not, so it
> doesn't get built. Hence the linker error.
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40005812cb7e
>
>
> ___
> 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users