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

[Andy Bradford]

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

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

[Andy Bradford]

Thus said "Joe Mistachkin" on Thu, 27 Oct 2016 17:22:26 -0700:

> I was  unable to reproduce the  stated linker error even  without this
> change.  Given  that the  generated  header  files  all seem  to  wrap
> references  to "fusefs_cmd"  in  #if  blocks, I'm  not  sure how  it's
> possible unless  maybe the linker  error was caused by  something like
> not using "make distclean"...?

I always  run ``make  distclean'' not ``make  distclean'' but  since you
suggest it, here's the difference on my system:

$ fossil info | grep checkout   
checkout: a1b0ec8e3953a248abdf2bac42bc8999ab48e4d2 2016-10-26 23:33:03 UTC
$ make clean; ./configure ; nice make -j2
rm -rf bld/* fossil
Host System...i386-unknown-openbsd5.8
Build System...i386-unknown-openbsd5.8
...
Checking libs for fuse_mount...-lfuse
FuseFS support enabled
Created Makefile from Makefile.in
autoconfig.h is unchanged
...
cc -o fossil bld/add.o  bld/allrepo.o  bld/attach.o  bld/bag.o  bld/bisect.o  
bld/blob.o  bld/branch.o  bld/browse.o  bld/builtin.o  bld/bundle.o  
bld/cache.o  bld/captcha.o  bld/cgi.o  bld/checkin.o  bld/checkout.o  
bld/clearsign.o  bld/clone.o  bld/comformat.o  bld/configure.o  bld/content.o  
bld/db.o  bld/delta.o  bld/deltacmd.o  bld/descendants.o  bld/diff.o  
bld/diffcmd.o  bld/dispatch.o  bld/doc.o  bld/encode.o  bld/event.o  
bld/export.o  bld/file.o  bld/finfo.o  bld/foci.o  bld/fshell.o  bld/fusefs.o  
bld/glob.o  bld/graph.o  bld/gzip.o  bld/http.o  bld/http_socket.o  
bld/http_ssl.o  bld/http_transport.o  bld/import.o  bld/info.o  bld/json.o  
bld/json_artifact.o  bld/json_branch.o  bld/json_config.o  bld/json_diff.o  
bld/json_dir.o  bld/json_finfo.o  bld/json_login.o  bld/json_query.o  
bld/json_report.o  bld/json_status.o  bld/json_tag.o  bld/json_timeline.o  
bld/json_user.o  bld/json_wiki.o  bld/leaf.o  bld/loadctrl.o  bld/login.o  
bld/lookslike.o  bld/main.o  bld/manifest.o  bld/markdown.o  
bld/markdown_html.o  bld/md5.o  bld/merge.o  bld/merge3.o  bld/moderate.o  
bld/name.o  bld/path.o  bld/piechart.o  bld/pivot.o  bld/popen.o  bld/pqueue.o  
bld/printf.o  bld/publish.o  bld/purge.o  bld/rebuild.o  bld/regexp.o  
bld/report.o  bld/rss.o  bld/schema.o  bld/search.o  bld/setup.o  bld/sha1.o  
bld/shun.o  bld/sitemap.o  bld/skins.o  bld/sqlcmd.o  bld/stash.o  bld/stat.o  
bld/statrep.o  bld/style.o  bld/sync.o  bld/tag.o  bld/tar.o  bld/th_main.o  
bld/timeline.o  bld/tkt.o  bld/tktsetup.o  bld/undo.o  bld/unicode.o  
bld/unversioned.o  bld/update.o  bld/url.o  bld/user.o  bld/utf8.o  bld/util.o  
bld/verify.o  bld/vfile.o  bld/wiki.o  bld/wikiformat.o  bld/winfile.o  
bld/winhttp.o  bld/wysiwyg.o  bld/xfer.o  bld/xfersetup.o  bld/zip.o 
bld/sqlite3.obld/linenoise.o  bld/shell.o  bld/th.o  bld/th_lang.o  
bld/th_tcl.o  bld/cson_amalgamation.o -lssl -lcrypto -lz -lm -lfuse
bld/dispatch.o:(.data.rel.ro+0xb44): undefined reference to `fusefs_cmd'
collect2: ld returned 1 exit status
*** Error 1 in /home/amb/download/tarballs/fossil (./src/main.mk:582 'fossil')
$ 

And here it is with distclean:

$ make distclean; ./configure ; nice make -j2 
rm -rf bld/* fossil
rm -f autoconfig.h config.log Makefile
Host System...i386-unknown-openbsd5.8
Build System...i386-unknown-openbsd5.8
...
Checking libs for fuse_mount...-lfuse
FuseFS support enabled
Created Makefile from Makefile.in
Created autoconfig.h
...
cc -o fossil bld/add.o  bld/allrepo.o  bld/attach.o  bld/bag.o  bld/bisect.o  
bld/blob.o  bld/branch.o  bld/browse.o  bld/builtin.o  bld/bundle.o  
bld/cache.o  bld/captcha.o  bld/cgi.o  bld/checkin.o  bld/checkout.o  
bld/clearsign.o  bld/clone.o  bld/comformat.o  bld/configure.o  bld/content.o  
bld/db.o  bld/delta.o  bld/deltacmd.o  bld/descendants.o  bld/diff.o  
bld/diffcmd.o  bld/dispatch.o  bld/doc.o  bld/encode.o  bld/event.o  
bld/export.o  bld/file.o  bld/finfo.o  bld/foci.o  bld/fshell.o  bld/fusefs.o  
bld/glob.o  bld/graph.o  bld/gzip.o  bld/http.o  bld/http_socket.o  
bld/http_ssl.o  bld/http_transport.o  bld/import.o  bld/info.o  bld/json.o  
bld/json_artifact.o  bld/json_branch.o  bld/json_config.o  bld/json_diff.o  
bld/json_dir.o  bld/json_finfo.o  bld/json_login.o  bld/json_query.o  
bld/json_report.o  bld/json_status.o  bld/json_tag.o  bld/json_timeline.o  
bld/json_user.o  bld/json_wiki.o  bld/leaf.o  bld/loadctrl.o  bld/login.o  
bld/lookslike.o  bld/main.o  bld/manifest.o  bld/markdown.o  
bld/markdown_html.o  bld/md5.o  bld/merge.o  bld/merge3.o  bld/moderate.o  
bld/name.o  bld/path.o  bld/piechart.o  bld/pivot.o  bld/popen.o  bld/pqueue.o  
bld/printf.o  bld/publish.o  bld/purge.o  bld/rebuild.o  bld/regexp.o  
bld/report.o  bld/rss.o  bld/schema.o  bld/search.o  bld/setup.o  bld/sha1.o  
bld/shun.o  bld/sitemap.o  bld/skins.o  bld/sqlcmd.o  bld/stash.o  bld/stat.o  
bld/statrep.o  bld/style.o  bld/sync.o  bld/tag.o  bld/tar.o  bld/th_main.o  
bld/timeline.o  bld/tkt.o  bld/tktsetup.o  bld/undo.o  bld/unicode.o  
bld/unversioned.o  bld/update.o  bld/url.o  bld/user.o  

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

[K. Fossil user]

Hi,

Below are answered I give to few people (Richard, etc.) who talk about this 
topic.
> « Irony: Isn't Rust heavily dependent upon Git for its package management? So 
> if Hg is written in Rust, does that mean that Hg has a dependency on Git? »

Rust is a language, Git is a DVCS.
You can use Rust with Fossil if you want ...

C is language written for a more robust UNIX : should people stop using it 
because they are with Windows ?Git was basically written for Linux, should 
OpenBSD avoid it ?

> « Many people do believe that just because an application is written in Rust 
> rather than in C that it must be "safer". But it is a logical fallacy. »

Rust is too recent : you could not tell that, as if it is a rule or a correct 
theory.
There are no evidence for that, and you know that.

> « I kind of agree that rewriting fossil in Rust will not buy much »

That is my point of view too, but I would like to see people writing a Fossil 
software with ONLY Rust as a language : I am curious. :-)

> « Are you really happy with the idea of Fossil making zero forward progress 
> for two years, and at the end, you have exactly the same feature set as 
> before? »

Depending on the goal. No ?
Three possible goals...
a) You want to use Rust to reahc some new developpers, it could be a good idea.
b) You would like to improve safety at least to give evidence that Rust does 
NOT give any advantage.
c) You would try an object approach...

etc.

> « 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. »
In theory Rust is far better than C. It has a functional approach which is a 
good idea, immutability is a good idea, concurrency is in mind, etc.
However, I don't see anything that would convince me to use Rust for Fossil.
Concurrency improvement could be a good reason, however may I suggest that the 
Fossil team would wait so some "fallacies" could be seen if it is the case...


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

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

[Joe Mistachkin]

I was unable to reproduce the stated linker error even without this change.
Given
that the generated header files all seem to wrap references to "fusefs_cmd"
in #if
blocks, I'm not sure how it's possible unless maybe the linker error was
caused by
something like not using "make distclean"...?

--
Joe Mistachkin @ https://urn.to/r/mistachkin

___
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

[David Mason]

Richard and Warren both make very legitimate comments.  I wasn't seriously
suggesting that work should stop moving Fossil forward for the perhaps
marginal benefit of conversion to Rust.

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.

../Dave
___
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 plugin for QtCreator IDE

[Artur Shepilko]

Great! Will be happy to know your experience with it.

Which version of QtCreator are you using? Which OS?
If you want to add Fossil plugin to your current QtCreator instance, it has
to be binary compatible. So make sure you build it with the same QtCreator
version sources and same compiler version (see menu Help>About Qt
Creator...) esp. so under Windows. Also it has to use the same or
compatible Qt version.

Building the QtCreator from sources is quite straightforward (takes about
40min on 1.7GHz i5 dual-core), provided all dependencies are in place.
I understand you're already familiar with QtCreator, so just load the
qtcreator.pro project file. We also described the build settings in the
README.

To build from the command-line (with target Qt environment set up):

  mkdir build-qtcreator
  cd build-qtcreator
  qmake -r /path-to-qt-creator-source/qtcreator.pro
  make

Running the freshly built qtcreator from command-line:

  bin/qtcreator -settingspath ./settings


BTW, internally we indeed use Fossil as our main repo for this plugin
project :)


On Thu, Oct 27, 2016 at 11:08 AM, Aldo Nicolas Bruno  wrote:

> Nice stuff!
> Wondering why you didn't manage it as a fossil repository? :)
> Il'll try this asap. I'm using qtcreator for a couple of projects at
> job... (currently with git). I need to find some time to download/compile
> qtcreator sources
> Thanks
> Aldo
>
>
> On 27/10/2016 00:08, Artur Shepilko wrote:
>
> A quick follow-up. A few folks asked if the Fossil plugin for Qt Creator
> supports "Commit" action -- it does support commit.
> I missed to list it in my original email, sorry for the confusion.
> This is actually mentioned on the project page:
> https://github.com/nomadbyte/qtcreator-plugin-fossil
>
> At a glance, the Tools>Fossil menu includes the following:
>
>- Annotate 
>- Diff 
>- Timeline 
>- Status 
>- 
>- Add 
>- Delete 
>- Revert 
>- ---
>- Diff
>- Timeline
>- Revert
>- Status
>- ---
>- Pull
>- Push
>- Update
>- Commit
>- Settings
>- Create Repository
>
>
> All of these actions result in resp. Fossil commands, with a bunch of
> accompanying niceties thanks to QtCreator's VCS framework.
> Branching and tagging is done on commit.
> Fossil "Clone" is handled via New Project wizard -- that's how it's done
> in Qt Creator.
>
> So for the most part this should shield the developer from SCM
> command-line interaction in routine project work.
> However "Merge" and some other repo-maintenance tasks should be done from
> command-line or Fossil UI.
> From personal experience, I feel that "Stash" should also be made
> available in the plugin, but that's later.
>
> Hope this clears it.
>
>
> On Sat, Oct 8, 2016 at 2:10 PM, Artur Shepilko 
> wrote:
>
>> We finally got to release Fossil plugin for QtCreator:
>> https://github.com/nomadbyte/qtcreator-plugin-fossil
>>
>> The Fossil plugin is free and open-source, of course. The README
>> describes how to build it. The most recent QtCreator version we used it
>> with is QtCreator-4.0.1, which is included in Qt 5.6.1-1 LTS (long-time
>> support) release. Through its life, internally we used the plugin with
>> previous versions of both QtCreator and Fossil client (the most recent was
>> 1.35).
>>
>> Hope this would help further spread the use of Fossil SCM, which is hard
>> to over-praise for its simplicity and versatility. Notably, thanks to
>> Fossil core devs for advancing its features over the years -- we really
>> appreciated this (first plugin release used fossil 1.26)
>>
>> For folks not familiar with QtCreator -- it's a multi-platform IDE for
>> C/C++ development. Primarily it targets Qt-based projects, but it's also
>> used with non-Qt projects and supports CMake-based projects. Support for
>> several popular SCMs is already built-in, yet Fossil is not supported --
>> with this plugin it is!
>>
>> Fossil plugin adds Fossil SCM as a choice for version control to use with
>> projects (similar to git, bazaar etc.). It's implemented using QtCreator
>> VCS framework which calls Fossil command-line interface. It supports
>> create/clone project repo, add/delete/rename files, diff/annotate,
>> status/timeline, revert/update/pull/push. Base set of operations, but it's
>> sufficient in routine development, the rest can be done directly with
>> fossil command.
>>
>> Enjoy!
>>
>> Artur
>>
>>
>
>
> ___
> fossil-users mailing 
> listfossil-users@lists.fossil-scm.orghttp://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
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

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

[Warren Young]

On Oct 27, 2016, at 5:37 AM, David Mason  wrote:
> 
> Also of interest is that Facebook is doing an implementation of hg in Rust.

Facebook’s market cap is $343.34 billion today.  This is relevant because...

>  Fossil seems pretty robust in C, but Rust would increase safety confidence.

According to SLOCCount, Fossil represents a $3.2 million investment in 
developer time, not counting SQLite.  Where is the money going to come from to 
pay those developers to rewrite it in Rust?

Further, it would take about 2 years to do that rewrite that with normal 
staffing, also according to SLOCCount.  (“Normal” meaning that the mythical 
man-month rule applies: doubling staff won’t halve development time.)  Are you 
really happy with the idea of Fossil making zero forward progress for two 
years, and at the end, you have exactly the same feature set as before?

With Facebook + Hg, the answer to these questions are clear, as you can see 
from the above.  But for Fossil…?

Here’s the full SLOCCount report, for your convenience:



SLOCDirectory   SLOC-by-Language (Sorted)
95707   src ansic=93887,tcl=1820


Totals grouped by language (dominant language first):
ansic:93887 (98.10%)
tcl:   1820 (1.90%)


Total Physical Source Lines of Code (SLOC)= 95,707
Development Effort Estimate, Person-Years (Person-Months) = 24.04 (288.54)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.79 (21.52)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 13.41
Total Estimated Cost to Develop   = $ 3,248,123
 (average salary = $56,286/year, overhead = 2.40).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] nginx & systemd

[Aldo Nicolas Bruno]

This is how I manage my fossil repositories...

on nginx configuration...

root /var/www/pizzahack.eu;

location /fossil {
  include scgi_params;
  scgi_pass localhost:8088;
  scgi_param SCRIPT_NAME "/fossil";
}

#this is for custom javascript and css
location ^~ /fossil/media {
  try_files $uri $uri/ =404;
}

I've created this file: /lib/systemd/system/fossil.service
[Unit]
Description=Fossil
After=syslog.target

[Service]
ExecStart=/usr/local/bin/fossil server /var/www/pizzahack.eu/fossil
--localhost --port 8088 --scgi --repolist
User=fossil
Type=simple

[Install]
WantedBy=multi-user.target

to update the service list:
systemctl daemon-reload

I've created the user fossil & gave ownership to the fossil forder
then it's enough to run
systemctl enable fossil && systemctl start fossil
and of course also you need to enable & start nginx

I'm also using highlightjs for automatic code highlight... that I've
loaded on /var/www/fossil/media

The only thing I couldn't achieve is to use the root / url as the fossil
home. I was forced to use /fossil or anything else

Tested on debian jessie
Hope it's useful to anyone :)

--
Aldo Nicolas Bruno

___
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 Thu, Oct 27, 2016 at 1:37 PM, David Mason  wrote:
> I's about 1/3 of the way through this report:
> https://groups.google.com/forum/#!topic/mozilla.dev.version-control/nh4fITFlEMk
>
> It seems that they originally preferred GIT (because it was what they knew)
> but now prefer hg, although it's a bit light on the reasons.  The article
> points out that Facebook has a heavily mod-ed version of hg.  It might be
> interesting to see what they've done that has made their people happy...

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
-- it's about scalability -- at least if I understand this well...

> for
> consideration for fossil.

indeed, would be good if fossil would scale well.
___
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 plugin for QtCreator IDE

[Aldo Nicolas Bruno]

Nice stuff!
Wondering why you didn't manage it as a fossil repository? :)
Il'll try this asap. I'm using qtcreator for a couple of projects at
job... (currently with git). I need to find some time to
download/compile qtcreator sources
Thanks
Aldo

On 27/10/2016 00:08, Artur Shepilko wrote:
> A quick follow-up. A few folks asked if the Fossil plugin for Qt
> Creator supports "Commit" action -- it does support commit.
> I missed to list it in my original email, sorry for the confusion.
> This is actually mentioned on the project page:
> https://github.com/nomadbyte/qtcreator-plugin-fossil
>
> At a glance, the Tools>Fossil menu includes the following:
>
>   * Annotate 
>   * Diff 
>   * Timeline 
>   * Status 
>   * 
>   * Add 
>   * Delete 
>   * Revert 
>   * ---
>   * Diff
>   * Timeline
>   * Revert
>   * Status
>   * ---
>   * Pull
>   * Push
>   * Update
>   * Commit
>   * Settings
>   * Create Repository
>
>
> All of these actions result in resp. Fossil commands, with a bunch of
> accompanying niceties thanks to QtCreator's VCS framework.
> Branching and tagging is done on commit.
> Fossil "Clone" is handled via New Project wizard -- that's how it's
> done in Qt Creator.
>
> So for the most part this should shield the developer from SCM
> command-line interaction in routine project work.
> However "Merge" and some other repo-maintenance tasks should be done
> from command-line or Fossil UI.
> From personal experience, I feel that "Stash" should also be made
> available in the plugin, but that's later.
>
> Hope this clears it.
>
>
> On Sat, Oct 8, 2016 at 2:10 PM, Artur Shepilko  > wrote:
>
> We finally got to release Fossil plugin for QtCreator:
> https://github.com/nomadbyte/qtcreator-plugin-fossil
> 
>
> The Fossil plugin is free and open-source, of course. The README
> describes how to build it. The most recent QtCreator version we
> used it with is QtCreator-4.0.1, which is included in Qt 5.6.1-1
> LTS (long-time support) release. Through its life, internally we
> used the plugin with previous versions of both QtCreator and
> Fossil client (the most recent was 1.35). 
>
> Hope this would help further spread the use of Fossil SCM, which
> is hard to over-praise for its simplicity and versatility.
> Notably, thanks to Fossil core devs for advancing its features
> over the years -- we really appreciated this (first plugin release
> used fossil 1.26)
>
> For folks not familiar with QtCreator -- it's a multi-platform IDE
> for C/C++ development. Primarily it targets Qt-based projects, but
> it's also used with non-Qt projects and supports CMake-based
> projects. Support for several popular SCMs is already built-in,
> yet Fossil is not supported -- with this plugin it is!
>
> Fossil plugin adds Fossil SCM as a choice for version control to
> use with projects (similar to git, bazaar etc.). It's implemented
> using QtCreator VCS framework which calls Fossil command-line
> interface. It supports create/clone project repo,
> add/delete/rename files, diff/annotate, status/timeline,
> revert/update/pull/push. Base set of operations, but it's
> sufficient in routine development, the rest can be done directly
> with fossil command.
>
> Enjoy!
>
> Artur
>
>
>
>
> ___
> 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] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

Allow me to elaborate a little more, hope this will make you stop
posting like in the previous days.

On Thu, Oct 27, 2016 at 1:30 AM, K. Fossil user
 wrote:
> a) I have nothing to ask at this time, so I don't even need to learn how to
> [ask]



> b) Someone who have something to say could demonstrate whatever he wants
> (e.g. Why does Fossil need (x)inetd when it is clearly forbidden by security
> expert ?).

Since in this mailing list I believe there are "experts", excluding
me, I would like you to understand that writing something like
"_someone_ who knows much more than you told me, _somewhere_,
_sometime_, that I should not use  because
it is not secure to use".

Now, note the use of "somexxx": you provided no documentation, no
links, no facts, no other discussions. Which version of x|inetd are
you referring to? Which version of fossil? Which OS? What kernel?
Which options?

So what can you do in order to help fossil? I believe you can test and
crash a few installations on your own and report back results with
some numbers, in order to support all your statements and the
statements made by _someone_ expert.

In the meantime I suggest you to carefully read this mailing list
before posting, as well as you do review basic mailing list rules and
recommendations (e.g., no html please). The simple fact that you point
git as an "enemy" for fossil means you do know very little about the
project and the culture behind it.

Luca
___
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:
> Fossil seems pretty robust in C, but Rust would increase safety confidence.

Many people do believe that just because an application is written in
Rust rather than in C that it must be "safer".  But it is a logical
fallacy.  You should avoid falling into that trap.

Rust helps at preventing certain kinds of bugs (null pointer
dereferences, use after free).  But those have never been an issue
with Fossil.  Fossil uses the transactional guarantees of the
underlying SQL database engine to ensure the safety of user data.
Perhaps Rust might be helpful in systems like Git or Hg which depend
on the integrity of the application-level code for data correctness
and safety.  But as Fossil has no such dependency, rewriting Fossil in
Rust would not help in any way.  Rather than making Fossil "safer",
rewriting it in Rust would simply introduce a bunch of new bugs cause
by the inevitable translation errors.

See https://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for
background information.

Irony:  Isn't Rust heavily dependent upon Git for its package
management?  So if Hg is written in Rust, does that mean that Hg has a
dependency on Git?

-- 
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] OT: Facebook engineers preferring hg to Git

[David Mason]

I's about 1/3 of the way through this report:
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/nh4fITFlEMk

It seems that they originally preferred GIT (because it was what they knew)
but now prefer hg, although it's a bit light on the reasons.  The article
points out that Facebook has a heavily mod-ed version of hg.  It might be
interesting to see what they've done that has made their people happy...
for consideration for fossil.

There's also a new command called absorb that does some merging before
commits that seems quite useful.

Also of interest is that Facebook is doing an implementation of hg in Rust.
Fossil seems pretty robust in C, but Rust would increase safety confidence.

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