Discussion:
Fossil on HN
(too old to reply)
Richard Hipp
2016-10-10 01:31:34 UTC
Permalink
https://news.ycombinator.com/item?id=12673229
--
D. Richard Hipp
***@sqlite.org
Adam Jensen
2016-10-10 12:12:57 UTC
Permalink
Post by Richard Hipp
https://news.ycombinator.com/item?id=12673229
These are probably significant decision points for a lot of people:

"My intent is to continue personally supporting and maintaining Fossil
for at least three more decades."


Adam Jensen
2016-10-10 14:02:15 UTC
Permalink
Post by Adam Jensen
Post by Richard Hipp
https://news.ycombinator.com/item?id=12673229
"My intent is to continue personally supporting and maintaining Fossil
for at least three more decades."
http://youtu.be/Jib2AmRb_rk
Along the same lines, it might be awesome if there were a dhr@
implementation of HDF5[1] using the same engineering methods, quality
standards, and long-term maintenance guarantees as SQLite.

Taking that idea further, if there were a data repository management
system, like Fossil, but with the goals (or additional goals) of
managing HDF5 based instrumentation data rather than (or addition to)
text file revision history, that could be a big deal within the
scientific communities.

[1]: https://www.hdfgroup.org/hdf5/
Though an open standard, there is only a single implementation of HDF5
(and it is less than inspiring).
Adam Jensen
2016-10-10 14:04:34 UTC
Permalink
s/dhr/drh-crew
Lonnie Abelbeck
2016-10-10 12:46:54 UTC
Permalink
Post by Richard Hipp
https://news.ycombinator.com/item?id=12673229
Our project uses Fossil to track configuration files for various open source packages, git was a non-starter for our small, embedded 50 MB image.

Fossil's small footprint and efficiency with built-in web tools makes it apples vs. oranges to most other VCS.

Lonnie
Richie Adler
2016-10-10 17:49:55 UTC
Permalink
Lonnie Abelbeck decía, en el mensaje "Re: [fossil-users] Fossil on HN" del
Post by Lonnie Abelbeck
Post by Richard Hipp
https://news.ycombinator.com/item?id=12673229
Our project uses Fossil to track configuration files for various open source packages, git was a non-starter for our small, embedded 50 MB image.
Fossil's small footprint and efficiency with built-in web tools makes it apples vs. oranges to most other VCS.
Your case is a very nice "success story".

Fossil is a perfect example of an excuse that has to die. *Nobody* has the
excuse that version control is costly or complicated anymore. You don't even
need to create an account in Github. You can keep it all in house and the
configuration couldn't be easier...
Adam Jensen
2016-10-10 18:11:43 UTC
Permalink
Post by Richie Adler
*Nobody* has the
excuse that version control is costly or complicated anymore.
As I sit here trying to untangle the [Permuted Index][1] of documents, I
realize there is most definitely a cost; I am paying it now. And,
unfortunately, none of this attention and effort is being harnessed. I
could be flagging small problems - something like making notes in the
margin while reading a book - a syntax error here, a grammatical problem
there, something that needs clarification or rephrasing, etc.

If the interface were designed to collect that data, I imagine the
developers could make good use of it and the cost of learning to use the
system would be reduced even further.

[1]: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html
Konstantin Khomoutov
2016-10-10 18:36:50 UTC
Permalink
On Mon, 10 Oct 2016 14:49:55 -0300
Richie Adler <***@gmail.com> wrote:

[...]
Post by Richie Adler
Fossil is a perfect example of an excuse that has to die. *Nobody*
has the excuse that version control is costly or complicated anymore.
You don't even need to create an account in Github.
So, do you really think one has to create a Github account to use Git?
You have been sadly misinformed then: github.com is to Git what
chiselapp.com is to Fossil -- a hosting solution (one of many, in case
of Git).
Post by Richie Adler
You can keep it all in house and the configuration couldn't be
easier...
You can "keep it all in house" using any contemporary VCS.

That's not to say Fossil does not have some edge here in the form of
its cobmo -- self-hosting on the server plus easy web UI -- just please
be objective.
Say, if I need to back a Git repo up to a nearby server I do

ssh server git init --bare ~/repo.git
git remote add backup ssh://server/~/repo.git
git push --all --follow-tags backup

which, I reckon, is next to be zero-configuration, too.
Warren Young
2016-10-10 19:26:52 UTC
Permalink
Post by Konstantin Khomoutov
On Mon, 10 Oct 2016 14:49:55 -0300
[...]
Post by Richie Adler
Fossil is a perfect example of an excuse that has to die. *Nobody*
has the excuse that version control is costly or complicated anymore.
You don't even need to create an account in Github.
So, do you really think one has to create a Github account to use Git?
Yes, I do, because git is nearly unusable without github.com or similar, whereas /usr/bin/fossil is perfectly usable as-is. :)

I’m only joking^Wserious. :)
Post by Konstantin Khomoutov
github.com is to Git what
chiselapp.com is to Fossil -- a hosting solution (one of many, in case
of Git).
github.com is far more than a hosting service. It provides a whole pile of things that don’t exist in /usr/bin/git or /usr/libexec/git-core/*:

https://github.com/features

And yes, I already know that not all of those things are in Fossil or ChiselApp, but many of them are, and many of the things you only get in Github Enterprise *are* in stock Fossil.
Post by Konstantin Khomoutov
Post by Richie Adler
You can keep it all in house and the configuration couldn't be
easier...
You can "keep it all in house" using any contemporary VCS.
But you can’t keep Github in house without buying Github Enterprise, at $21/user/month, minimum 10 users, so $2,520 per year entry cost.

If you want any of the features common to Github/GHE and Fossil, and you want to host it privately, you’re looking at GHE or one of its complicated competitors. For example, here’s GitLab’s setup guide for CentOS:

https://about.gitlab.com/downloads/#centos7

Compare Fossil: unpack, make && sudo make install.

No matter how you slice it, Git is more complex than Fossil, compared feature-for-feature. Git only has advantages where it has a feature that you need that is missing in Fossil. Many of us don’t need the extras Git provides, like subrepositories, rebase, etc.
K. Fossil user
2016-10-12 00:38:14 UTC
Permalink
I read this :"Please steal ideas and code from Fossil"There are no serious reason for people to use Fossil.In the past I was a huge fan of it...
1/ I ask for a poll I was told that I was ... (no matter what).2/ I've tried to compile Fossil it did not... In the past, it did nicely: I've created my own deb files. Too complicated nowadays ?3/ I asked about a guy's opinion when it comes to Fossil in production use : He said no. Note that he plays with huge projects.4/ I agree with him that for huge project it would be hard, especially when I've read that a big part of Fossil code is SQL with SQLite which is not for big project.Big projects uses PostGreSQL, MariaDB, Percona, Oracle, IBM SQL (DB2 and so on) ...5/ And when a project uses the word "steal" I have a big doubt...Even if it is a metaphoric "steal" it is inappropriate because it seems rude and disrespectful.You could say : "Please we are proud to help you to have a better UI/something if you wish.We could provide information about how good it is and if necessary we could work together"I could say that my writing is bad however in the fossil user base, I've seen many people who write very well...Ask them at least, so you could have a better communication.
6/ Ask yourself why people stay with Git/Mercurial ... me included even if I am not a fan of them.

My wishes :
a) A poll as I asked the other dayb) A fossil release 1.37-rocksolid or 1.37-LTS without compilation problemsc) A strategy for fossil roadmap.d) A minimal understanding of Fossil users needs (Marketing and stuffs like that).e) A fossil that do run nicely as it is with git that I do use.

My wishes are a piece of cake for serious projects...
Best Regards

De : Warren Young <***@etr-usa.com>
À : Fossil SCM user's discussion <fossil-***@lists.fossil-scm.org>
Envoyé le : Lundi 10 octobre 2016 19h26
Objet : Re: [fossil-users] Fossil on HN
Post by Konstantin Khomoutov
On Mon, 10 Oct 2016 14:49:55 -0300
[...]
Post by Richie Adler
Fossil is a perfect example of an excuse that has to die. *Nobody*
has the excuse that version control is costly or complicated anymore.
You don't even need to create an account in Github.
So, do you really think one has to create a Github account to use Git?
Yes, I do, because git is nearly unusable without github.com or similar, whereas /usr/bin/fossil is perfectly usable as-is. :)

I’m only joking^Wserious. :)
Post by Konstantin Khomoutov
github.com is to Git what
chiselapp.com is to Fossil -- a hosting solution (one of many, in case
of Git).
github.com is far more than a hosting service.  It provides a whole pile of things that don’t exist in /usr/bin/git or /usr/libexec/git-core/*:

  https://github.com/features

And yes, I already know that not all of those things are in Fossil or ChiselApp, but many of them are, and many of the things you only get in Github Enterprise *are* in stock Fossil.
Post by Konstantin Khomoutov
Post by Richie Adler
You can keep it all in house and the configuration couldn't be
easier...
You can "keep it all in house" using any contemporary VCS.
But you can’t keep Github in house without buying Github Enterprise, at $21/user/month, minimum 10 users, so $2,520 per year entry cost.

If you want any of the features common to Github/GHE and Fossil, and you want to host it privately, you’re looking at GHE or one of its complicated competitors. For example, here’s GitLab’s setup guide for CentOS:

  https://about.gitlab.com/downloads/#centos7

Compare Fossil: unpack, make && sudo make install.

No matter how you slice it, Git is more complex than Fossil, compared feature-for-feature.  Git only has advantages where it has a feature that you need that is missing in Fossil.  Many of us don’t need the extras Git provides, like subrepositories, rebase, etc.
Warren Young
2016-10-12 14:46:43 UTC
Permalink
Post by K. Fossil user
1/ I ask for a poll
If you mean your request nearly 4 months ago in the thread about how the mailing list is run, a poll isn’t going to affect anything. This project is not a democracy. Like virtually all other open source projects, it is a do-ocracy: that is, those who do the work make the rules. User voices do occasionally sway those who do the work, but ultimately the project runs the way they want it to run.
Post by K. Fossil user
2/ I've tried to compile Fossil it did not…
I’ve rebuilt Fossil several times over the past few days. It still builds just as easily as it ever did.

“It did not” is not something we can help you with. If you want help with build problems, post your OS and compiler details along with the error messages you got.
Post by K. Fossil user
3/ I asked about a guy's opinion when it comes to Fossil in production use : He said no. Note that he plays with huge projects.
Several very famous people claim that vaccines cause autism, despite decades and millions of dollars of research.

Testimonials are not facts, and expertise is relative.
Post by K. Fossil user
I've read that a big part of Fossil code is SQL with SQLite which is not for big project. Big projects uses PostGreSQL, MariaDB, Percona, Oracle, IBM SQL (DB2 and so on) …
Project size is almost the very last consideration to take into mind when considering the DBMS to use. Features, cost, administration, etc. are far more important.

By your logic, Git is even less suitable to large projects because it doesn’t use a DBMS at all, and “everyone” knows that large projects require a DBMS.

SQLite has two major weaknesses compared to the client-server DBMSes you mention:

1. SQLite proper is not client-server, so it is a bad choice when multiple computers need to modify a single DBMS instance. This is not a problem for Fossil because we have “fossil server” which provides that piece. (Also ssh tunneling.)

2. SQLite is not well-tuned for highly concurrent access. This is only a problem if you have frequent simultaneous commits. I don’t mean that two commits run concurrently occasionally during the workday, I mean high levels of sustained concurrent access. If that is not happening on your Fossil repository, you don’t need a highly-concurrent DBMS as the Fossil data store.

With those two weaknesses eliminated as irrelevant to this particular application, there is no reason not to use SQLite and plenty of reason to use it.

I suspect that if you reworked the Fossil internals to use a different DBMS engine that Fossil would run considerably slower for almost all current users of Fossil. Until you get to dozens or more concurrent accesses, the advantages of the big client-server DBMSes aren’t going to show up for Fossil.

(I say that as one who has migrated code from MySQL to SQLite and observed a 2x speed increase because the application no longer has all that client-server IPC overhead.)
Post by K. Fossil user
5/ And when a project uses the word "steal" I have a big doubt…
That’s a perfectly good idiomatic use of English. It does not mean what you think it does. Please do not criticize other people’s use of English until you have mastery of it yourself. I’m not trying to be unkind, I am just telling you that you have no basis to be criticizing drh’s use of the English language given your demonstrated skill level.

(Be assured that I will not criticize your use of French. :) )
Post by K. Fossil user
6/ Ask yourself why people stay with Git/Mercurial …
Easy: network effects.

https://en.wikipedia.org/wiki/Network_effect
Post by K. Fossil user
b) A fossil release 1.37-rocksolid or 1.37-LTS without compilation problems
We can’t fix problems if you don’t tell us what you’re running into.

I just did a search on this mailing list for your email address, and I can’t see any messages detailing your compilation problems.
Post by K. Fossil user
c) A strategy for fossil roadmap.
Already done:

https://www.fossil-scm.org/index.html/info/0e047901c2f4a07d8110f7bb9a94c92b56202700
Post by K. Fossil user
d) A minimal understanding of Fossil users needs
So tell us: what are your unmet needs?
Post by K. Fossil user
(Marketing and stuffs like that).
Marketing is not the correct word if you mean to talk about improving Fossil to meet user needs. Market research is part of it, but that’s only a tiny part of marketing.

I believe you should be talking about community management, not marketing. That’s what we’re doing here, right now. It is why I am answering your email instead of ignoring it.
Post by K. Fossil user
e) A fossil that do run nicely as it is with git that I do use.
Have you tried the nick.lloyd-git-interop branch?

https://www.sqlite.org/debug1/timeline?r=nick.lloyd-git-interop
K. Fossil user
2016-10-16 02:58:09 UTC
Permalink
Hi,
1/ "it is a do-ocracy"We didn't know that. NOW I DO KNOW ! Thank you.I don't think that the owner of a project will give the keys to the average people, do you ?However, the leader of any project knows who to listen to.

2/  "I’ve rebuilt Fossil several times over the past few days.  It still builds just as easily as it ever did."Happy for you. When I will have time I will try it again. 1.35 does not here the last time I did it.

3/ "If you want help with build problems, post your OS and compiler details along with the error messages you got"This means that you don't understand.I NEVER said that I will explain anything about MY compilation issue. I explain that A compilation issue, I face, is NOT normal when in the past there were NO compilations problems.These last days, I was astonished that some compilation problems occur for some people especially for the Windows OS.How could it be possible ? I don't know.

4/ "Testimonials are not facts, and expertise is relative"I pass the vaccine discuss (a bit stupid but I accept that anyway).One day about a software I used to play with, a guy said "compilation issue". Nothing else. The owner of the project try the compilation process and then found it; fixed of course.To say it in kids word : "may be there is a compilation issue just because HE SAID it".IMHO "compilation issue" is a rumor [kind of]. Not fact at all ! However, the owner have got a good nose so he found the issue. As I said, fixed of course.
Expertise is relative ? Nope, unless you don't know anything about the subject (any subject) you talk about.In the past I've heard about CVS, then SVN came. But when I've read GIT features I did say : "This is the future".You could know people who have got high diploma in a field but he is bad in this field, or another one who have no diplomas AT ALL and he is excellent in the field. I do know people like the two I've mentioned.The best stay The Best (with a big B).In our discuss, the Best is not you or me because we do not have very big projects in our hands.People like the one I do know who plays with many [very] big projects, have my vote. He NEVER said "Fossil is a possibility" he said "NO".No is no sir.He was even very kind to tell me about some projects that is not known, and especially one. This one, few years after, was showed and explained in some magazines...

5/ "Project size is almost the very last consideration to take into mind when considering the DBMS to use".If you know what a DBMS is, you could understand the basics of what I'd say :a) Try to use the Best DBMS if human resources (DBA?) could follow or if it is not forbidden by the host of your DBMS (only MySQL) or etc.b) Use a DBMS that is not an issue for the project : if you've got few names SQLite suffice, however if those names are sensitive information, may be, a more robust DBMS is better.c) Some technological issue may encourage a DBMS over another: If you would like to use a cluster of many computers, Percona could be better than MySQL; I never said that MySQL could not do the trick.d) etc.
SO I could never said that the size of a project is ONLY something that decide what kind of DBMS you may use.I use GIT for many little projects, but I would like to use Fossil for a bigger one. Am I wrong ?

6/ "By your logic, Git is even less suitable to large projects because it doesn’t use a DBMS at all, and “everyone” knows that large projects require a DBMS."NEVER said nor think that. Sarcastic huh ?
Some answers are below.Despite the facts that I am not a linux developper, Linux does not use any DBMS as I know (yeah I could be wrong but even if it is the case they may use a little portion of it) but they use GIT. I suppose that L. Torvald is a fool because he misses Fossil ?Is linux big enough for you?Do you really think that for me a DBMS is a requirement for large projects ? I even discourage people to use DBMS if possible."Try to use [unicode] text when you can", I always say. It's like I say MongoDB, Redis, etc : NoSQL most of the time !

7/ Your discuss about SQlite weakness...a) Even a rock solid DBMS such as PostgreSQL have got some weakness : you call it bugs.It is sometimes known as slower because it is more secure ...b) You said that there's a lack of HIGH concurrency with SQLite. Big projects needs "load balancing" (which most of the time needs correct concurrency).In another word, Fossil is not suited for real big projects.I was suddenly right ? :-D
c) Fossil could use SQLite if they want that, and it is not a bad idea. However SQL is not the future, but this is another topic :-).

8/ Ah the "steal" discuss... :D
Sorry I laugh for what I've read.a) One could criticize whatever he wants IF it is respectful e.g. correctly explained, etc.I could say that the mailman configs are bad e.g. the one for Fossil, etc.b) So you could understand that I could say that YOUR English is not suited for the target audience e.g. we don't care if drh have got a PhD in English.
c) Of course I know what idiomatic stands for ! (really I laughed! even now I do laugh).

Let's face it:a) I've got an American well educated friend who teaches English. My basic English is good enough to be understood, and she noticed that I understand even high level discuss.b) Unless I am wrong, Fossil is not for US only citizen with PhD in English (major semantics).In a more layman word, most people have very basic knowledge of English, especially technical English.And that means that "steal ideas" could be at first glance misinterpreted...c) For the record I do understand what DRH/whosever-you-name-him would like to say.He could for example say "pick our idea it would help" even if it could be seen as a bit pretentious...In short : try to understand Globish but explain in proper English.
d) I was told that most computer specialists are rude and brutal, disrespectful, etc.I am the stupid guy who said "no some do, most don't".Didn't I say that "steal idea" is at least disrespectful ?
9/ "Easy: network effects."It is so simple ? Wow !a) CVS was used for ages, then SVN... Network Effect seems not come to SVN...b) For technical reason I will use Git not SVN. The same reason arise when we compare Fossil and Git.I can't use Fossil for big projects, that suffice.

10/ "I can’t see any messages detailing your compilation problems"Thank you but most of the times I know how to deal in most problems when it comes to compilation.
BTW I've answered it few lines above, beginning at number 3.

11/ I've asked for a roadmap:
a) Easy to find address such as fossil-scm.com/docs/roadmapsb) Not an obscure address that could only be find because I've asked you.c) Yay I do know that there is a serious lack of communication in Fossil...

12/ "So tell us: what are your unmet needs?"I've said nothing about it : there is no reason for that. See number 13.

13/ "Marketing" Community management ?
Let's see :"That’s what we’re doing here, right now.  It is why I am answering your email instead of ignoring it"a) some people would see this as a bit disrespectful.b) I know what community management is, sorry for you.c) My discuss is really about marketing. Ah, I know what marketing is.In [serious] marketing, poll is necessary... especially polls about convenient way of communication in our cases.Don't you (Fossil Team) say no to me ?These suffice to tell me that you (Fossil team) know nothing about marketing (communication, interaction, and so on).d) Two of us in the past talk about MatterMost one day. Thank to this guy.
A guy who have a little skill about Marketing and Management (community for example), knows about MatterMost and will even want some discuss about it. Nothing happens.
14/ Just ONE example inside many that demonstrate how far you (Fossil Team) are from what should be communication and marketing."Have you tried the nick.lloyd-git-interop branch?"a) Why should I ? I ask something for normal user not for geeks.b) Is it normal when the average guy (and some of you think that I am one of the worst of Fossil user so I am the guy who just use basic Fossil) ask for something to tell him to go in nowhere ? A branch is nowhere !c) Imagine you ask me for some marketing knowledge. I respond : read books, this one. Nice ?
Imagine a big project, would you ask people to test many branch/tags to find his treasure, especially if the treasure is a must ?


So what the point may some people ask ?Good question.Why am i going to loose my time to explain/ask for/debate about/etc. marketing communication polls compilation issues when I read how and what the Fossil team answer to me ?Why am I going to use Fossil when the learning curve may discourage and as I've noticed, Git can do most of the job ?When I read some answers, some people think that poll is an end stop, when for clever men and women, it is a beginning of many things.
The only reason why I respond to your answer is that I've answered in this topic about something which should have an impact in the future of Fossil.Unfortunately, people could read whatever is said, my prose included. This means that it is illogical if I don't explain my point of view.When people don't get why marketing (communication) is important, they do not deserve anything from me.
To sum up my point in this thread, when I've seen many thread about compilation issue, it is an evidence of at least a lack of documentation, and believe me or not, for some people it could be worst.Do you need me to explain what is the semantic of the word "Worst" ? Clever people understand easily how tremendous is the issue.No one would like any fight, at least not me. So try hard.


Best Regards

K.
P.S. : I will never understand why should I give long answer when most of what I say is known for ages...
De : Warren Young <***@etr-usa.com>
À : Fossil SCM user's discussion <fossil-***@lists.fossil-scm.org>
Envoyé le : Mercredi 12 octobre 2016 14h46
Objet : Re: [fossil-users] Fossil on HN
Post by K. Fossil user
1/ I ask for a poll
If you mean your request nearly 4 months ago in the thread about how the mailing list is run, a poll isn’t going to affect anything.  This project is not a democracy.  Like virtually all other open source projects, it is a do-ocracy: that is, those who do the work make the rules.  User voices do occasionally sway those who do the work, but ultimately the project runs the way they want it to run.
Post by K. Fossil user
2/ I've tried to compile Fossil it did not

I’ve rebuilt Fossil several times over the past few days.  It still builds just as easily as it ever did.

“It did not” is not something we can help you with.  If you want help with build problems, post your OS and compiler details along with the error messages you got.
Post by K. Fossil user
3/ I asked about a guy's opinion when it comes to Fossil in production use : He said no. Note that he plays with huge projects.
Several very famous people claim that vaccines cause autism, despite decades and millions of dollars of research.

Testimonials are not facts, and expertise is relative.
Post by K. Fossil user
I've read that a big part of Fossil code is SQL with SQLite which is not for big project. Big projects uses PostGreSQL, MariaDB, Percona, Oracle, IBM SQL (DB2 and so on) 

Project size is almost the very last consideration to take into mind when considering the DBMS to use.  Features, cost, administration, etc. are far more important.

By your logic, Git is even less suitable to large projects because it doesn’t use a DBMS at all, and “everyone” knows that large projects require a DBMS.

SQLite has two major weaknesses compared to the client-server DBMSes you mention:

1. SQLite proper is not client-server, so it is a bad choice when multiple computers need to modify a single DBMS instance.  This is not a problem for Fossil because we have “fossil server” which provides that piece.  (Also ssh tunneling.)

2. SQLite is not well-tuned for highly concurrent access.  This is only a problem if you have frequent simultaneous commits.  I don’t mean that two commits run concurrently occasionally during the workday, I mean high levels of sustained concurrent access.  If that is not happening on your Fossil repository, you don’t need a highly-concurrent DBMS as the Fossil data store.

With those two weaknesses eliminated as irrelevant to this particular application, there is no reason not to use SQLite and plenty of reason to use it.

I suspect that if you reworked the Fossil internals to use a different DBMS engine that Fossil would run considerably slower for almost all current users of Fossil.  Until you get to dozens or more concurrent accesses, the advantages of the big client-server DBMSes aren’t going to show up for Fossil.

(I say that as one who has migrated code from MySQL to SQLite and observed a 2x speed increase because the application no longer has all that client-server IPC overhead.)
Post by K. Fossil user
5/ And when a project uses the word "steal" I have a big doubt

That’s a perfectly good idiomatic use of English.  It does not mean what you think it does.  Please do not criticize other people’s use of English until you have mastery of it yourself.  I’m not trying to be unkind, I am just telling you that you have no basis to be criticizing drh’s use of the English language given your demonstrated skill level.

(Be assured that I will not criticize your use of French. :) )
Post by K. Fossil user
6/ Ask yourself why people stay with Git/Mercurial 

Easy: network effects.

  https://en.wikipedia.org/wiki/Network_effect
Post by K. Fossil user
b) A fossil release 1.37-rocksolid or 1.37-LTS without compilation problems
We can’t fix problems if you don’t tell us what you’re running into.

I just did a search on this mailing list for your email address, and I can’t see any messages detailing your compilation problems.
Post by K. Fossil user
c) A strategy for fossil roadmap.
Already done:

  https://www.fossil-scm.org/index.html/info/0e047901c2f4a07d8110f7bb9a94c92b56202700
Post by K. Fossil user
d) A minimal understanding of Fossil users needs
So tell us: what are your unmet needs?
Post by K. Fossil user
(Marketing and stuffs like that).
Marketing is not the correct word if you mean to talk about improving Fossil to meet user needs.  Market research is part of it, but that’s only a tiny part of marketing.

I believe you should be talking about community management, not marketing.  That’s what we’re doing here, right now.  It is why I am answering your email instead of ignoring it.
Post by K. Fossil user
e) A fossil that do run nicely as it is with git that I do use.
Have you tried the nick.lloyd-git-interop branch?

  https://www.sqlite.org/debug1/timeline?r=nick.lloyd-git-interop
Continue reading on narkive:
Loading...