Re: [fossil-users] warning about unsaved changes with `fossil checkout --keep`

[K. Fossil user]

Hi,
It is better if you could give to people the release you do use... (1.37 ?)
Some people do use a release that is inside some public servers which are not 
always up to date.Not to mention that most of the time the official (say 
stable) release is not the latest release which is less buggy ...
 
Best Regards

K.

  De : Natacha Porté <nata...@instinctive.eu>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 7 juillet 2017 9h44
 Objet : Re: [fossil-users] warning about unsaved changes with `fossil checkout 
--keep`
   
Hello,

*snip*
Have I left anything unclear?


Natasha
___
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] Fossil 2.1

[K. Fossil user]

1/ Git is better than Fossil when it comes to the job to be done. period.
2/ nine days after first commit is not evidence of efficiency.

a) it could be an evidence of issues. Windows compilation issue was reported 
after commits in the past.That kind of issue is totally abnormal.
b) The version numbering is rubbish X.Y when everyone [say serious projects] do 
x.y.z ...Did someone notice Google Chrome numbering ? Huh ?

c) debian and slackware do take very long time before stable releases.IMHO 
debian and slackware teams are (very far) better than will ever be the Fossil 
team whatever you may think.
d) not to mention that when it comes to security, the Fossil Team is not aware 
about it...(who is stupid enough to use inetd ? Fossil claim they do ! wow !)
3/ If Fossil is so the best, why don't people would like to use it ? There are 
many website that host Fossil repository ...
4/ Ok it's Warren comments ... So I don't take it too seriously. I like to read 
his comments when I've got times so I could laugh, sometimes loudly...I urge 
Warren to sometimes talk about security : it's VERY amusing...(The MD5 discuss 
: wow)I say : SOMETIMES, not every day...  
Regards

K.

  De : Warren Young <war...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 10 mars 2017 17h32
 Objet : Re: [fossil-users] Fossil 2.1
   
On Mar 10, 2017, at 10:26 AM, Richard Hipp <d...@sqlite.org> wrote:
> 
> Fossil version 2.1 is now available from the download pages. 

…after 9 days from first commit to final release.

Beat that, Git!

___
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] Fossil 2.1 beta. Was: Progress report of Fossil 2.x

[K. Fossil user]

Ah ? really ?
1/ I am one of the guys who talks about security here. I am not the first 
one.SHA1 was one of the discuss...
2/ I am one of the first guy who give many examples of good way to use a 
specific hash algorithm... (when you use command line)

If honesty occur here, kudos should go to us not to DRH.
Just to mention that the explanation given (SHA1) is known for a long time : 
there is an issue with SHA1.
The Fossil Team, or whatever you may call it, did just what every software team 
should do : give appropriate explanations about the policy that should or may 
occur [around the SHA1 issue].
3/ To let you understand my point :I was astonished that finally the Fossil 2.0 
is not SHA3, but it sticks with SHA1.You should ask/demand an SHA3 if you want 
it to run with your Fossil 2.0. Say : command line such as fossil new sha3 ... 
[or something like that]

In another word, Fossil 2.0 which is supposed to be considered as a MAJOR 
release, did not make the change ...
People should see a new release such as 1.37.1 (with the new SHA1 algo) but 
this will NEVER happen.
People should expect that the 2.0 is SHA3 with SHA1 as an option if needed...

4/ I suppose that the Fossil Team knows nothing about ergonomics, too ?(Poor of 
me)

 
Best Regards

K.

  De : Lonnie Abelbeck <li...@lonnie.abelbeck.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 5 mars 2017 23h31
 Objet : Re: [fossil-users] Fossil 2.1 beta. Was: Progress report of Fossil 2.x
   

On Mar 5, 2017, at 5:01 PM, Richard Hipp <d...@sqlite.org> wrote:
> The big change is that now Fossil will actually generate SHA3-256
> hashes for new artifacts, if you ask it to, or by default in new
> repositories.  See
> https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.wiki for
> details.

Kudos to Richard, the Fossil team and all that contributed ideas for this 
Fossil "Hash Policy".  It appears every corner-case is covered.

Lonnie

___
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] Fossil Version 2.1 (prerelease)

[K. Fossil user]

DRH question is strange in fact ...
Not everyone would go for a Fossil 2.0 just because their repo ARE SHA1.
Not to mention that, some providers won't move immediately when a stable 
release will come.
I've said it in the past : a command line with option such as --sha1 --sha256 
and so on is necessary...Of course the Fossil Team did not get it ... [until 
people ask for it]

 
Best Regards

K.

  De : Lonnie Abelbeck <li...@lonnie.abelbeck.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 5 mars 2017 16h30
 Objet : Re: [fossil-users] Fossil Version 2.1 (prerelease)
   

On Mar 5, 2017, at 10:15 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 3/5/17, Lonnie Abelbeck <li...@lonnie.abelbeck.com> wrote:
>> For what is planned for Fossil 2.1, will new repos created using 2.1 using:
>> --
>> fossil init --sha1 repo.fossil
>> --
>> be compatible with recent Fossil 1.x versions ?
> 
> Yes.

Thanks Richard,

> But why would you want to do that?  Fossil 2.0 is out and 2.1 will be out 
> soon.

We use a fossil repo to track configuration files on an embedded system 
(Asterisk PBX, etc.).

Compatibility between fossil versions far more important to us than any 
practical issue with SHA1.  Users can upgrade and revert firmware, possibly 
containing any version of Fossil.

BTW, I just committed Fossil 2.0 for our next release.  We do appreciate the 
option to use SHA3 when we decide to.

Thanks the world-class project, Fossil.

Lonnie

___
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] Fossil 2.0 for win64 [Was: Fossil Version 2.0]

[K. Fossil user]

Is your Fossil app compiled with the Official SQLite ?
As I remember, you seem to have a better approach ... [a better SQLite]
Just sayin'  
Best Regards

K.

  De : Jan Nijtmans <jan.nijtm...@gmail.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 3 mars 2017 13h54
 Objet : [fossil-users] Fossil 2.0 for win64 [Was: Fossil Version 2.0]
   
2017-03-03 14:45 GMT+01:00 Richard Hipp:
> Fossil version 2.0 is now available on the Fossil website
> (https://www.fossil-scm.org/download.html) and its mirrors.
>
> Fossil 2.0 is 100% backwards compatible with Fossil 1.x.  Do no worry
> about the change in the first digit.

For anyone interested in a 64-bit Windows build, this can be found here:
    <https://sourceforge.net/projects/cyqlite/files/fossil/>

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


   ___
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] Google Security Blog: Announcing the first SHA1 collision

[K. Fossil user]

Hello,
I can't believe that a so called community manager (Warren) could say theses 
...  :D
I assume that most of you have read Warren Stuff ?
1/ Hey Warren, you know nothing about security software so don't speak about 
it. :-|

2/ CentOS does not need any advice from you : they know their stuff.a) SHA 
algorithm is not an issue when it is more a test for integrity such as MD5 for 
files than anything else.b) You are like a kid who focuses on ONE thing when 
people like me are focusing in MANY things even when it comes to ONE subject.c) 
CentOS uses many tools to know who is sending what.You could force people to 
follow some procedures to be allowed to put a precise info into a specific 
server :
Say, you can ask the guy to use SSH first to connect, and only after he could 
work : no GPG, nothing else needed...I don't even talk about port knocking...
So they can rely on ONLY SHA1 if they want that, this is not an issue at all !
So YOUR sentence "it’ll be a problem if git.centos.org is still relying on SHA1 
hashes" IS NOT RELEVANT.
3/>"Point #2 is also questionable.  Torvalds is assuming that any collision 
attack on a Git"
Really ? As I understand Fossil points (security etc) are not seriously 
questionable [for you] ... but Linus point is ? Are you kidding ?
MY assumption is that Linus would like that a guy such as a Fossil Team guy, 
could understand that it is NOT that hard to make some changes with the SHA 
algorithm...

In another word :

4/ When you say that plans are easy but execution is hard ... You miss the 
point.a) Plans are necessary for serious project.b) Plans done, execution is 
not that hard : it may take time but it is not that hard.c) Appropriate tools 
are needed to achieve plans in time and expectations...
Serious project = Plans ! OK ?

If for you SHA1 is not a serious project, then I would like you to explain it 
to us... :D
5/ All this said :I've noticed that there are too much details in Linus Torvald 
discuss. I suppose that he was thinking about guys like you Warren ?You know 
the guy that don't get it. :-)
  
Regards

K.

  De : Warren Young <war...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Lundi 27 février 2017 18h10
 Objet : Re: [fossil-users] Google Security Blog: Announcing the first SHA1 
collision
   
On Feb 26, 2017, at 2:58 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> 
> just FYI, Linus' own words on the topic, posted yesterday:
> 
> https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL

Point #1 misses the fact that people *do* rely on Git hashes for security.  
Maybe they’re not “supposed” to, but they do.

For example, the CentOS sources are published through Git these days, rather 
than as a pile of potentially-signed SRPM files.  This means the only assurance 
you have that the content checked into Git hasn’t been tampered with is that 
the hashes are consistent.

(I randomly inspected one of their repos, and it doesn’t use GPG signed 
commits, so the hashes are all you’ve got.)

This is adequate security today, but once bad actors can do these SHA1 attacks 
inexpensively, it’ll be a problem if git.centos.org is still relying on SHA1 
hashes.


Point #2 is also questionable.  Torvalds is assuming that any collision attack 
on a Git checkin will be detectable because of the random noise you have to 
insert into both instances to make them match.

Except that you don’t have to do it with random noise.

Thought experiment time: Given that it is now mature technology to be able to 
react to a useful subset of the spoken English language either over a crappy 
cell phone connection or via shouting at a microphone in a canister in the next 
room, complete with query chaining (e.g. Google Now, Amazon Echo, etc.) how 
much more difficult is it to write an “AI” that can automatically generate 
sane-looking but harmless C code in the middle of a pile of other C code to 
fuzz its data bits?

I have no training in AI type stuff, but I think I could do a pretty decent job 
just by feeding a large subset of GitHub into a Markov chain model.  Now 
imagine what someone with training, motivation, and resources could do.

Or, don't imagine.  Just go read the Microsoft Research paper on DeepCoder:

  https://news.ycombinator.com/item?id=13720580

I suspect there are parts of the Linux kernel sources that are 
indistinguishable from the output of a Markov chain model. :)  *Someone* 
allowed those patches to be checked in.


As for his point #3, he just offers it without support.  He says there’s a 
plan.  Well, we have a plan, too.  Plans are easy.  Execution is the hard part.
___
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

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[K. Fossil user]

Hello,

Does this mean that it is not so hard to adapt SHA algorithm to a better one ?:D

DRH suspected that it would be hard :D :D :D
Of course I don't agree with DRH ; I will never agree with him about security 
discuss either ... :-|
Thank to "sgbeal". :-)  
Best Regards

K.

  De : Stephan Beal <sgb...@googlemail.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 26 février 2017 21h58
 Objet : Re: [fossil-users] Google Security Blog: Announcing the first SHA1 
collision
   
On Sun, Feb 26, 2017 at 10:34 PM, Richard Hipp <d...@sqlite.org> wrote:

And in any event, I don't think centralization is a factor here.
Fossil is better positioned than Git or Mercurial to transition to a
different hash algorithm because the Fossil implementation uses a
relational 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.


just FYI, Linus' own words on the topic, posted yesterday:
https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/"Freedom is sloppy. But since tyranny's 
the only guaranteed byproduct of those who insist on a perfect world, freedom 
will have to do." -- Bigby Wolf

___
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] Google Security Blog: Announcing the first SHA1 collision

[K. Fossil user]

1/ Warren the guy who knows nothing about software security talks about 
software security ...Wow. I don't get this.

2/ semi?

> « I think Fossil is in a much better position to do this sort of migration 
> than, say, Git, due to its semi-centralized nature »
This would convince people to use Git not Fossil ...

Git is more secure than Fossil (first reason to use a VCS)Git could be 
centralized or not. I am wondering if Fossil could be centralized... Now you've 
said that it is semi-centralized by NATURE.

 
Regards

K.

  De : Warren Young <war...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 24 février 2017 0h01
 Objet : Re: [fossil-users] Google Security Blog: Announcing the first SHA1 
collision
  


On Feb 23, 2017, at 10:50 AM, Marc Simpson <m...@0branch.com> wrote:
> 
> This may be of interest to some here, especially in light of previous
> SHA-1 related discussions on list:
> 
>  https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Before I respond, first know that I respond out of concern for Fossil.  I’m a 
staunch Fossil defender, and I’m on the record doing so, many times.  My 
motivation in laying out these criticisms is that I want Fossil to continue to 
be worthy of that defense going forward.

Second, there will be those who say we’ve covered all of this already, multiple 
times.  I know, I was there.  But now we have new data.  Before, this sort of 
attack was theoretical only.  Now it’s not only proven possible, it is already 
within the ROI budget for certain specialized attacks; attacks only get cheaper 
over time.

The new data includes not only this news from Google and its research partners. 
 The resulting discussion on Hacker News made me aware of a way an attacker 
could use this new attack against Fossil despite the fact that this is “just” a 
collision, rather than a way to generate second-preimages inexpensively:

    https://news.ycombinator.com/item?id=13715887

This thus gives me an answer to drh’s challenge to me in one of the prior 
threads on this subject:

    https://goo.gl/2tzdOi

Executive summary for those who don’t want to click either of the above links: 
Challenge: “What can you do with this attack?”  Response: “Replace a good 
checkin during a clone/sync shipping that good checkin to another Fossil 
instance.”  After the attack, the repos do not all contain the same data, but 
they will agree that they’re in sync if you ask them to check.

Previous threads have pointed out that you need to fiddle not only with the 
SHA1 but also with an MD5 and some other kind of non-cryptographic checksum, 
and still have both the evil and useful checkins be working C code.  All of 
that is doable.  A motivated attacker could probably do all of that 
computationally in about a second on modern hardware.  That means these other 
mechanisms add essentially nothing to Fossil’s resistance to sync stream 
tampering.

The classic solution for Byzantine Fault Tolerance in the face of 1 possible 
traitorous general — or an untrustworthy messenger, as with the MITM attack — 
is to have at least 3 replicas, but that only works when the algorithm used to 
achieve consensus among the loyal generals is trustworthy.

This paper is on-point:

    http://zoo.cs.yale.edu/classes/cs426/2012/bib/castro99practical.pdf

Quoting from page 2, “We also assume that the adversary…[is] computationally 
bound so that (with very high probability) it is unable to subvert the 
cryptographic techniques mentioned above.”  We call that “key assumption 
violated” where I come from.  (Check the authors list, by the way.  Yes, *that* 
Liskov.)

According to another post on the Hacker News page linked above, this attack 
cost about $100k in GPGPU resources.  There must be Fossil-hosted projects 
worth that much to attack today, and after a bad actor pulls that one off, 
they’ve paid for the hardware, so a second attack costs only power and cooling. 
 

Given the up-front costs, a bit more to mount a MITM attack doesn’t seem 
infeasible.

Consider also that this attack is “free” to attackers who already have access 
to a pool of compromised PCs, many of which will have powerful GPUs.

Today, I see the following defenses to this problem:

1. “fossil diff --from known-good-release” before electing to use binaries 
built from a given repo you don’t trust implicitly.  (And I hope this news has 
shortened your list of such repos!)

2. Modify all drive-by patches to foil pre-generated collisions.  (Presumably 
you trust those with checkin privileges on the repo.)

3. Put any attackable Fossil repos behind a TLS proxy with a strong cert (i.e. 
not self-signed, and certainly not SHA-1 hashed!) that enforces TLS access, as 
in my HOWTO:

    https://goo.gl/USybpW

TLS proxying prevents the MITM attack, but look at the cost.  I’m happy to pay 
it for my public Fossil repos, but do we

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[K. Fossil user]

Thank you Marc...
1/ I've said that it is needed to let people choose their digest algorithm...
a) of course the Fossil team does not take into account what I've said.
b) I was wondering in the past when would it be possible to the lambda guy to 
break the sha1.Finally it is worse than what I've expected...
c) I like this sentence :"especially in light of previous
>SHA-1 related discussions on list"
the discussion is not over, it is the beginning ... :D

2/ When I reply to ALL I've got these TWO e-mail ...Which one is the correct 
one...?
 
 
Best Regards

K.

  De : Kees Nuyt <k.n...@zonnet.nl>
 À : fossil-us...@mailinglists.sqlite.org 
 Envoyé le : Jeudi 23 février 2017 18h15
 Objet : Re: [fossil-users] Google Security Blog: Announcing the first SHA1 
collision


  
[Default] On Thu, 23 Feb 2017 09:50:12 -0800, Marc Simpson
<m...@0branch.com> wrote:

>This may be of interest to some here, especially in light of previous
>SHA-1 related discussions on list:
>
>  https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Interesting.

https://shattered.io/ says:


Who is capable of mounting this attack?

This attack required over 9,223,372,036,854,775,808 SHA1
computations. This took the equivalent processing power as 6,500
years of single-CPU computations and 110 years of single-GPU
computations.

How does this attack compare to the brute force one?

The SHAttered attack is 100,000 faster than the brute force
attack that relies on the birthday paradox. The brute force
attack would require 12,000,000 GPU years to complete, and it is
therefore impractical. 


-- 
Regards,
Kees Nuyt

___
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] Linux binary downloads

[K. Fossil user]

> « 1.37.1 » ???

AH ?We were told that this would never occur [inside the Fossil Realm].Even a 
non official binary should not use that numbering because it is disrespectful.
Surprisingly you've decided to do whatever I've said :a) Use little numbering 
for little fixesb) Use latest SQLite when possiblec) Use appropriate secure 
software (the latest OpenSSL at least)
You don't agree with the Fossil Team such as Warren and many others ?
(No warren is NOT in the Fossil Team he speaks as if he is inside)

 I guess that you are the man who would give to us the 1.37 rock solid I've 
asked ?
I like this talk from you :
« Provides win32/win64 versions of sqlite3.dll, which work better 
(smaller/faster/longer paths) than the dll's provided by sqlite.org . »

A better Fossil will be a good idea... :-)

 
Best Regards

K.

  De : Jan Nijtmans <jan.nijtm...@gmail.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mardi 21 février 2017 9h58
 Objet : Re: [fossil-users] Linux binary downloads
   
2017-02-20 16:42 GMT+01:00 Richard Hipp:
> On 2/20/17, sky5w...@gmail.com <sky5w...@gmail.com> wrote:
>> Any chance to get the Windows binary as x64 also?

You can find my win64 build here:
    https://sourceforge.net/projects/cyqlite/files/fossil/
It is marked 1.37.1, because it is built with openssl 1.1.0e
and SQLite 3.17.0, and it has a few more fixes discovered
just after 1.37. (see the 1.37 branch in the fossil repository)

> The problem with that (for me at least) is that it is difficult to
> compile the OpenSSL library using MSVC.  OpenSSL really wants to be
> compiled with MinGW.  And I only have a 32-bit MingGW compiler.  So
> (for me at least) the choices are 32-bit Windows builds, or 64-bit
> builds that lack "https" capabilities.

So, what's the problem with the mingw-w64 compiler? Works
fine in my environment, and - as far as I know - in any
64-bit windows environment.

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


   ___
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] Bug report: Terrible Performance, when Checking in LLVM Source

[K. Fossil user]

Hi,
@Martin Vahi said :
> « [...] CPU is AMD 64bit [...] »

I don't know what AMD 64 means for you : it could be a dual core or a Quad 
core, and who knows an optocore...

The amount of RAM could let the calculation of the Checksum be faster ...
The bus speed can help a lot
etc.

> « [...] The uplink is ~1MiB/s (~10Mbps) and the ping
from my local machine to the remote machine is about 20ms [...] »

1MiB : it's theorical I guess.

You've said that files uploaded ONE by ONE should take 1 hour when a block of 
the equivalent data is 2 hours ... ??

No, when you process ONCE a copy it is faster than MANY little ones ...

@Jungle said :
> « Doesn't this depend on the CPU and available RAM? Search the archives
for importing large repos »

It is not importing it is exporting : "commit" Martin said.
BTW, I agree with your FIRST question (RAM).
@Karel said :
> « [...] subversions trees [...] »

So Martin should migrate the SVN trees to a git ones first and then import the 
git ones into a fossil one ... No ?

> « [...] If however I'm still off, I would appreciate
reference to some material explaining repo/chksums business in fossil. [...] »

So do I :-)

@Joerg said :
> « [...] What repo checksum does is compute a separate checksum over the
concatenation of all files [...] »

Hmmm...

You should say that EACH files are checksumed AND the repo itself is checksumed.

This should explain why it takes so long for a large repo... No ?
  
Best Regards

K.

  De : Joerg Sonnenberger <jo...@bec.de>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Dimanche 4 décembre 2016 20h55
 Objet : Re: [fossil-users] Bug report: Terrible Performance, when Checking in 
LLVM Source
   
On Sun, Dec 04, 2016 at 09:23:37PM +0100, Karel Gardas wrote:
> On Sun, Dec 4, 2016 at 8:57 PM, Joerg Sonnenberger <jo...@bec.de> wrote:
> > On Sun, Dec 04, 2016 at 08:50:44PM +0100, Karel Gardas wrote:
> >> Otherwise as Nikita recommended, switching off repo checksums helps a
> >> lot, but then make sure you are on the filesystem like ZFS/btrfs which
> >> does that for you transparently and you do not need to do that on the
> >> fossil side.
> >
> > Eh, no. You do not need a file system with automatic hashing. Every
> > single file is still recorded by checksum in Fossil. It is not what the
> > repo checksum option does.
> 
> Errhmm, thanks for correction. Am I right that repo checksum switched
> on means that modified files will be those where checksum stored and
> checksum computed from the file on fs is different? And once you
> switch that off, you rely purely on comparison of modification time on
> file in fs and I guess stored modif time in repo db? If so, then
> indeed I've been completely mistaken and thank you very much for your
> kind correction. If however I'm still off, I would appreciate
> reference to some material explaining repo/chksums business in fossil.

No. What repo checksum does is compute a separate checksum over the
concatenation of all files.

Joerg
___
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] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[K. Fossil user]

1/ Dear Joerg,
I really appreciate your stuff in this Fossil mailing list. However it seems 
that you don't read that much what I've written...
> « [...] it's been said before. Please keep your aggressive attitude and 
> platitudes to yourself. You are just annoying and distracting people [...] »

I give my point but it is clear that you haven't read them...
This said why don't you explain to me why I could not find any checksums here ? 
(1.36)

Fossil Download Checksums
http://www.hwaci.com/fossil_download_checksums.html


a) For the record, This is the Fossil official checksum website as I understand 
it.b) I was not the first who have noticed this. I was thinking that it is a 
simple bug for few hours.It for a long time that nothing happens, so I decided 
to talk about it.
c) You know that the day I will see a 1.37 rock solid, I would look at 
evrything especially what is relevant for everyone :checksums, 32/64 bits for 
Linux/Windows, compilation, etc.
 
Have a nice day Joerg. (It's time to me to talk to Will)

2/ Mister Will Parsons I presume ?
> « [...] Can we all now just stop replying to his [censored by K.], or better 
> yet, have him removed from the mailing list? »

Note that I censored some part of your talk to avoid issues...
a) I love it if you dare to say that to Linus Torvalds, Patrick (Slackware), 
etc. even if they are clearly wrong.And of course I don't even tell to you that 
you can see that behavior with some more "normal" people in a mailing list.Why 
aren't those guys expelled far outside the universe ? Mystery...

b) Explain where I am wrong so I could see what I could do for you, if I 
wish.Which part ? SLQLite ? Fossil ? Marketing (I don't want to talk about 
something you don't know) ? release ? What is it ?

c) I didn't know that a dot invalid domain is a serious one.Let me know what is 
it about your website.
d) Sorry but NOW I don't have time for you. Tomorrow I guess.

e) Dear Will, I forgot : Sorry about that.Here, I do use Webmail, but as I 
understand most guys do use a MUA.
Why don't you Mr Parsons do a simple thing for us :create a filter where "K. 
Fossil user" should be thrown in the dust-bin of your MUA.
e1) You will avoid me to see your stuff
e2) You will avoid people to read our stuffs...
e3) You won't deserve anything from me so I will be glad if you do that ... 
PLEASE Mr Parsons (We don't care if it is your name).

 Regards

K.

  De : Joerg Sonnenberger <jo...@bec.de>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Mardi 15 novembre 2016 10h46
 Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 
64bit binary
   
Dear "K. Fossil user",
it's been said before. Please keep your aggressive attitude and
platitudes to yourself. You are just annoying and distracting people.

Joerg
___
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] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[K. Fossil user]

Hi,
1/ > « [...] in other words fossil was happy enough at that time to release 
1.36 [etc...] »

Software that doesn't have any bugs, is utopia.At least here (in my country), 
we don't dream ...
2/ > « [...] Quite frankly creating a new fossil version each time a new 
sqlite3 version (even minor) is out could lead to a loop [etc...] »

Seriously ? Nope.Fossil needs SQLite to run appropriately, SQLite could exist 
without Fossil. We can use Git (Yeah the evil for some Fossil user).
SO,a) SQLite was 3.15.0 and now is 3.15.1, which should mean a bug fix, even a 
minor one.b) Fossil must use the SQLite that is supposed without bugs, which is 
... 3.15.1.c) We can conclude that we could wait for 10 days...That is the 
point, not the loop discuss which is not relevant here. We could create 1.36.1 
then 1.36.2 then 1.36.3, I will stay with SQlite 3.15.1 with Fossil 1.36.0 
INSIDE sqlite.org if I do wish that.The main component of Fossil is SQLite.

> « [...] Beside that, could you try to discuss technical stuff without being 
> such hostile? »

People try to talk : why don't you try ?Someone is clearly hostile ? Try to 
demonstrate that such behavior is not relevant if you can...

  
Best Regards

K.

  De : Luca Ferrari <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 13 novembre 2016 10h58
 Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 
64bit binary
   
On Sat, Nov 12, 2016 at 1:24 AM, K. Fossil user
<ticketpersonnal-fos...@yahoo.fr> wrote:
> Explain me why a SO serious project could not wait for 10 days or if it is
> not that possible (I don't see why ??), why don't Fossil create a 1.36.1?

Sorry pal, my guess is that the latest sqlite3 was not required by
fossil 1.36, in other words fossil was happy enough at that time to
release 1.36.
Quite frankly creating a new fossil version each time a new sqlite3
version (even minor) is out could lead to a loop, since sqlite3 needs
fossil to manage the code base and so each time a new fossil version
is out due to a new sqlite3 version, a new sqlite3 version should be
released leading to a new fossil version...

Beside that, could you try to discuss technical stuff without being
such hostile?

Luca
___
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] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[K. Fossil user]

> « [...] I have no idea what you think I wrote. [etc...] »


Ah ?No the answer was for Luca not for you, Scott ... ! :-D

Of, course, little software may not need Gantt software, however it is better 
to use such a tool.I will answer all the rest when I could but not now...
 
Best Regards

K.

  De : Scott Robison <sc...@casaderobison.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 13 novembre 2016 18h38
 Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 
64bit binary
   
On Nov 11, 2016 5:28 PM, "K. Fossil user" <ticketpersonnal-fos...@yahoo.fr> 
wrote:
>
> Ah you don't understand again what I've said ...
>
> 1/ Fossil and SQLite work together, and to be clear, the same guy work for 
> both projects.
> I was even told that the AIM of Fossil is to help SQLite.
> Do you agree at least with these ?Yes, fossil & sqlite have a beneficial 
> symbiotic relationship.> 2/ When you plan things you are supposed to create a 
> Gantt chart or something which help any project.
> For instance, something serious not something else.
> You've said it : Oct 24 Fossil, Nov 04 SQLite.
> I AM SO happy that you've wrote it.I have no idea what you think I wrote. 
> Gantt charts are not requirements for successful software. I've written some 
> very successful software projects that have been recognized with industry 
> awards without ever using a gantt chart. DRH makes new fossil releases 
> periodically for the community but he generally suggests using the tip of 
> trunk as he usually does himself.> Explain me why a SO serious project could 
> not wait for 10 days or if it is not that possible (I don't see why ??), why 
> don't Fossil create a 1.36.1?Fossil has never used semantic versioning. I 
> don't understand the reason for your continued emphasis on 10 days. Perhaps 
> the reason is that people are imperfect, or that they have different 
> priorities than you, or that they have simply started blocking your emails 
> due to the in your face "I'm right and anyone who disagrees with me is a 
> fool" style attitude that comes across in your messages. No, that is not a 
> quote from you, but it is how you come across.There are ways to communicate 
> that invite people to see your point of view. There are other ways to 
> communicate that make people dislike your message no matter how correct it 
> might be.>
> [too much] Pride ? Huh ?
>
> My point was : Why do Fossil show a 1.36 FEW days BEFORE SQLite.
> (FEW days IS the key of MY point of view before yours)I believe I addressed 
> this above.>
>  
> Best Regards
>
> K.
>
>
> 
> De : Luca Ferrari <fluca1...@infinito.it>
>
> À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
> Envoyé le : Vendredi 11 novembre 2016 11h38
> Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 
> 64bit binary
>
> On Wed, Nov 9, 2016 at 4:16 PM, K. Fossil user
> <ticketpersonnal-fos...@yahoo.fr> wrote:
> > Beyond that, I don't understand why SQlite is not 3.15.1 ...
>
> Seems to me that SQLite 3.15.1 was released on november the 4th, while
> fossil 1.36 was compiled on october the 24th.
>
> Anyway, I cannot find checksums for 1.36 here
> <http://www.hwaci.com/fossil_download_checksums.html>.
>
> Luca
>
> ___
> 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
>
___
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] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[K. Fossil user]

Ah you don't understand again what I've said ...
1/ Fossil and SQLite work together, and to be clear, the same guy work for both 
projects.I was even told that the AIM of Fossil is to help SQLite.Do you agree 
at least with these ?
2/ When you plan things you are supposed to create a Gantt chart or something 
which help any project.For instance, something serious not something 
else.You've said it : Oct 24 Fossil, Nov 04 SQLite.I AM SO happy that you've 
wrote it.
Explain me why a SO serious project could not wait for 10 days or if it is not 
that possible (I don't see why ??), why don't Fossil create a 1.36.1?
[too much] Pride ? Huh ?
My point was : Why do Fossil show a 1.36 FEW days BEFORE SQLite.
(FEW days IS the key of MY point of view before yours)
 Best Regards

K.

  De : Luca Ferrari <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 11 novembre 2016 11h38
 Objet : Re: [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 
64bit binary
   
On Wed, Nov 9, 2016 at 4:16 PM, K. Fossil user
<ticketpersonnal-fos...@yahoo.fr> wrote:
> Beyond that, I don't understand why SQlite is not 3.15.1 ...

Seems to me that SQLite 3.15.1 was released on november the 4th, while
fossil 1.36 was compiled on october the 24th.

Anyway, I cannot find checksums for 1.36 here
<http://www.hwaci.com/fossil_download_checksums.html>.

Luca
___
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] Download v1.36 Linux x86 tar.gz actually contains 64bit binary

[K. Fossil user]

Hi,
Yes, you should not give something dynamic to people ...I guess that it is 64 
bits because they are not aware by the fact that they should compile for both 
architectures (32 bits  AND 64 bits binary)?
I've recommended to the Fossil team that they should create a 1.36.1 release 
because most of the time there are some glitches that may suggest people that 
Fossil is not that serious.
Unfortunately, I was right...

Beyond that, I don't understand why SQlite is not 3.15.1 ... 
 
Best Regards

K.

  De : Artur Shepilko <nomadb...@gmail.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 9 novembre 2016 2h42
 Objet : [fossil-users] Download v1.36 Linux x86 tar.gz actually contains 64bit 
binary
   
Just happened to download v1.36 Linux binary off Fossil page to a
Linux x86-32bit box and surprisingly it would not execute
http://fossil-scm.org/index.html/uv/download/fossil-linux-x86-1.36.tar.gz

Turns out it's actually a 64bit binary:
      file ./fossil
      ./fossil: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=abeae887e354f3300aa097e9380ce8acead4711d, stripped

      ./fossil version -v
      This is fossil version 1.36 [c24373934d] 2016-10-24 14:59:33 UTC
      Compiled on Oct 24 2016 17:40:35 using gcc-5.4.0 20160609 (64-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
      SSL (OpenSSL 1.0.1f 6 Jan 2014)
      UNICODE_COMMAND_LINE
      DYNAMIC_BUILD

Not sure if this is a new way going forward, if it is, then certianly
this should be noted somewhere on the download page.

Previous releases (v1.35 and v1.34) are x86 32bit, also they are STATIC_BUILD.

This brings up another issue, on 64-bit Linux a staticly-linked 32-bit
fossil binary may not be able to properly bind to 64-bit gcc
run-times, producing error like the following:

      ./fossil-1.35-x86-32 clone http://fossil-scm.org fossil.fossil
      getaddrinfo() fails: Name or service not known
      Clone done, sent: 0  received: 0  ip:
      server returned an error - clone aborted

So, perhaps, there's a need to post BOTH Linux x84 binaries 32-bit and
64-bit. This way users may not need to scratch heads then tweak and
build Fossil themeselves.
___
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] Follow-up to reverting missing files

[K. Fossil user]

Hi,
1/ I've got a question : is bogus bounces NOT already solved ?

2/>backticks instead [of $(...)]

Can't we use pipes ? 
 
Best Regards

K.

  De : Andy Goth <andrew.m.g...@gmail.com>
 À : Fossil Users Mailing List <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 9 novembre 2016 3h03
 Objet : [fossil-users] Follow-up to reverting missing files
   
With my enhanced changes command, the way to revert all missing files is:fossil 
revert $(fossil changes -missing)If your shell doesn't have $(...) command 
substitution, use `...` backticks instead.If you're unlucky enough to have 
files with spaces in their names, you'll need:fossil changes -missing | xargs 
-r -d'\n' fossil revertYou can limit the scope by giving one or more directory 
name arguments to changes, e.g. "." for the current directory.Short of being 
clever with grep, you cannot inhibit recursion, so subdirectories are always 
processed too. I hope to change this eventually.If you don't have my enhanced 
changes command, in place of "fossil changes -missing" you can write:fossil 
changes | sed -rn '/^MISSING */s///p'This fails if a filename happens to start 
with spaces.Sorry, I can't properly reply to the email since I can see it only 
in the web archive and not my mailer (actually my phone), so it must have 
arrived during the time my account was deactivated due to bogus bounces.
___
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] Error compiling FOSSIL trunk

[K. Fossil user]

Hi,
I agree with Scott.
The checkin should not change many things (nothing with VS) when it comes to 
compiling...(The latest release is not that far...)

That's the point.  
Best Regards

K.

  De : Richard Hipp <d...@sqlite.org>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 2 novembre 2016 18h52
 Objet : Re: [fossil-users] Error compiling FOSSIL trunk
   
On 11/2/16, Scott Doctor <sc...@scottdoctor.com> wrote:
> Seems to be more problems than usual with this release.

That was not a "release" problem.  That was a check-in from yesterday.


-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] sites inaccessible

[K. Fossil user]

Hi,
Yesterday I've noticed that Fossil was down for a long time...drh said one day 
that inetd stopped : may be it was the case yesterday ?  
Best Regards

K.

  De : jungle Boogie <jungleboog...@gmail.com>
 À : General Discussion of SQLite Database 
<sqlite-us...@mailinglists.sqlite.org>; Fossil SCM user's discussion 
<fossil-users@lists.fossil-scm.org> 
 Envoyé le : Samedi 29 octobre 2016 7h28
 Objet : [fossil-users] sites inaccessible
   
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 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 <n...@corvidae.org>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 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 <d...@sqlite.org> 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

[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] 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 <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 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
<ticketpersonnal-fos...@yahoo.fr> wrote:
> Hi,
>
>> « <http://bikeshed.org/> »
>
> 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 

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] Which IDE is good with Fossil ?

[K. Fossil user]

Hi,
I would like to have some information, even little one about IDE that have 
Fossil as a DVCS (even a plugin that is experimental).
a) glade/GTK based IDE    Qt based 
    wxWidget based    Python based    Java based
    etc.
b) it could be interesting if you could give your point of view about it.(good 
news, issues, personal point of view, etc.)
c) Even if I am not interested in a comparison Git/SVN/etc. vs Fossil inside an 
IDE, I do suppose that it may be useful to tell something about it...d) IMHO it 
is interesting to hear what are the features inside the IDE (you talked about) 
that you would like to have or that you really appreciate...e) If you could, 
tell us about the release which suited the best.(sometimes old release are 
better ...)


 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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

In this mailing list we need to know everything about fossil and fossil related 
stuffs.- inetd/xinetd etc. that may be used in conjonction with Fossil (may be 
I am the only one who hear about a daemon (inetd) that was used with Fossil?)
- security related (Fossil is a server sort of)- Windows/Linux/etc. issue when 
it comes to Fossil- tips and tricks (most of the time are used with something 
else)
Every experience around Fossil use should be reported ...
This funny part :
>« you don't learn what to ask on the right mailing list »

You don't know when to stop which is worse... :-x

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 
?).c) If I were you the next time people would talk about OpenSSL/LibreSSL/etc. 
just demand to the Fossil Team to ban him.
    Of course, if someone would like to talk about GIT, it should be forbidden 
because it is a Fossil user enemy...

And if I understand your logic, you should not say that I am a troll/etc. : 
this is not Fossil ONLY talk ! :-)Wake up man ! :-D


Best Regards
K.

  De : Luca Ferrari <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 26 octobre 2016 6h25
 Objet : Re: [fossil-users] Why we should NEVER use inetd/xinetd
   
On Wed, Oct 26, 2016 at 1:02 AM, K. Fossil user
<ticketpersonnal-fos...@yahoo.fr> wrote:
> For example, today I've learned that Luca is not aware about security like
> 90% of Windows normal users...

And still you don't learn what to ask on the right mailing list.
Stop trolling.
___
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

[K. Fossil user]

Hi,

>« The security concerns come in as a result of not paying attention to the 
>details of the implementation »

Oh I forgot this.
In the past, it was my tought. But as the expert explain to us, it is not only 
implementation.
Theses days, we all hear about DDOS that could not be stopped, not to mention 
serious security issue not far in the past with routers...

>« but that is by no means a guarantee »

No one ask for guarantee. But everyone would like to reduce issues...


DDos :
'Preliminary' evidence: Cyberattack not carried out by a government - Oct. 25, 
2016
http://money.cnn.com/2016/10/25/technology/cyberattack-obama-dyn-ddos/index.html
Eh it was this year ? This month ? It should never happen, no ?

Today's Brutal DDoS Attack Is the Beginning of a Bleak Future
http://gizmodo.com/todays-brutal-ddos-attack-is-the-beginning-of-a-bleak-f-1788071976

« No matter who did it, we should expect incidents like this to get worse in 
the future »
As Luca said, Fossil users don't need security talks ... :-D

Hmm ...
Now I've got a question just for me : why do we want security in Github ?


Best Regards

K.


  De : Nathaniel Reindl <n...@corvidae.org>

*snip*




   ___
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,

>« Oh, I thought we were on fossil-users here... »

Many people are interested in security talks, but not you.
You are so good in this area, aren't you ?
When it comes to servers, especially TCP/IP things, one should consider 
security seriously.
People will talk again to you the day when a security breach happens to you 
with some software you do mostly use...

>« Ok, so why are you posting here instead of simply accepting what you have 
>been told as a religious dogma? »

You know nothing about security, don't you ?

>« OpenBSD releases twice per year, May and November, so how would you judge 
>such "trend"? »

a) My trend discuss is an example : many things are good sign.
b) OpenBSD have got security issue sometimes, check CVE.
In the past they've said that they have god no issues, and one day some issue 
was discovered.
Strange no ?
c) When I talk about security it is general purpose, not a specific one such as 
OpenBSD.
I don't even talk about Linux, why should I talk about OpenBSD that is a niche ?

>« Really, I don't see the point of all of this. »

... because you never face security issue in your life.

>« My fault. »

No, you don't have the skills to understand : you could not know everything.
That is one of the reason why I am here : I don't know anything about Fossil, I 
always learn something new most of the time.
For example, today I've learned that Luca is not aware about security like 90% 
of Windows normal users...


Best Regards

K.

  De : Luca Ferrari <fluca1...@infinito.it>

*snip*
   ___
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,

Thanks to Joerg who give some nice perspective about software.
Thank to Warren which tries to talk.

Warren said :
>« I just did a search for inetd at the NVD CVE search, and got nothing 
>relevant to running Fossil under inetd »

a) I don't talk about Fossil. My talk is about inetd/xinetd issue when it comes 
to security.
Clearly speaking, there COULD be security breach with 
inetd/xinetd/what-ever-it-is
b) There are nothing because, the latest release is 4 years later and no one 
would like to use such a software.
c) I've said that it is not recommended so who am I to think that you will find 
something in any CVE ?

>« Perhaps you have misunderstood your advisors, who are really saying that you 
>shouldn’t be using in.telnetd and such any more, which are merely *associated* 
>with inetd, but which are not inetd themselves. »

You really want to know what an expert in computers security said to us ?
"Never use xinetd or inetd or something like that."
Isn't never, never ?
I don't argue against an expert...

>« I am just telling you that the age of the software is a poor gauge to its 
>security »

a) no one said that the age of a software is an important gauge to its security.
b) The age of the LATEST change of a software may explain in part that it is 
widely used or not.
Then you could imagine if bugs could be found or not.
c) Age is not a poor gauge, it is a good one when you see the trends : few 
release are signs of few reviews and so on...

>« The responses just tell the original poster of that thread that *he* 
>probably doesn’t need it »

Nope, the answer explains that FreeBSD use what should be used: You call that 
best practice.
Most of the time it is for security reason when people decided to make changes.
Notice that it is said that inetd should not be used :
It is even said « run separate daemons » ...


At least read Joerg explanations ...They are well explained. :-P


Best Regards

K.

  De : Warren Young <w...@etr-usa.com>

*snip*
   ___
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] features I'd like to have in fossil

[K. Fossil user]

Hi,

>« Be concrete: how do you want tags to work which makes them entirely 
>different from branches? »

I've said that tags and branches are the same technically speaking.
However, for people those are not the same : for example the master branch is a 
special branch.

When in git you do :

git clone some-url

The code downloaded is the latest one, from the master branch (HEAD most of the 
time).

>« Why is it a problem that Fossil branches are implemented in terms of 
>auto-propagating tags? »

Marketing issue that you obviously don't know about.You can talk about release 
(tags) but not about experimental code (branch).

>« Branches vs tags have nothing to do with “marketing.” »

In the Fossil perspective, I agree with you, in the user perspective who knows 
nothing about Fossil/git/etc. that counts.
No one would like to read something like :
"Download the branch A because it [what you may want] is there" 

>« Both options exist because both have a reason to exist »

Which means they are different ? :D
People don't want to have multiple branches if they just would like to clone 
the repository or, if they want to have a special release (tags).
>« I challenge you to show me a real use case where Fossil’s write locking 
>causes an actual concurrency problem »

No one would show you that because as I've said, few people use Fossil.
May be a researcher could do that just for you.

>« My contention is that you will get zero measurable improvement in Fossil 
>performance when doing such a thing, which if true proves that SQLite is not 
>the problem here »

That is a point of view nothing serious. Citation needed as you asked... to me.

>« If you have to artificially generate 1000 simultaneous checkins to show that 
>system A is better than system B, that proves nothing, since virtually no 
>project has checkin rates anywhere near that level. »

a) Github is widely used ... many simultaneous access and so on.

b) When it comes to millions my assumption is that git can do the trick : 
Fossil will never.
 e.g. When you will use a 360 software (whatever it is), you need a rock solid 
DVCS.

>« Even large projects generally have only dozens of checkins *per day*, which 
>means that any given time, there is only zero or one checkin happening, which 
>in turn means concurrency IS NOT A PROBLEM. »

So your perspective is for some few guys when mine is for a more general 
purpose which is the future...
In another word, concurrency matters for Fossil.

>« A poll may feed information into the marketing process, but market research 
>is not marketing itself »

As I've said, Poll is marketing, but as I understand what you've said, I should 
be precise ?
When you need a poll it is because after some research you may have noticed 
that you need people point of view.
For example a guy asked someone to test/check is code...
When you check and give YOUR results to the guy, you explain to the guy what is 
good or not.

You do marketing because some projects don't ask anything and don't want any 
interactions : finally, they are in trouble.
(who would like to use your product if no one could complain to you ? And there 
are other ones around ?)

I never said that Poll is ONLY marketing, I've said that it is a tool for 
marketing.
Marketing is a vague word that even expert won't agree with when it comes to 
definition. So who are we to think that we've got a definition, and to be 
clear, who are you when you send to use a definition of marketing ?
Isn't it an evidence that you don't know what marketing is ?

>« Notice that there is no discussion of communication, responding to user 
>complaints and requests, or triaging bug reports. »

People don't talk about communication because this is not what they are coming 
for MOST of the time.
Clever people understand why communication (a marketing part) is so important.
Unless for you google teams are stupid when they use Stack (MatterMost is a 
clone sort of stack) ?

to sum up what I've said:
a) Poll is one of the numerous tools to do marketing.
b) Fossil is not good at concurrency/large projects which are bad things for 
the future.
c) Nowadays, few people uses a DVCS, but in the future when it comes to a 360 
software (Saas etc.) then a good DVCS is one of the key for success.

Definition of Marketing that could be accepted :
« Marketing is the activity, set of institutions, and processes for creating, 
communicating, delivering, and exchanging offerings that have value for 
customers, clients, partners, and society at large »

Marketing - Wikipedia
https://en.wikipedia.org/wiki/Marketing
« The holistic marketing concept looks at marketing as a complex activity and 
acknowledges that everything matters in marketing »




Best Regards

K.

  De : Warren Young <w...@etr-usa.com>

*snip*
You know it’s time for a thread to die when we have to resort to the dictionary 
for rebuttals, but since th

Re: [fossil-users] remote check in

[K. Fossil user]

Hi,

>« So do people who have a check-in or a new file email
the file to the administrator and they add/check-in, or do those
people have command line access? »

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
3/ The purpose of SSH (long talk with the Fossil users) is to help people use 
secure remote command line...
(This is how I understand it)
4/ I was wondering if Fossil have got something that is not "command line". I 
dunno.


Best Regards

K.



  De : Scott Doctor <sc...@scottdoctor.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Samedi 22 octobre 2016 22h40
 Objet : [fossil-users] remote check in
   
I am trying to figure out how to use fossil for an upcoming 
project. I keep coming back to fossil as the alternatives (git, 
mercurial,...) are just... well I will go bald trying to figure 
them out. I made a test repository to play with and mostly 
figured out the command line commands. The problem I am having 
is how to add files, do check-ins and such via the UI, mostly 
regarding doing it remotely without command line access.

My question is, for example the sqlite fossil system, someone 
wants to check-in a change of a file, or add a new file. How do 
they do such over the internet without having command line 
access? I do not see any operations from the UI that does that. 
Seems adding files, doing check-ins, merges, should all be part 
of the UI. So do people who have a check-in or a new file email 
the file to the administrator and they add/check-in, or do those 
people have command line access?

-- 

-
Scott Doctor
sc...@scottdoctor.com
-

___
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] features I'd like to have in fossil

[K. Fossil user]

Hi,

>« This is "fossil-users" mailing list, and it exists to share opinions,
problems, issues, suggestions and so on, would you agree to that? »

Exactly my tought.

>« learning curve »

I've said something about that.

>« The less people use it
- the less new ideas, less improvements and evolution »

Unfortunately you are right.

>« I do not propose any breaking changes »

Not me either.

>« What I expected from this post is, well, to share my problems with the
community. There was a chance I could get a discussion on the problems
to better understand what people think and whether they find it
important or not. That could help me to set the right priority to my work. »

Agreed !
I may add that I am here to help Fossil : this does _not_ mean that I would let 
people say something wrong about me or what I've said or think.

Again, Fossil needs to do/improve marketing.



Best Regards

K.


  De : Nikita Borodikhin <elit...@gmail.com>

*snip*
Hi Richie,
*snip*
   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[K. Fossil user]

Hi,

I was wondering if it is necessary to create a new thread just for 
inetd/xinetd...
Two guys said this :
>« Wait, what's wrong with inetd? »
and, this :
>« That ellipsis really should be filled in with more details. Would you 
>perhaps be willing to elaborate a bit on what you mean? »

These are simple questions from people who would like to understand, nothing 
else of course.At least, understand that they are NOT trolls.

1/ As I've stated in the past according to people I do know, for security 
reason, inetd/xinetd is not recommended.I was explained to never use ONE daemon 
for many servers. When needed ONE daemon for ONE server and not more.
At least if you must use inetd, use xinetd.

2/ Xinetd is old (four years ?) so may be not secure.

3/ And this info should definitely helps :
rc or inetd? What should I use? | The FreeBSD Forums
« Modern FreeBSD installations run separate daemons for almost every service 
nowadays, and inetd is all but deprecated. It's probably only around for 
historical/compatibility reasons. Starting services from /etc/rc.conf is the 
modern FreeBSD way. »


P.S. : I will never understand why people don't know about security issue when 
it comes to inetd.

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] features I'd like to have in fossil

[K. Fossil user]

Hi,
I don't have much time now but I just answer to what you've said :
No I don't ask Fossil team to switch now over MatterMost.I ask them to think 
about it. I remind you that I am not the owner of the Fossil.
It is not because I ask it for the Best of Fossil that it would mean that I do 
want that myself.

And for the record, I don't want to use Mattermost with Fossil as an 
IM/Chat/communication-thing-you-may-think.E-mail suffice.  
Best Regards

K.

  De : Warren Young <w...@etr-usa.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Samedi 22 octobre 2016 3h08
 Objet : Re: [fossil-users] features I'd like to have in fossil
   
Yes, and the impression I got is that the thing you are most concerned with is 
switching the community over to MatterMost.

Personally, the exact method the community communicates is one of the least 
important parts of Fossil.  I’d far rather time and effort be spent on Fossil 
itself rather than on chasing the IM/chat/email alternative of the month.
___
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] features I'd like to have in fossil

[K. Fossil user]

Hi again,
Most of the time I try not to interact with people discuss.
However, I was astonished by what a community manager answered to another guy.
So I decided to give my opinion about it.

> « You admitted to not using branches, apparently because you don’t see the 
> point of them in a single-developer project »

As a community manager if you said that to another guy, it means that he should 
use branch even if he doesn't want to.
For example, I don't want to use branch but I prefer tags even if branch is 
better. Tags have nothing to do with branches of course !
I just don't want branches because I prefer that all the stuffs are in ONE 
branch (Master, trunk, head, whatever-you-call-it).
Of course, I've never said that using a branch is bad : if one said he doesn't 
want, it's up to him.

>« Committing publicly, early, and often is objectively better, a fact that 
>falls naturally out of the mathematics of control theory. »

Nope.
a) It is said that SQLite is not good at concurrency. Thanks God someone, not 
me, dare to say that SQLite is not good when it comes to concurrency !
b) It creates higher server loads that should not occur.
c) it creates too much information so the Fossil file would grow too much for 
no serious reasons.
d) I even guess that it may create merge issues if everyone works with the same 
trunk and the same file (rare).

Who said that marketing (e.g. poll, good communication, etc) is not needed in 
the Fossil realm ?

As you could all guess, I prefer not to read all the rest.I expect that some 
people may read it and then give appropriate responses ...

Best Regards

K.PS: Have you read my unmet needs Warren ?

  De : Warren Young 
 À : Fossil SCM user's discussion  
 Envoyé le : Vendredi 21 octobre 2016 18h14
 Objet : Re: [fossil-users] features I'd like to have in fossil
   
On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin  wrote:
> 
> == color support - review the change, history analysis ==
> 
> One should not underestimate the significance of color on terminals these 
> days, that's why both git and mercurial and a lot of tools have color support 
> in their base distribution.  It makes it much easier to spot the changes in a 
> diff

For diff, simply install colordiff, which is almost certainly already packaged 
for your OS.  Then:

    $ fossil set diff-command 'coloridff -wu'
    $ fossil diff -r 2016-10-01 | less

> to group similar files together in a status report at a glance

Define “similar.”  Do you just mean that all the modified files should group 
together separate from the added files and such, or something different?

This is one of the areas where working code will speak louder than well-crafted 
prose.

> == change sets - preparing the change ==
> 
> I often end up having several sets of unrelated changes.

You admitted to not using branches, apparently because you don’t see the point 
of them in a single-developer project.  This is one good use for them.

That is, if you’re working on one feature and then see that you’ve gone off on 
a  tangent and are now building something unrelated, you can check the first 
feature’s unfinished changes into a branch, then return to the trunk to work on 
the second feature.

You’re using branches in this case to stash unfinished work without breaking 
the trunk or admixing unrelated features in a single checkin.

> Working with git, I use staging area to collect the needed changes and group 
> them together

I think the git staging area fights against team cohesiveness, primarily 
serving the needs of the sort of developer who likes to go off and hide in 
their office, not showing their work to their team members until it’s 
“perfect.”  Committing publicly, early, and often is objectively better, a fact 
that falls naturally out of the mathematics of control theory.

I realize that this is not a problem for you, but I’d guess that more Fossil 
users are on teams than not.

> subversion really shines here with its changelists

Some months ago, a proposal was made that I consider vastly superior to svn 
change lists: a flag for the stash command that would let you select and reject 
each hunk of the current diff interactively.

If you had three essentially unrelated changes in the current working copy, you 
could stash all the hunks belonging to two of them, then test the third change 
separately and check it in once you’re happy.  Then you could “stash pop” and 
repeat to polish the other two, one at a time.

It is important that this not be implemented in terms of checkin, since you 
need to test each unrelated feature separately before checking it in.

> == grep - development support ==
> 
> Often the projects building process leaves many temporary files in the 
> working directory.  I could grep over the directory using standard grep but 
> then I have to filter out those temporary files created by my build system.

The solution to that is ag, 

Re: [fossil-users] Can fossil bind to a single address?

[K. Fossil user]

Hi,
However, xinetd or inetd are not recommended...

Best Regards

K.

  De : Nathaniel Reindl <n...@corvidae.org>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Vendredi 21 octobre 2016 21h48
 Objet : Re: [fossil-users] Can fossil bind to a single address?
   
On Fri, Oct 21, 2016, at 05:28 PM, Steven Gawroriski wrote:
> Is Fossil able to bind to a single IP address? There is `--localhost`

It doesn't seem that way, no. I've personally worked around it by employing 
tcpsvd from Gerrit Pape's excellent ipsvd package. The inetd super server (and 
its descendants) provide similar functionality.

In my runit run script, modulo tcpsvd-specific details not relevant here, I 
have `exec tcpsvd 127.0.1.6 3000 fossil http /data/fossil/root --https`, and 
that seems to work well when using a reverse proxy to send traffic to it via 
something like Apache, HAProxy, or an Amazon ELB. —n
___
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] on sha1 as a hash

[K. Fossil user]

Hi,
In this thread I try to: give short answer to what I've read, then I give my 
opinion, and finally I put some suggests :
1/ Thanks to people who give their opinions and technical point of view in this 
topic.2/ I know that Git uses sha1, debian uses md5,sha1,sha256 , etc. ...The 
point is not "is it used?", the point is : is it secure when it is not only 
used locally ...3/ I've said that xinetd and something like that should not be 
used for any server, and drh used it in one of his server.4/ OpenBSD have 
security in mind so OpenBSD sha1 code should be used. However, see if license 
match.

My assumptions are:
1/ weak server is bad so even a sha512 or higher (does it exists ?) never 
change anything : you're in big troubles, or you will be in big trouble.2/ If 
we only use sha1, if people do want sha256, it could not happen. I would like 
an md5, so I could run it in a slower machine, I suppose.
My Suggests :
1/ SHA1 should be OpenBSD source code.
2/ At compilation time options should be :a) default : SHA256 only e.g. no 
options e.g. --with-sha=default e.g. --with-sha=sha256b) old behavior : SHA1 
and SHA256 e.g. --with-sha=compatibility e.g. --with-sha=sha1,sha256 e.g. 
--with-sha=before1.37-rock-solid (:D LOL)
c) SHA1 only (Why not) e.g. --with-sha=legacy e.g. --with-sha=sha1d) MD5 only 
(why not) e.g. --with-sha=md5e) public server e.g. --with-sha=public e.g. 
--with-sha=sha1,sha256,sha512f) local only e.g. --with-sha=local e.g. 
--with-sha=md5g) SHA1 is OpenBSD e.g. --sha1-is-openbsd e.g. 
--sha1-code=openbsd,netbsd
3/ Configuration example :commit-allowed-sha : md5,sha256commit-denied-sha : 
sha1commit-public-sha=sha1,sha256commit-priority : deny, allowed, 
nonefossil-exchange-priority : sha256, sha1, noneSHA1=OpenBSD
etc.
4/ Fossil status should show something like :SHA available are :- SHA1 (release 
number) OpenBSD
- SHA256 (release number) (default)-etc.
5/ When one runs it :fossil (some options) --commit-sha=md5,sha1,sha256fossil 
(some options) --commit-sha=publicfossil (some options) --commit-sha=myProfile 
# Yes it should be possible!
etc.

6/ In the fossil options when a browser is used, a tab should be used for SHA 
only.Everything should be seen there :a) Who could see what.b) Who could use 
what.c) What is the status of the configuration : server, Fossil file, etc.

All these need a poll. Why ?1/ Options name should be discussed.2/ Options real 
behavior should be known (is SHA1 OpenBSD ?)
3/ What are legacy and compatibility definitions for Fossil user ?
4/ default option should be clear.
etc.
Ah ! I was asked what are my unmet needs.I've said "none at this time: I don't 
want to talk about that".However, I think that THIS unmet need (sha options) 
are unmet needs that I do want as soon as possible, please !


Best Regards

K.

  De : Scott Robison <sc...@casaderobison.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 19 octobre 2016 18h48
 Objet : Re: [fossil-users] on sha1 as a hash
   
On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno <ovenpa...@pizzahack.eu> 
wrote:

  Better question can be, how fossil manage collisions? 


Fossil rejects new artifacts with matching hashes, working on the assumption 
that it already has the blob. The only way someone could hope to exploit this 
for malicious purposes is:
1. Discover some fossil user has created a commit with an artifact having a 
given hash X.2. Quickly create another artifact with that same hash.3. Push it 
to other copies of the same repository before the original fossil user is able 
to push his copy.
In both the cases of git and fossil, it seems to me that hash collisions 
(deliberate or coincidental) are a race condition. Whoever pushes to other 
repositories first wins.
Given that it is impossible to predict exactly how one will solve a given 
problem (and thus what its hash would be) in advance, the speed of fossil's 
default auto sync, the fact that no one has yet demonstrated an effective real 
time attack, and the fact that sha1 is not being used for security but for 
reliability, sha1 isn't an issue.
Even if someone found an effective real time attack that could generate a 
collision, they then have the problem of not just finding a collision, but a 
collision that will be close enough to the original that the primary 
functionality wasn't broken (in the case of tracking source code, arguably the 
most common case).
Really, from this POV, fossil and git are both just fine. It's far more likely 
that someone will compromise a server with a weak password and completely 
replace the good repo with a bad repo, or just host a fork that looks legit and 
get people to pull from that instead.
-- 
Scott Robison

___
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] on sha1 as a hash

[K. Fossil user]

Hi,
1/ Does Fossil use SHA1 ?OoToo bad if it is.At least I expect that we've got a 
choice : sha256, sha512, etc. ...

2/ However, when people use Fossil in a local PC, even MD5 should not be an 
issue.3/ Thanks for this reminder. 
 
Best Regards

K.

  De : bch <brad.har...@gmail.com>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Mardi 18 octobre 2016 22h23
 Objet : [fossil-users] on sha1 as a hash
   
https://news.ycombinator.com/item?id=12737535
___
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] disabled due to excessive bounces (again?)

[K. Fossil user]

Hi again,
1/ Malware or anything related? NOT at all !
2/ Yep resubscribe. However it could bother some people (not me tough).


Best Regards

K.

  De : Scott Doctor <sc...@scottdoctor.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mardi 18 octobre 2016 2h25
 Objet : Re: [fossil-users] disabled due to excessive bounces (again?)
   
Could it be a virus or some sort of malware?


-
Scott Doctor
sc...@scottdoctor.com
-

On 10/17/2016 19:12, Richard Hipp wrote:
> I was just now booted from my own mailing list for excessive bounces.
> ;-)  Dunno what that is about...
>
> It was easy enough to click on the link in the notification message to
> resubscribe.
>

___
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] disabled due to excessive bounces (again?)

[K. Fossil user]

Hi all of you,
Hi Scott and Luca,
1/ Luca said :
"And you are free to get another DVCS of your choice.
Go get trolling somewhere else"
a) I don't use Fossil. I used to in the past. I am waiting for a rock solid 
one. :-)At least read carefully if English is not your first language.b) I 
don't try another DVCS because I am happy with my Git for what I am waiting for 
(basic needs).
c) I think you don't know what a troll is.d) If you don't agree with someone 
try to argue.
(I was wondering if I should answer or not. :D)

2/ The discuss beyond will be for Scott.
a) One of the best comment I've ever read in Fossil Mail. Thank you.
b) I agree with most of your statment, at least, I agree with the "DRH/Linus" 
point of view.

c) "I have a hard time understanding how you think one email address having 
difficulty with a mail list is a sign of a lack of marketing acumen"
This would be my point of view in the past.In fact, communication e.g. email, 
Mattermost, etc. is a marketing tool.Git communication is Github. Note that 
I've NEVER said that Github is a part of Git !

d) About Git : nope Git was adopted because of his features in the 
beginning.The famous Linux lets Git grows faster. Github consolidate git first 
place.

e) And of course as you said, things don't ALWAYS work.
3/ For the record, I've got NO interest inside MatterMost.My thought is that 
nice project deserve nice communication tools, not for marketing but for a more 
efficient communication between Fossil users.
4/ About Yahoo discuss :No I won't change my email because of a "bounce 
notification". "Bounce notification" does not bother me at all.For 
communication reason, I rise the issue, so the Fossil Team should be warned.
The issue seems to be the fact that the mail man software sends email that is 
owned by yahoo.That behavior is forbidden by serious companies, because of 
phishing risks, etc., and Mailman should take that into account seriously.

To sum up my point of view :When one can't use a tool as it should be, it is 
bad communication : may be a lack of something.Behind the scene the Fossil 
website were down : drh said "NEVER happened". I said that it's a security 
issue : xinetd should not be used because it might be a security breach (I've 
learn that few years ago).Whatever is your project, you will need a marketing 
tool, and most of the time most of the basic tools : it is not about money, it 
is about Future [of the project].


Best Regards

K.
  De : Scott Robison <sc...@casaderobison.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Lundi 17 octobre 2016 15h56
 Objet : Re: [fossil-users] disabled due to excessive bounces (again?)
   
On Oct 16, 2016 6:35 PM, "K. Fossil user" <ticketpersonnal-fos...@yahoo.fr> 
wrote:
>
> I am angry because Fossil knows nothing about marketing which is bad for any 
> project...If I may paraphrase, Fossil's benevolent dictator has stated many 
> times in the past that the One True Purpose (TM) of Fossil is to serve SQLite 
> development. The fact that others find it nice for their use is a happy 
> coincidence.I think the point of marketing can be interpreted a couple 
> different ways.One, in some organizations marketing drives development. This 
> is done to make more money or to try to be all things to all people. Since 
> Fossil is FOSS money is not an issue. Since DRH has a pretty clear vision of 
> what he wants Fossil to be, he explicitly does not want it to be all things 
> to all people. He's not opposed to allowed enhancements that he doesn't use 
> himself as long as they don't conflict with his core DVCS principles.Two, 
> pure marketing, from the perspective of informing people of the option, is 
> not a strength of most FOSS projects. Evangelism is similar but different. I 
> would state that Linus Torvalds isn't a great marketer either, but that 
> didn't stop the Linux kernel from gaining mind share. It just happened to 
> come at the right time and became huge IMO based on the FUD surrounding BSD 
> at the time. That git is popular is almost exclusively an artifact of Linux 
> popularity, not brilliant marketing.In similar fashion, SQLite started as a 
> solution to a problem it's author was having. It was shared, and it grew in 
> popularity. From a dev perspective it's arguably not as interesting as Linux 
> (there are more subprojects of Linux for a dev to try to hack on if they 
> want), but it has gained mind share in its space. The fact that SQLite is a 
> smaller scope project than Linux parallels the relative mind share of Fossil 
> vs git. Not to mention the cottage industry of projects that exist to make 
> git more usable, which is arguably not as necessary for Fossil.I don't 
> believe you're trying to be offensive in your use of words, but I have a hard 
&

Re: [fossil-users] disabled due to excessive bounces (again?)

[K. Fossil user]

Hi,
1/a) "It is possible that Yahoo is
blocking the e-mails due to much mail"
May be. I've received many mails from other website but nothing like that.
b) "It is also possible that Yahoo is refusing some kinds of attachments"
May be, however i do receive any kind of attachments.
c) "I
would suggest you go to your subscription settings for the mailing list
and disable attachments"
Something I won't do : attachments have got nice info sometimes especially 
patches... and sometimes signatures.At least do what you can as you've said and 
think.Then we will see if a change could be done.
2/"You should not attribute mail server communication issues as malice. If
the administrators wanted you gone they could outright ban and block
your e-mail address"
:-D
a) Nothing seems to show us that there is any malice, at least here nothing I 
point out that it should not occur: it is bad for the Fossil future.However I 
agree that it is necessary for you to inform people about this e.g. your talk 
about malice.b) People could be banned, and I know someone in another website 
that was banned.It's something I never recommend unless there is a serious 
jeopardy such as illegal way of conduct or something that may tend to that.c) 
Honestly people here are really respectful, may be some of them are not but 
that doesn't bother me.d) And I dare to say that Fossil team does a nice job in 
general, however they act like stupid people when it comes to something outside 
the computer reality...(A geeky attitude i suppose ?)

3/ Try to see if it is because Fossil send something that is supposed to be 
from Yahoo ?They would like to avoid phishing issue for example ?

4/ BTW thank you for your advice and your job.I don't think that you can do 
anything but who knows...

Best Regards

K.

  De : Steven Gawroriski <ste...@multiphasicapps.net>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Dimanche 16 octobre 2016 12h08
 Objet : Re: [fossil-users] disabled due to excessive bounces (again?)
   
On Sun, 16 Oct 2016 03:27:02 + (UTC)
"K. Fossil user" <ticketpersonnal-fos...@yahoo.fr> wrote:

> Hi again,
> Ah I forgot something like this :
> "Your membership in the mailing list fossil-users has been disabled
> due to excessive bounces The last bounce received from you was dated
> 16-Oct-2016.  You will not get any more messages from this list until
> you re-enable your membership.  You will receive 3 more reminders like
> this before your membership in the list is deleted.
> "

I would check all of the e-mails you have received and compare them
with the archive on the mailing list site. It is possible that Yahoo is
blocking the e-mails due to much mail (anyone from a Yahoo address
will get a copy of the mails).

It is also possible that Yahoo is refusing some kinds of attachments,
which do appear in the mailing list, and is blocking those e-mails. If
none of your e-mails from the mailing list have attachments then I
would suggest you go to your subscription settings for the mailing list
and disable attachments.

> When it comes to mailman... not astonished.
> The message one could read could be "Hey you hurt us !".Now I
> understand that the issue the other day is not fixed. The same in
> fact.

You should not attribute mail server communication issues as malice. If
the administrators wanted you gone they could outright ban and block
your e-mail address. That would be far more effective and more
efficient than recompiling the mail server to create fake bounce
notices on your account.
___
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] disabled due to excessive bounces (again?)

[K. Fossil user]

Hi,
Hostile ? You don't know what it is hostility then...Someone who is a bit 
hostile won't write here unless he is a bit moronic in his mind...And of course 
he won't give any advice.
Of course he would tell everyone that Fossil is a very bad Team with a very bad 
product.May be you would like me to say that around ? Yes I can, but I may 
not.I am angry because Fossil knows nothing about marketing which is bad for 
any project...
I must admit it : I was wrong when I taught that Fossil have basic knowledge of 
marketing.
And yes sir, it will be hard to try to convince people to use Fossil after what 
I've read.We both agree at least that you haven't read/didn't understand what 
I've said in my previous thread, have you ?
Serious people don't like pessimistic message, but I, like many serious people, 
prefer Truth even if it is said with very brutal and rude way.I guess what I've 
wrote is really brutal for you...

Of course, if you've got nice advice to all of us, at least for me, share it.

I've got an advice for you : because I am so wrong why don't you try to ask 
your friends in real life (not here) about this :"What do you think guys about 
a project who knows nothing about marketing ?"Or at least if you do think that 
it is untrue (let me laugh) ask:"What do you think guys about a project who 
knows blatantly about marketing ?"
And because you are SO honest then ask this :"Is the guy who have noticed that 
wrong or not ?"
Are you still honest with us ? Yes ? Then share it here...
Remember what I've said ? Everyone prefer the Truth.
To sum up what I've said in previous thread :Because there is no reason for 
people to use Fossil, then it is necessary to have a better marketing 
approach.A poll is a beginning of a marketing approach. Everyone seem to 
disagree with the poll I've asked.
Then I've given some good reasons why polls should occur, such as a compilation 
issue I've never seen before. And WE ALL see that there were few days ago some 
compilation issue with the Windows OS realm. Which is a shame in my point of 
view.

Would you dare to say what I've sum up above ? I do recommend not, but it's up 
to you sir.

Best Regards

K.

  De : Joerg Sonnenberger <jo...@bec.de>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Dimanche 16 octobre 2016 14h27
 Objet : Re: [fossil-users] disabled due to excessive bounces (again?)
   
On Sun, Oct 16, 2016 at 03:27:02AM +, K. Fossil user wrote:
> Try to convince people to use Fossil after that : very hard.

Can you please take your negative and hostile attitude somewhere else?
It seems clear now that you have a number of problems on your side.
>From a mail server that doesn't work properly for whatever reason, over
a build environment you don't want tell us about to whatever random FUD
you are repeating based on unnamed coworkers. I'd kindly request you to
follow basic rules of productive communication. If you have a problem
and you don't want it solved, don't bother telling us about it. If you
do want it to be improved, it doesn't help if you don't tell us what it
actually is.

Joerg
___
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

[fossil-users] disabled due to excessive bounces (again?)

[K. Fossil user]

Hi again,
Ah I forgot something like this :
"Your membership in the mailing list fossil-users has been disabled due
to excessive bounces The last bounce received from you was dated
16-Oct-2016.  You will not get any more messages from this list until
you re-enable your membership.  You will receive 3 more reminders like
this before your membership in the list is deleted.
"

When it comes to mailman... not astonished.
The message one could read could be "Hey you hurt us !".Now I understand that 
the issue the other day is not fixed. The same in fact.

Try to convince people to use Fossil after that : very hard.


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] www.fossil-scm.org down? security issue ?

[K. Fossil user]

Security issue ?Ah yes, security is not the first target for Fossil.
I was told by a security computer specialist that we should NEVER use xinetd, 
xinitd or something related...Of course, for the Fossil team, people I do know 
are not good enough ...

:-D (One day I was wondering if downloading Fossil is safe... I've got my 
response now. This is why I laugh out loud)
The only good news is that someone dare to say there is an issue.You should 
thank him.
Pray that your system was/is not hacked ...


Best Regards

K.

  De : Richard Hipp <d...@sqlite.org>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Dimanche 16 octobre 2016 1h55
 Objet : Re: [fossil-users] www.fossil-scm.org down?
  


FWIW, sqlite.org was also down (since it is on the same machine and
uses the same xinetd process to respond to requests, but nobody bother
to report that

On 10/15/16, Richard Hipp <d...@sqlite.org> wrote:
> On 10/15/16, Johan Kuuse <jo...@kuu.se> wrote:
>> Hi,
>>
>> I cannot acces www.fossil-scm.org
>> Anyway, www.fossil-scm.org:8080 responds, so it seems to be a problem
>> with the web server.
>
> xinitd, which manages inbound connections on port 80, had crashed.  I
> restarted it.  Things should be working again.  Thanks for the report.
> I had not noticed it before because I always use https instead of
> http.
>
> https on port 443 is managed by stunnel4.  It was still running.
> Apache manages port 8080 and it was still running.  Backup servers at
> http://www2.fossil-scm.org/ and http://www3.fossil-scm.org/ were both
> still running.
>
> --
> D. Richard Hipp
> d...@sqlite.org
>


-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on HN

[K. Fossil user]

re 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.


Be

Re: [fossil-users] autosetup: hidden autoconf/automake compatibility

[K. Fossil user]

Hi,
"They just add overhead
to debugging build problems for no good reason"

Not necessary an issue.Some people would like more verbosity, some others no 
verbosity.However, if you don't want those options, don't use them :-)
In debian realms, those options are most of the time used and I agree with 
that.  
Best Regards

K.

  De : Joerg Sonnenberger <jo...@bec.de>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Samedi 15 octobre 2016 23h02
 Objet : Re: [fossil-users] autosetup: hidden autoconf/automake compatibility
   
On Sat, Oct 15, 2016 at 01:01:17PM +0900, Osamu Aoki wrote:
> As I see output of "./configure --help" on autoconf/automake based code,
> I see the following:
> 
>  --enable-silent-rules  less verbose build output (undo: "make V=1")
>  --disable-silent-rules  verbose build output (undo: "make V=0")

Frankly, I find those rules supremely annoying. They just add overhead
to debugging build problems for no good reason.

Joerg
___
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] autosetup: hidden autoconf/automake compatibility

[K. Fossil user]

Hi,
The good question is : Why don't they use autoconf/automake like most people 
do, at least CMake even if I don't agree with this ?
Snobism ? :-P (LOL)  
Best Regards

K.

  De : Osamu Aoki <aoki.os...@gmail.com>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Samedi 15 octobre 2016 4h01
 Objet : [fossil-users] autosetup: hidden autoconf/automake compatibility
   
Hi,

Here is FYI suggestion to make compatibility of autosetup to support the
system expecting typical autoconf/automake options while not killing
nice option checking feature of autosetup via --disable-option-checking.

As I see output of "./configure --help" on autoconf/automake based code,
I see the following:

  --enable-silent-rules  less verbose build output (undo: "make V=1")
  --disable-silent-rules  verbose build output (undo: "make V=0")

Also I see in autosetup/system.tcl already supports many *hidden*
options for autoconf/automake compatibility.  Why not add one more
hidden option support for "silent-rules"?

Regards,

Osamu

FYI: back ground info

Here is the analysis of Debian packaging.

Since autosetup behaves very much like autoconf/automake, the current
Debian package maintainer sets standard autoconf/automake build options
using Debian default build infrastructure to build binary package.
Unless --disable-option-checking is used to invoke ./configure, binary
package build fails as:

| ...
| Checking for stdlib.h...ok
| Error: Unknown option --silent-rules
| Try: 'configure --help' for options
|        "tail -v -n +0 config.log"
| ==> config.log <==
| Invoked as: ./configure --build=x86_64-linux-gnu --prefix=/usr
| --includedir=${prefix}/include --mandir=${prefix}/share/man
| --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
| --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu
| --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
| --disable-dependency-tracking --disable-internal-sqlite --json
| --with-th1-docs --with-th1-hooks --with-tcl=/usr/lib/x86_64-linux-gnu
| --with-tcl-stubs

The Debian package maintainer currently disables option-checking via
alternative way without using --disable-option-checking.  That's anther
story.

Osamu
___
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] Fossil on HN

[K. Fossil user]

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 
 À : Fossil SCM user's discussion  
 Envoyé le : Lundi 10 octobre 2016 19h26
 Objet : Re: [fossil-users] Fossil on HN
   
On Oct 10, 2016, at 12:36 PM, Konstantin Khomoutov 
 wrote:
> 
> On Mon, 10 Oct 2016 14:49:55 -0300
> Richie Adler  wrote:
> 
> [...]
>> 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. :)

> 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.

>> 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.
___
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] Further mailing list configuration changes.

[K. Fossil user]

1/ I don't speak about human : Git users are sometimes [big] organization ...So 
I mean that subscribers COULD be organization. 519 subscribers ... NOT 
humans.To be honest, subscribers are e-mails : I could create two or three just 
for the mailing list discuss...(I could create many if I do want)You've got two 
at least here...

2/ People don't want to mess with "mailing discuss", not here (me) at least but 
I try to convince you to do the right thing.People would like to be asked : in 
the subject of this thread WE READ : "Further mailing list configuration 
changes"There are NO questions ...In a poll there are questions and choices 
given...
3/ in this e-mail, YOU've write to me, YOU can see that the "reply-to" is to 
YOUR email address, a special one you've created for me...Is it appropriate for 
you? Not for me and especially not for people who would like to give their 
opinions...As I said, the correct behavior should be : "reply-to" the Fossil 
SCM list...
4/ 
>Do you agree that  the majority of people who decided  to respond to the
>thread about  the mailing  list change  were in  favor of  restoring the
>original behavior?
That was/is not my discuss : I've respond to that in number 2) just above : 
"people don't want to mess..."

5/ Privacy
>Are people not  already able to choose? Must they  depend on the mailing
>list to provide the privacy they seek?Hmm... So we could choose between many 
>Fossil mailing list ? One with privacy, one with none, etc ? LOL !Or may be 
>every one knows how to create an e-mail with postfix/whatever you want... TLS 
>included ?I do suppose that every one could deal with NAT using 
>nfstable/iptables in a DMZ?Or I do suppose that we have the choice to use IRC 
>even if we don't want it...?I was astonished one day in the past when I've 
>seen that some developers don't even know anything about VCS ...
Or people will create a special account in a webmail (say Gmail) where they are 
asked for phone number and so on.I guess that they will be forced to buy a 
phone account so they could fill the webmail requirements...I can do that but 
I, personally, don't want that : it's unprofessional.

6/ And this :
>At any  rate, how long  should they be given  to respond? If  they never
>respond, does that  mean that they agree or disagree  with said proposed
>change?As every discuss : no opinion means ... NO opinions, and not yes or 
>no...
NO people don't want to mess with mailing list discuss, but ask them for a poll 
about future of Fossil (mailing list included) then many will read, and some 
people just answer.Ah and in a poll we give them an amount of time AND a 
reminder ...
Number 4/ suffice to answer in fact.
7/ Ask your self why I DO NOT give any informations about bugs I've found in 
the past ...I've seen some glitches that are easy to find : never fixed. May be 
these days it is...Ask your self why one guy sees some typos that are easy to 
seek : he was even asked how he found these...Ask your self why a guy who is a 
lead of a big project don't want Fossil ...
If I were a bad guy I would dare to say to the guy who talks about MatterMost : 
"Hey they don't know how to deal with a mailing list and you ask for a 
slack-like tool ? Are you stupid man ?"I want to point out that I DO NOT use 
MatterMost, but I WILL in the [near] future.

You are clever enough Andy : you could understand.Finally, I think that we 
agree to disagree.I must admit one thing : I like Fossil and I am stupid to 
like it.

I would test 1.35, because I like it, but at this level of discuss I don't 
think that I would give any information about bugs I would found : it's a lose 
of time I don't want to deal with.I guess that someone will found them...

Thank you for reading.

Best Regards

K.

  De : Andy Bradford 
<amb-sendok-1469821765.fappjflkogdfbmcmj...@bradfords.org>
 À : K. Fossil user <ticketpersonnal-fos...@yahoo.fr> 
Cc : Fossil SCM User's Discussion <fossil-users@lists.fossil-scm.org>
 Envoyé le : Mercredi 29 juin 2016 21h49
 Objet : Re: [fossil-users] Further mailing list configuration changes.
   
>Thus said "K. Fossil user" on Tue, 28 Jun 2016 20:51:29 -:
>
> 1) if numbers count, then 5 is not sufficient in front of 519, and 519
>> is not sufficient either in front of the numerous GIT users...
>519 subscribers does not mean 519 humans.
>At any  rate, how long  should they be given  to respond? If  they never
>respond, does that  mean that they agree or disagree  with said proposed
>change? Given the  implications of your terms, I would  submit that this
>list should have never changed configuration in the first place, because
>a ``poll'' to discover whether or  not the ``community'' supports such a
>change would likely have been as similarly ignored by 500+- subscribers.
>Do you agree that  the majority o

Re: [fossil-users] Further mailing list configuration changes.

[K. Fossil user]

Ah...Let's play YOUR game then.People ask for something then you ask others to 
follow because it seems that most people (let say : five or more?) guys speak 
about it ?And of course those guys are EXPERT (or I suppose according to you or 
the fossil team or whoever you want) so everyone should follow ?Hmm strange.
I've read somewhere that we are 519 ... Right ?
1) if numbers count, then 5 is not sufficient in front of 519, and 519 is not 
sufficient either in front of the numerous GIT users...
2) if experts point of view count, then this example I've experienced myself 
will help you to think :One day I've told a guy that Fossil is a good thing... 
It must be have a try.After discussion he said : no for technical reason. He 
just asked me if I've heard about some VCS project he quoted. I said no.You 
[Andy] could say that at this stage of my talk it is not interesting and a bit 
stupid, I would agree with you.
Unfortunately for you the guy is a lead of a very big project (SQLite is a 
little one)...Do you know what kind of VCS needs a big and serious project ? Of 
course you do...
So ...

to sum it up)
It is not because I do like what you've write most of the time that it means 
that I will/would say YES to whatever you said...IMHO a serious project 
respects people's privacy, so it doesn't even show up any information : 
anonymity is the key !
I've just say : "let people choose if they want to show anything about them or 
not". Even that makes people angry (really ? You, people, are angry about 
privacy ?).Finally, to reduce some guys anger, I ask for a serious poll. A 
serious poll means that every explanations should be provided, especially about 
pros and cons ... Of course, the subject it-self have the word "poll" inside.MY 
game is about the poll...

How could I convince people to use Fossil if even a poll is an issue,or worst 
irrelevant ?


Best Regards

K.

  De : Andy Bradford 
<amb-sendok-1469675137.ehjibpjdkmnieipof...@bradfords.org>
 Cc : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org>

Thus said "K. Fossil user" on Mon, 27 Jun 2016 20:10:53 -:

> I don't understand  why the Fossil team don't create  a poll about the
> Mailing list behavior people may want?

Are the responses not sent to  the previous thread regarding the changes
sufficient?

Andy
--
TAI64 timestamp: 40005771e99f


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

[fossil-users] Your membership in the fossil-users mailing list is currently disabled due to excessive bounces

[K. Fossil user]

Hello again,
I've received that message :"Your membership in the fossil-users mailing list 
is currently disabled due to excessive bounces" 
That's not serious ... ><

 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] Further mailing list configuration changes.

[K. Fossil user]

I don't understand why the Fossil team don't create a poll about the Mailing 
list behavior people may want ?Is it so hard to do ?
The main reason i've read, that people said, was : "Dear Fossil, we could not 
filter so don't change the first behavior".My filters run correctly why not the 
others one ? I even could create a special filter for drh if I which that ...
As I said, if people would like to be known , just put your details and that's 
it...
I read that some people would like that the old behavior is set just because 
they would like it to run with Gmane...Is that serious ? And if I ask that I 
would like it to run with a-special-tool-we-do-use-here because I like it, 
would Fossil do what I ask ?Oh, am I asking too much ?Oh sorry, let's say I ask 
for a google user group that is nice in some extent. Would Fossil change for 
that even if more people would like to use it ? Of course not.
Not clear enough ? If the Fossil team would like to be seen, I should see 
Fossil in Google (search and so on) ...It is not the case. No one around me use 
Fossil, and precisely they haven't hear about it...Surprisingly everyone uses 
SQLite (Firefox, etc.) and some people knows about SQLite...

And if I ask for MatterMost - THE future - would Fossil follow us ? Of course 
not ...
Most of us would like to stay with mailing list, me included, but it is *not* 
THE future !
To sum it up, it is not because someone ask for something (Gmane, MatterMost, 
etc) that you decide to follow it, unless you do create a serious poll about 
it.One of the goal of a serious project must be the future of it (is a project 
whose VCS is CVS the future? Not for me...) and the related way to 
discuss/communicate/etc. (Which communication is the future? etc.).
 Best Regards

K.

  De : Gour <g...@atmarama.com>
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Lundi 27 juin 2016 7h50
 Objet : Re: [fossil-users] Further mailing list configuration changes.
  


On Mon, 27 Jun 2016 14:05:28 +0800
Barry Arthur <barry.art...@gmail.com>
wrote:

> I'm glad to hear that.

However, we do not know the number of subscribers via Gmane - I'm the
one and survived. :-)


Sincerely,
Gour

-- 
Before giving up this present body, if one is able to tolerate
the urges of the material senses and check the force of desire and
anger, he is well situated and is happy in this world.


___
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] Fossil :: typos

[K. Fossil user]

Hi,
People read docs : this is one way to find typos... :-)just sayin' 
Best Regards

K.

  De : Richard Hipp <d...@sqlite.org>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mardi 21 juin 2016 20h04
 Objet : Re: [fossil-users] Fossil :: typos
   
On 6/21/16, Svyatoslav Mishyn <j...@openmailbox.org> wrote:
> Hi, just found a few typos.

Fixed now.  Thanks.

How did you find these?  Are you reading through the code line by line?

-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] some e-mails goes to the spam box

[K. Fossil user]

Hi,

It seems that some mails goes to the spam box...
I've noticed this when it comes to David Simmons e-mail.
Did someone have this issue ? Could it be fixed ?

 
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] Should mail be seen or not ?

[K. Fossil user]

It is strange to me to see my mail in your mailing list response.Is it not 
supposed to be hidden ? Even for respect to people privacy ?
I'm asking because suppose that I don't want to be spammed because of this, it 
would be hard to stop spams, even with appropriate tools...  
Best Regards

A.___
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 server commit and other hooks?

[Srikumar K. S.]

Hi,

I'd like to know how to setup commit hooks on a fossil server
so that, for example, I can perform an automatic checkout,
run tests and restart a server. I intend to use this for
deploying projects on a server - sort of like heroku's
deploy using git push.

This has come up a few times in the past iirc, but I'm not
sure whether there is any resolution on whether fossil will
ever accept to support this and if so in what form it might 
take.

I'd like to propose something that (afaik) has not been
proposed --

Expose fossil server activity in the form of hook URLs
to which information about the activity is sent by POST
with the body in JSON format. With this setup, it would
be possible to code up a hook client in, say, node.js
which can respond appropriately.

So, for example, if trunk just got a new commit, and
a hook URL root of http://localhost:/myserver/;
is registered, then a POST to http://localhost:/myserver/commit;
is made with the body something like -

{branch:trunk, commit:longhexSHAid, comment:some text, ...}

Multiple such root URLs may be registered. In case connection
to one fails, it can be simply ignored.

I think there would be no need for the fossil server
to wait for the post action to complete before continuing
with whatever it needs to do (though I admit I haven't thought
that through).

Thoughts?
-Kumar




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] I do want open --keep to be possible with updates [solved]

[K. Fossil user]

I've found the appropriate response finally:

1/ In most cases :

fossil pull
OR
fossil pull --user aFossilValidUser

2/ For those who own a server and do want to pull AND push :
fossil sync
OR
fossil sync --user aFossilValidUser

Note that, fossil update -n do nothing of course... :-)

 
Best Regards


K.

Themba Fletcher wrote :



'fossil update -n' will just show you what would change if you ran fossil 
update. 

'fossil sync' will just sync the repo and not make any changes but not make any 
changes to your checkout. Fwiw, I believe update with -n syncs as well. 

Hth,

T

On Thursday, February 21, 2013, K. Fossil user  wrote:



Hello,


fossil open myrepo.fossil --keep
fossil update
 ## updates downloads files and they are stored in the current directory.


Can't fossil do something like :
fossil update --keep

# so NO files are written in the current directory ?

 
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] I do want open --keep to be possible with updates

[K. Fossil user]

Hello,

fossil open myrepo.fossil --keep
fossil update
 ## updates downloads files and they are stored in the current directory.

Can't fossil do something like :
fossil update --keep

# so NO files are written in the current directory ?

 
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] 101 entries... when it should be 200...

[K. Fossil user]

Hello again,

Click on Timeline
then click on tags: trunk
finally click on button 200 entries
I can read 101 entries... when it should be 200...
Two buttons appear [20 entries], which is correct and [200 entries] that should 
not exists...


date in the bottom is 2013-01-03 22:33


 
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] 101 entries... when it should be 200...

[K. Fossil user]

1/ it is the fossil repository... :-)

$ fossil dbstat


repository-size:    40726528 bytes (40.7MB)
artifact-count: 19750 (stored as 5624 full text and 14126 delta blobs)
artifact-sizes: 52103 bytes average, 4993770 bytes max, 1028938476 bytes 
(1.0GB) total
compression-ratio:  25:1
checkins:   4981
files:  755 across all branches
wikipages:  25 (285 changes)
tickets:    994 (3163 changes)
events: 4
tagchanges: 504
project-age:    2030 days or approximately 5.56 years.
project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
fossil-version: 1.25 2013-02-08 09:37:10 [fab09a1710] (gcc-4.5.2)
sqlite-version: 2013-01-17 17:20:49 [38852f158a] (3.7.16)
database-stats: 39772 pages, 1024 bytes/page, 5109 free pages, UTF-8, 
delete mode


2/ may be this can solve it ?
File is : src/timeline.c 

line 1359, change it to :
  else if( nEntry200 ){


 
Best Regards


K.


Stephan Beal wrote :


On Fri, Feb 8, 2013 at 2:44 PM, K. Fossil user wrote:

I can read 101 entries... when it should be 200...
Two buttons appear [20 entries], which is correct and [200 entries] that 
should not exists...


Does your repo have more than 101 entries?

What does the output of:

fossil dbstat

say?
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] 101 entries... when it should be 200...

[K. Fossil user]

1/ else does not break here... :-)

It runs as expected...
(if entries are over 20 then 20)

2/ Depending on the trunk I click on, it may say 14 or 15 or 11...
14 timeline items related to trunk occurring around 2013-02-07 15:28:18 
 
Best Regards


K.




 De : Stephan Beal sgb...@googlemail.com
À : Fossil SCM user's discussion fossil-users@lists.fossil-scm.org 
Envoyé le : Vendredi 8 février 2013 14h25
Objet : Re: [fossil-users] 101 entries... when it should be 200...
 

On Fri, Feb 8, 2013 at 3:14 PM, K. Fossil user 
ticketpersonnal-fos...@yahoo.fr wrote:

1/ it is the fossil repository... :-)

Doh.
 
2/ may be this can solve it ?
File is : src/timeline.c 

line 1359, change it to :
  else if( nEntry200 ){


An else there would break if (nEntry20  nEntry200).

      if( nEntry20 ){
        timeline_submenu(url, 20 Entries, n, 20, 0);
      }
      if( nEntry200 ){
        timeline_submenu(url, 200 Entries, n, 200, 0);
      }

What you're seeing seems to be a side-effect of the related to (r=trunk) math 
(note that the title of the page is related to trunk occurring around). If 
you change r=trunk to b=trunk then you see the 200 you are expecting.
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] 101 entries... when it should be 200...

[K. Fossil user]

1/ at most 200 entries
Ah ok...

2/ Is it possible that you put a tooltip when the mouse is hovering ?
(at most 200 entries, for example)

3/ Thanks for the b=trunk...
I was wondering *if* it should not be b=trunk then...

 
Best Regards


K.

Richard Hipp wrote :




On Fri, Feb 8, 2013 at 8:44 AM, K. Fossil user 
ticketpersonnal-fos...@yahoo.fr wrote:

Hello again,


Click on Timeline
then click on tags: trunk
finally click on button 200 entries


That button really means at most 200 entries but that is too much text for a 
button, so it is abbreviated to just 200 entries.

 
I can read 101 entries... when it should be 200...
Two buttons appear [20 entries], which is correct and [200 entries] that 
should not exists...



date in the bottom is 2013-01-03 22:33

 
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




-- 
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: [fossil-users] 101 entries... when it should be 200...

[K. Fossil user]

1/ I agree with the 20-200, but my idea is this :
I would like to know which button I've pressed: 200 or 20 ? (it doesn't matter 
if n=100)
Never mind, this is not that important for me.
It could be that important for some people...

2/ The timeline variant is strange, because I've thought that if I click the 
FIRST trunk then it should say 200... not 101...
But maybe, the number of lines are 200 but the trunk IS only 101 ?
If it is the case, I like it... However, it seems not.
I don't know...


 
Best Regards


K.




Stephan Beal wrote:


Try this:

http://fossil-scm.org/index.html/timeline?n=100

With the else, the 200 entry would not appear there.

2/ Depending on the trunk I click on, it may say 14 or 15 or 11...
14 timeline items related to trunk occurring around 2013-02-07 15:28:18 

Because the around time depends on the commit time of the link you are 
clicking, which changes the results returned by that particular timeline 
variant.
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal___
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] I suggest a lite release of fossil so --static could be used

[k]

on Feb 01, 2013, Stephan Beal sgb...@googlemail.com wrote:


I'm not sure if I understand what's being said, but if I do, I would disagree 
that
Fossil sans networking support would be nearly useless.




I use Fossil locally exclusively. I may be in the minority. I do not know.

Nearly meaning essentially for everyone who uses it with remote repos AND 
everyone
who uses the built-in UI, which covers the vast majority of users. Since the 
whole
UI is an HTML interface, networking is more or less implied. Without the 
networking
support fossil server and fossil ui could not work.

Good point. As I use fossil UI, I do actually use its networking facilities.


The issue of static linking is not an app-level problem, it's an 
environment-level
problem. Fossil aims to be as platform-neutral as possible and, like the C 
standard
itself, does not address the minutia of platform-specific quirks like dynamic 
vs
static linking. i apologize if i seem a bit riled up/annoyed about this, but 
the
OP keeps asking (trolling, it seems!) again and again, despite being given 
plentiful
information and links where he can follow up on it, why can't I build this 
statically?
The answer (again) is you _can_, but on Linux, Solaris 10/OpenSolaris, and 
possibly
other platforms, you _will_ run into platform-level limitations which we 
cannot fix
at the application level.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/http://gplus.to/sgbeal

While I use SQLite statically, Fossil I do not. I look at Fossil as a user 
level program and SQLite as a library.
^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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

Hello,

1/ Thank you very much Edward Berner. You rock my world.
Of course, embedded system must use light libc...
I've seen that some software uses dietlibc.
In my point of view, static linking can be done in this area, so it will be 
easier to spread Fossil everywhere with network support.

2/ I find that strange that a software needs manifest fix to compile without 
errors.
I agree with you that maybe it is what I've done (fossil close) that may did 
this...


3/ Could you help Fossil team with dietlibc ?

4/ Crashing...
I do compile Fossil in Porteus to unsure that _if_ it is possible to compile in 
Porteus, it will be possible EVERYWHERE to compile it WITHOUT issues.
I do use Porteus 64 bit for that purpose. And I do run the resulting binary in 
Porteus 64 bit either... :-)
The Crashing thing occur when I do compile with --static option...

5/ Question: why is it a DNS resolver issue ?

 
Best Regards

K.

Edward Berner wrote :
I think that for static linking on Linux you may need to look at what 
the embedded Linux folks are doing.  I think the alternate libc 
libraries (musl libc, uclibc, dietlibc, etc.) have static linking as an 
explicit design goal.

-- Edward Berner


On 1/31/2013 12:35 PM, K. Fossil user wrote:
 Hello all of you,

Hello.

 2/ serious issue
 I've downloaded today's timeline trunk:
 $ ./configure --prefix=/usr --sysconfdir=/etc \
 --with-openssl=none \
 --static \
 --json \
 --markdown
 $ make
 ## all seems ok !
 $ sudo make install
 $ fossil open fossil.fossil
 $ fossil update
 Autosync:  http://www2.fossil-scm.org/
 Segmentation faultrtifacts sent: 0  received: 0

I'd guess that it's crashing in the DNS resolver, although I wouldn't expect it 
to crash if it is running on the same host it was built on.  I played with the 
static linking stuff a while back and I think I saw this behavior when I 
compiled on a 64 bit Ubuntu and ran on a 32 bit, or something like that.

 $ fossil close fossil.fossil

The fossil close caused the problem below...

 
 ## delete all the files...
 
 $ ./configure --prefix=/usr --sysconfdir=/etc \
 --with-openssl=none \
 --json \
 --markdown
 $ make
 make: *** No rule to make target `src/../manifest.uuid', needed by 
 `bld/VERSION.h'.  Stop.

If a repository's manifest setting is on then the manifest and 
manifest.uuid files are included in the checkout directory when a repository 
is opened with fossil open (and in the files created by the fossil zip and 
fossil tarball commands).  But they're removed by fossil close.

Fossil requires the manifest and manifest.uuid files to build, so you'll 
need to get them back.  Running fossil open again would probably do it.

--
Edward Berner___
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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

Hello everyone,


Can't we use GnuTLS instead of openSSL ?
Wget decided to use GnuTLS instead of openSSL...



Best Regards


K.


D. Richard Hipp wrote:
K. Fossil user  wrote:

People would like to use a DVCS everywhere with any distro with the SAME 
binary, not the one specific to a distro.



I concur.  Unfortunately, this is a function of the distro more than of the 
application.  For example, OpenSSL seems to not support static linking and is 
also highly distro-dependent, so a universal binary needs to omit HTTPS 
support.  So there are tradeoffs. 

Fossil has traditionally worked great on all systems, directly from sources.  
And the binaries are highly portable (module OpenSSL issues).  Have you seen 
otherwise?___
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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

Hello all of you,

 

1/ Jan Nijtmans wrote:
I agree with others' remarks, that --static doesn't
make sense on modern systems any more.

I do not agree with such statement.
Static is important because mostly we do use two or more systems.
(debian and centos for example)
Darcs is static and runs everywhere... (at least for me)


 

2/ serious issue

I've downloaded today's timeline trunk:

$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=none \
--static \
--json \
--markdown
$ make

## all seems ok !

$ sudo make install
$ fossil open fossil.fossil
$ fossil update
Autosync:  http://www2.fossil-scm.org/
Segmentation faultrtifacts sent: 0  received: 0

$ fossil close fossil.fossil


## delete all the files...


$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=none \
--json \
--markdown
$ make 
make: *** No rule to make target `src/../manifest.uuid', needed by 
`bld/VERSION.h'.  Stop.


## delete all the files...

## install OpenSSL...

$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=none \
--json \
--markdown
$ make 
## ...
HTTPS support enabled
Checking for readline/readline.h...not found
Checking for editline/readline.h...not found
Checking libs for gethostbyname...none needed
Checking libs for socket...none needed
Checking libs for iconv...none needed
Checking for getpassphrase...not found
Checking libs for getpass...none needed
Checking libs for dlopen...-ldl
Created Makefile from Makefile.in
Created autoconfig.h
make: *** No rule to make target `src/../manifest.uuid', needed by 
`bld/VERSION.h'.  Stop.


If someone could explain me it would be great.
I've seen these issues yesterday, however I decided to wait today for another 
more recent source.
(fossil update)

 
 

Best Regards


K.

Jan Nijtmans wrote:


2013/1/30 Jan Nijtmans jan.nijtm...@gmail.com:
 The $tclconfig(TCL_LIBS) contains the -ldl, but
 $tclconfig(TCL_STUB_LIB_SPEC) does not, which is
 OK. (the stub library doesn't use dlopen, fossil does)

 Somehow, fossil should add -ldl here, such that the
 --with-tcl-stubs option works in combination with --static.

 Regards,
           Jan Nijtmans

Fix committed. On most platforms --static should work
again. I still have problems on Ubuntu AMD64, when
using --static in combination --with-tcl-stubs option
(even with the fossil_strcmp macro), but I really
wonder who would want this: A static fossil
binary with dynamically loading libtcl

I agree with others' remarks, that --static doesn't
make sense on modern systems any more.

Regards,
      Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___
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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

Hello,

copy error in my last mail:
correct copy is below :


$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=auto \
--json \
--markdown
$ make 
## ...
HTTPS support enabled
Checking for readline/readline.h...not found
Checking for editline/readline.h...not found
Checking libs for gethostbyname...none needed
Checking libs for socket...none needed
Checking libs for iconv...none needed
Checking for getpassphrase...not found
Checking libs for getpass...none needed
Checking libs for dlopen...-ldl
Created Makefile from Makefile.in
Created autoconfig.h
make: *** No rule to make target `src/../manifest.uuid', needed by 
`bld/VERSION.h'.  Stop.

 
 

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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

$ fossil update ba86c859df
checkout: ba86c859dff83e89640091ea18dec5571630af2a 2013-01-31 18:12:54 UTC
tags: trunk
comment:  Added an extern to work around a duplicate-definition linking
  error with the tcc compiler. (user: stephan)
changes:  None. Already up-to-date
$ fossil set manifest on
$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=auto \
--json \
--markdown
$ make

## all compiles correctly, but next is a new issue:

$ ./configure --prefix=/usr --sysconfdir=/etc \
--with-openssl=none \
--static \
--json \
--markdown
$ make 
## ...
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H  
-I. -I./src -Ibld -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0 
-DSQLITE_DEFAULT_FILE_FORMAT=4 -DSQLITE_ENABLE_STAT3 
-Dlocaltime=fossil_localtime -DSQLITE_ENABLE_LOCKING_STYLE=0 -c ./src/sqlite3.c 
-o bld/sqlite3.o
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H  
-I. -I./src -Ibld -Dmain=sqlite3_shell -DSQLITE_OMIT_LOAD_EXTENSION=1 -c 
./src/shell.c -o bld/shell.o
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H  
-I. -I./src -Ibld -c ./src/th.c -o bld/th.o
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H  
-I. -I./src -Ibld -c ./src/th_lang.c -o bld/th_lang.o
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H  
-I. -I./src -Ibld -c ./src/cson_amalgamation.c -o bld/cson_amalgamation.o
cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN  -g -O2 -DHAVE_AUTOCONFIG_H -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/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/doc.o bld/encode.o bld/event.o bld/export.o bld/file.o bld/finfo.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_tag.o bld/json_timeline.o bld/json_user.o bld/json_wiki.o bld/leaf.o 
bld/login.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/pivot.o bld/popen.o bld/pqueue.o bld/printf.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/skins.o bld/sqlcmd.o bld/stash.o bld/stat.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/update.o bld/url.o 
bld/user.o bld/utf8.o bld/verify.o bld/vfile.o bld/wiki.o bld/wikiformat.o 
bld/winhttp.o bld/wysiwyg.o bld/xfer.o bld/xfersetup.o bld/zip.o bld/sqlite3.o  
bld/shell.o  bld/th.o  bld/th_lang.o    bld/cson_amalgamation.o -static -lz -ldl
bld/shell.o: In function `find_home_dir':
./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
bld/http_socket.o: In function `socket_open':
./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking

 
Best Regards


K.



Stephan Beal wrote:

I've downloaded today's timeline trunk:
...$ fossil open fossil.fossil
$ fossil update
Autosync:  http://www2.fossil-scm.org/
Segmentation faultrtifacts sent: 0  received: 0


Can you give us more info on that, e.g. the version hash and perhaps a 
stacktrace? i've been using several builds from today, built with both tcc and 
gcc, on i386 and x64 platforms with no such problems (also updating from the 
same source as you).
 
make: *** No rule to make target `src/../manifest.uuid', needed by 
`bld/VERSION.h'.  Stop.

That one i haven't seen in such a long time that i don't recall what caused it 
nor how to fix it :/.
 
If someone could explain me it would be great.

The following is from a very old post by Joe Mistachkin:
---
A temporary workaround for this issue is to clone (or update) the Fossil
source code and update to the release tag:

        fossil update release

Then, while still in the Fossil source code directory, run:

        fossil set manifest on

This should give you the correct manifest and manifest.uuid files
needed to build the source code.
--


I've seen these issues yesterday, however I decided to wait today for another 
more recent source.
(fossil
 update)


That one with manifest.uuid has come up several times before, but i thought it 
had long since been solved. i unfortunately don't remember what causes it, 
though. Ooops... but now i've got my tree in that same

Re: [fossil-users] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

1/ GLibc and linux symbols versionning issue then...
OK, thanks.

2/ runs everywhere:
I mean, it should run in every plateform... but not cross platform of course.
It is not about java bytecode thing... :D

For example, if someone do fossil compilation with i386, then ALL i386 linux 
should be able to run fossil with no changes.
However, as you said it, we can't deal with that... Just too bad...

 
Best Regards


K.


Nico Williams wrote:

 $ ./configure --prefix=/usr --sysconfdir=/etc \
 --with-openssl=auto \
 --json \
 --markdown
 $ make


 ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
 applications requires at runtime the shared libraries from the glibc version
 used for linking
 bld/http_socket.o: In function `socket_open':
 ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked
 applications requires at runtime the shared libraries from the glibc version
 used for linking

Well yes, using gethostbyname() and getpwuid() mean using dlopen()
because that's what the name service switch in glibc does.  If glibc
were to always use nscd instead then this wouldn't happen.

Anytime you need dlopen() you need all the run-time linker/loader
machinery, and you need to be prepared to load libraries that need
pthreads, and so on.  Static linking is only really going to work well
if you avoid dlopen() altogether.

I don't understand the appeal of a binary that runs everywhere.  Or, I
do, but that's not easy anymore (and if you need multiple processor
architectures then you really can't have this, not on Linux).  On
Solaris you can achieve that because of the ABI compatibility
guarantee, as long as interfaces don't get EOFed on you.  On Linux it
ought to be the same, but because Linux depends on symbol versioning
instead of direct binding, and because symbol versioning is typically
added to libraries by the distros rather than by the open source
projects themselves... you're at the mercy of the distros.  If Linux
were to adopt direct binding then all you'd need is common run-paths
and SONAMEs, which you basically already get, and then it'd be a lot
easier to build a single dynamic-linked executable that runs close
enough to everywhere.___
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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

So you have to build an executable per-distro -- welcome to
Linux.

Is it the same with *BSD systems ?

(Thank you for your tought: it's really appreciated !)

 
Best Regards


K.

Nico Williams wrote:



 bld/shell.o: In function `find_home_dir':
 ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
 applications requires at runtime the shared libraries from the glibc version
 used for linking
 bld/http_socket.o: In function `socket_open':
 ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically
 linked applications requires at runtime the shared libraries from the glibc
 version used for linking


 These we warned you about at the start of this thread - they are
 platform-specific limitations which we can do nothing to get rid of.

Wel, you could use getenv(USER) and LOGNAME instead of
getpwuid(), or fork/exec/spawn id(1) to get the username.  And you
could use a DNS library to resolve the hostname without the benefit of
local caching (unless there's a local caching server).

The bigger problem is that this is something you'd risk having to do
again and again every time something else in glibc ends up needing
dlopen().  It's a losing battle, and even if it isn't (maybe nothing
else in glibc will ever need dlopen()), philosophically it is a losing
battle.  So you have to build an executable per-distro -- welcome to
Linux.

Nico___
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] I suggest a lite release of fossil so --static could be used

[K. Fossil user]

1/ RedHat is a company that needs to earn money.
If static compiling is used then few people may need to buy their products.
If you read what is written, it is not said IMPOSSIBLE.
It is said DISCOURAGED, which is TOTALLY not the same.
As I said, it should be possible to dynamically linking, but I NEVER said that 
it must be possible.

What RedHat said is a commercial discuss which have nothing to do with my 
discuss.
Most people do not need a total secure software because it is not relevant in 
most software.
if it is not commercial discuss for you, then tell me why I ALWAYS compile 
static EVERY TIME it is possible with EVERY software ?
Why does fsck have a static binary ? Why do I see static binary in some 
official package ?
portableapps.org have binary that runs everywhere with windows plateform... Why 
?


2/ I do compile with static option ON when it is possible.
This is evidence that RedHat is untrue.
Is it important that the binary is less bigger, less slower at startup and so 
on ? NO.
What is important for users is that it should run everywhere.
Not in a special distro which release is X.Y.Z-i786DX.
What people need is that you just open the package every where in a folder and 
do:
./commandtorunbinaryenter
and that's it.


3/ CVS is used by few people because in the past they forget to meet people's 
need.
SVN takes over them...
Now I do use git, because it is far better than subversion...


4/ We don't always need network support with SSL...
I can create the fossil file locally and then send my work via SSH (sFTP, 
etc.)...

 
Best Regards


K.

Stephan Beal wrote :

Why don't fossil create a lite version that could be static and the full one 
which will forbid the static option ?
Isn't that a good idea ?

That's like asking, why not have a fossil which has no networking support? 
and the answer is, because it would be nearly useless. On modern Linuxes the 
networking libraries require dynamically libraries at runtime (they will link 
but will emit a warning while linking and may or may not work at runtime).

The static limitations have NOTHING to do with fossil itself and EVERYTHING to 
do with the platform you are building it on.

Along with the other links people have provided you about this topic, i 
recommend reading:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib.compatibility.static.html
(read the first sentence)

http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead
(especially read the first/most highly-rated answer)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] I suggest a lite release of fossil so --static could be used

[k]

Why don't fossil create a lite version that could be static and the full one 
which
will forbid the static option ?
Isn't that a good idea ?
That's like asking, why not have a fossil which has no networking support? 
and the
answer is, because it would be nearly useless. On modern Linuxes the 
networking
libraries require dynamically libraries at runtime (they will link but will 
emit
a warning while linking and may or may not work at runtime).


I'm not sure if I understand what's being said, but if I do, I would disagree 
that Fossil sans networking support would be nearly useless.

I use Fossil locally exclusively. I may be in the minority. I do not know.

^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] I suggest a lite release of fossil so --static could be used

[K. Fossil user]

You do understand what Stephan said.

It is not what I've said, it is what Stephan said...
I agree with you.
I do not use network either...

However, my discuss is more about the fact that people do care about the way 
how they may use it without dependencies...
Less dependencies means less installs and less issue because some dependencies 
are not found or are hard to find...


 
Best Regards


K.




 De : k...@lightpowered.org k...@lightpowered.org
À : fossil-users@lists.fossil-scm.org 
Envoyé le : Vendredi 1 février 2013 0h49
Objet : Re: [fossil-users] I suggest a lite release of fossil so --static could 
be used
 


Why don't fossil create a lite version that could be static and the full one 
which
will forbid the static option ?
Isn't that a good idea ?
That's like asking, why not have a fossil which has no networking support? 
and the
answer is, because it would be nearly useless. On modern Linuxes the 
networking
libraries require dynamically libraries at runtime (they will link but will 
emit
a warning while linking and may or may not work at runtime).


I'm not sure if I understand what's being said, but if I do, I would disagree 
that Fossil sans networking support would be nearly useless.

I use Fossil locally exclusively. I may be in the minority. I do not know.

^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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] I suggest a lite release of fossil so --static could be used

[k]

on Jan 31, 2013, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote:

You do understand what Stephan said.
It is not what I've said, it is what Stephan said...I agree with you.
P.S.: Next time you received a mail from Fossil just click on the button 
called [reply
to all], otherwise I [or someone else] will the only guy that may
 receive the mail...
:-) Best Regards

K.

Yes, my mistake  apology. :) I was confused by the similarity in our name 
configuration of email. :P

^K

ps: I just did it again. The name similarity masked the real problem; your 
email address comes in the from field. I'm used to fossil-users@ being in the 
from address of mailing list emails.


 De : K k...@lightpowered.org
 À : ticketpersonnal-fos...@yahoo.fr
 Envoyé le : Vendredi 1 février 2013 0h45
 Objet : Re: [fossil-users] I suggest a lite release of fossil so --static 
 could be used



Why don't fossil create a lite version that could be static and the full one 
which
will forbid the static option ?
Isn't that a good idea ?
That's like asking,
 why not have a fossil which has no networking support? and
the
answer is, because it would be nearly useless. On modern Linuxes the 
networking
libraries require dynamically libraries at runtime (they will link but will 
emit
a warning while linking and may or may not work at runtime).


I'm not sure if I understand what's being said, but if I do, I would disagree 
that
Fossil sans networking support would be nearly useless. I personally use 
Fossil
locally exclusively.

^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] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

-DLL = Windows.
I do not use window$
-Warning does not stop compiling... :-)

-Why do I ask for --static compilation to succeed

Don't forget that if you would like Fossil to be used, it must be easy to 
compile, especially with option --static.
People would like to use a DVCS everywhere with any distro with the SAME 
binary, not the one specific to a distro.
Darcs, I've downloaded, runs everywhere...


I do use at least, Linux Mint, Porteus, Slackware, CentOS, debian...
Sometimes in Live CD mode sometimes not...

Sometimes Ubuntu.

Just sayin'


BTW, Thanks to people who tries to fix this.

 
Best Regards


K.

stephan beal wrote :


On Linux the networking-related libraries cannot be statically linked (for 
reasons i once knew but no longer recall). Or they _can_ be linked but the 
linker will warn you that it's not _really_ statically linking them and that 
the DLL will be used at run-time. Fossil's TCL support also appears to use 
dlopen(), which cannot be used in statically-linked programs (at least on 
Linux). Like networking libs, it will produce warnings like:

warning: Using 'dlopen' in statically linked applications requires at runtime 
the shared libraries from the glibc version used for linking
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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

[fossil-users] Latest stable release or dev release does not compile with option: --static

[K. Fossil user]

Hello,

Latest stable release or dev release does not compile with option:
--static
This issue occur with/without openSSL.

I would like to point you out that readline is not used.

Distribution : Porteus 1.2, 64bit.
(Slackware based live CD)

Latest stable release or dev release does not compile with option:
--static
This issue occur with/without openSSL.

I would like to point you out that readline is not used.

Distribution : Porteus 1.2, 64bit.
(Slackware based live CD)


 
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] Unintentional fork/race condition

[K]

on Jan 12, 2013, Richard Hipp d...@sqlite.org wrote:


On Sat, Jan 12, 2013 at 7:31 PM, Richard Hipp d...@sqlite.org wrote:



Loss of situational awareness is a leading cause of airplane crashes and 
medical
errors.
Here's another example of loss of situational awareness, which seems likely to 
result
in an adverse outcome:




 http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg

Love it.
^K



-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Clarification on file move being treated as file deletion.

[K]

That is great to see. So I've looked in Download and Code, and I am still not 
able to figure out how I can download a snapshot of the current source of trunk.

Please pardon what must be blindness on my part.

^K

on Dec 20, 2012, Richard Hipp d...@sqlite.org wrote:



On Thu, Dec 20, 2012 at 8:40 PM, K k...@lightpowered.org wrote:



Thank you for refining the presentation of moved-not-deleted files.



Is this code now integrated into the primary trunk,
Yes.  In http://www.fossil-scm.org/fossil/timeline?c=2012-12-18nd at 
2012-12-18 02:38 you can see where the changes were merged into trunk.



 
 or at least is that the intention? My question when I went to do commits for 
 these
moves just became, how do I ensure I continue to use the improved code.





Thanks again,

^K



on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:







On Mon, Dec 17, 2012 at 9:12 PM, K k...@lightpowered.org wrote:











However, I'm still curious why files must split upon move?



It isn't a requirement.  The page is simply showing all artifacts that 
represent
a

file with a given name.  That is one way to slice the data.  You are wanting 
to
track

a file throughout its revision history and through name changes.  That is a 
different

way to slice the data.  Both views are useful.







The file-by-name view is currently used because it is the simplest to 
implement,

in several ways.  (1) The file you want to look at has a unique name, so you 
just

include that name as a query parameter on the URL.  (2)  You can look up all 
changes

by querying the database once by that name.







File-history-through-name-changes is more complicated.  For example, how do 
you
specify

what file you want to look at in the URL.  You cannot just say file1.txt 
any more,

because two or more different files might have passed through that name 
during their

history.  I suppose you would have to specify the filename and a particular 
check-in

at which the file had that particular name.  So you have two query parameters 
instead

of one.  Then down in the implementation, it is now necessary to query the 
database

again for each name-change.  This all adds up to more complication. Since 
nobody

has (yet) requested file-history-through-name-changes, it was easier just to 
leave

it out.















Issue #1 still exists btw.



Fixed in the latest check-in.

--

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 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

___
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] Clarification on file move being treated as file deletion.

[K]

And blindness indeed. The download option may be found in check-in pages. 
Therefore the latest trunk check-in download link is found at: 
http://www.fossil-scm.org/index.html/info/55a28e7f5a

Thanks again.
^K

on Dec 20, 2012, Richard Hipp d...@sqlite.org wrote:



On Thu, Dec 20, 2012 at 8:40 PM, K k...@lightpowered.org wrote:



Thank you for refining the presentation of moved-not-deleted files.



Is this code now integrated into the primary trunk,
Yes.  In http://www.fossil-scm.org/fossil/timeline?c=2012-12-18nd at 
2012-12-18 02:38 you can see where the changes were merged into trunk.



 
 or at least is that the intention? My question when I went to do commits for 
 these
moves just became, how do I ensure I continue to use the improved code.





Thanks again,

^K



on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:







On Mon, Dec 17, 2012 at 9:12 PM, K k...@lightpowered.org wrote:











However, I'm still curious why files must split upon move?



It isn't a requirement.  The page is simply showing all artifacts that 
represent
a

file with a given name.  That is one way to slice the data.  You are wanting 
to
track

a file throughout its revision history and through name changes.  That is a 
different

way to slice the data.  Both views are useful.







The file-by-name view is currently used because it is the simplest to 
implement,

in several ways.  (1) The file you want to look at has a unique name, so you 
just

include that name as a query parameter on the URL.  (2)  You can look up all 
changes

by querying the database once by that name.







File-history-through-name-changes is more complicated.  For example, how do 
you
specify

what file you want to look at in the URL.  You cannot just say file1.txt 
any more,

because two or more different files might have passed through that name 
during their

history.  I suppose you would have to specify the filename and a particular 
check-in

at which the file had that particular name.  So you have two query parameters 
instead

of one.  Then down in the implementation, it is now necessary to query the 
database

again for each name-change.  This all adds up to more complication. Since 
nobody

has (yet) requested file-history-through-name-changes, it was easier just to 
leave

it out.















Issue #1 still exists btw.



Fixed in the latest check-in.

--

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 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

___
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] File moves reported in commit as file deletion!

[K]

on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Sun, Dec 16, 2012 at 11:56 PM, K k...@lightpowered.org wrote:



Hello,



I've done a number of fossil mv file.h source/code/ today, then issued a 
commit.
The check-in reports that all of the files I've moved have been deleted and 
renamed.



For example:



Deleted foo.c version [0e52b8b63a1e8c0d]



Name change from from foo.c to source/code/foo.c.



Why is a file I moved using fossil mv, then on the file system, being 
reported
as deleted? Now when I look at the history of the 'new' files, they don't show 
their
entire history.



The page you are looking at is probably looking at the history of files name 
source/code/foo.c. 
This is different from the history of a particular file that is currently 
named foo.c
but was formerly call by one or more different names.

I'm looking at the page for my file and its history ends as deleted when I did 
not delete it. I moved it, which fossil changes reported as a RENAMED. I 
commited and now have the surprise dumped on me that my file was deleted and 
whatever else, when it was not. This is not acceptable to lose the history of a 
file just because I MOVE it. I cannot believe this is how Fossil is operating 
and apparently is expected to operate. PLEASE JUSTIFY THIS.

^K



 



What is going wrong please?



^K

___

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

___
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] File moves reported in commit as file deletion!

[K]

As I said, I did not DELETE any files, but rather moved them. fossil changes 
reported them as RENAMED. And in the check in, they are being reported as 
DELETED. 

I'm just asking how in the design of Fossil you justified this decision. Please 
directly address this vs skirting it.

^K


on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Dec 17, 2012 at 2:55 PM, K k...@lightpowered.org wrote:





I'm looking at the page for my file and its history ends as deleted when I did 
not
delete it. I moved it, which fossil changes reported as a RENAMED. I commited 
and
now have the surprise dumped on me that my file was deleted and whatever else, 
when
it was not. This is not acceptable to lose the history of a file just because 
I MOVE
it. I cannot believe this is how Fossil is operating and apparently is 
expected to
operate. PLEASE JUSTIFY THIS.





I've very sorry that the file history report does not structure the 
information as
you would prefer.

All of the information needed to track file changes across renames is 
contained in
the repository.  And, in fact, the annotate screens do trace changes across 
renames. 
But nobody has yet taken the time to write a report screen that displays a 
file history
graph across renames.  Perhaps because nobody cares as passionately about this 
as
you seem to.  The Fossil source code is open-source; you could contribute a 
solution
if you wanted to.  



-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] File moves reported in commit as file deletion!

[K]

I don't need to make assumptions, and therefore am not. I'm going off of the 
facts, which I can observe, and which I can present to others.

The file was not deleted. It was moved using Fossil's own fossil mv command. 
It's irrational to treat this as a deletion.

If you cannot provide justification for this behavior, we should move to 
discussing the behavior Fossil should exhibit.

^K


on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Dec 17, 2012 at 3:49 PM, K k...@lightpowered.org wrote:



As I said, I did not DELETE any files, but rather moved them. fossil changes 
reported
them as RENAMED. And in the check in, they are being reported as DELETED.



I'm just asking how in the design of Fossil you justified this decision. 
Please directly
address this vs skirting it.

I would guess that when generating the DELETED text the code merely notes 
that a
file with that name is no longer part of the check-in and that the code does 
not
go to the extra trouble to figure out if the filename changed.



You seem to be making the assumption that whoever wrote that bit of code made 
a deliberate
decision to obscure the fact that the filename changed.  Why would you assume 
that?
 





^K





on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:







On Mon, Dec 17, 2012 at 2:55 PM, K k...@lightpowered.org wrote:











I'm looking at the page for my file and its history ends as deleted when I 
did not

delete it. I moved it, which fossil changes reported as a RENAMED. I commited 
and

now have the surprise dumped on me that my file was deleted and whatever 
else, when

it was not. This is not acceptable to lose the history of a file just because 
I
MOVE

it. I cannot believe this is how Fossil is operating and apparently is 
expected
to

operate. PLEASE JUSTIFY THIS.











I've very sorry that the file history report does not structure the 
information
as

you would prefer.



All of the information needed to track file changes across renames is 
contained
in

the repository.  And, in fact, the annotate screens do trace changes across 
renames.

But nobody has yet taken the time to write a report screen that displays a 
file
history

graph across renames.  Perhaps because nobody cares as passionately about 
this as

you seem to.  The Fossil source code is open-source; you could contribute a 
solution

if you wanted to.







--

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 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

___
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] File moves reported in commit as file deletion!

[K]

When some arbitrary decision/value such as a minimum length of wiki pages 
imposes itself for no rational reason on my workflow, and I'm told by the 
maintainer to maintain a separate personal branch rather than this being 
changed in the main source, I started leaving my Richard Hipp fan club card at 
home. (Which I have carried for several years now)

Then when I come across something which distorts my source code repository and 
report it, and am patronized with remarks about my passion for the issue, I 
become frustrated. My ass is on the line having strongly advocated Fossil in my 
enterprise.

I have not intended to be rude to Mr. Hipp, however I acknowledge my 
frustration could be better concealed.

I will gladly pay, given I don't have the C ability yet myself, to have this 
issue fixed. If anyone is interested in a bounty, please speak up and I'll 
articulate what I believe would be the correct behavior in this case.

^K


on Dec 17, 2012, Themba Fletcher themba.fletc...@gmail.com wrote:

On Mon, Dec 17, 2012 at 12:58 PM, K k...@lightpowered.org wrote:

 If you cannot provide justification for this behavior snip


I'm a bit confused by the tone of some of the messages on the list lately.

This could have as easily been worded as a polite bug report, but
instead comes across as aggressive and intellectually challenging.
There seem to be a lot of people ready to tell Richard that he's doing
it wrong lately, and I am starting to resent it.

I could silently unsubscribe of course, but that misses the point.
He's incredibly responsive to requests on here, and abuse leveled
directly at the primary maintainer of a piece of software does nothing
but make reading the list a job rather than a pleasure for him, to the
detriment of all of us in the end. Please watch the tone of your
posts.

Spoken without any authority, but sincerely as a fellow user of this software,

Themba Fletcher
___
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

[fossil-users] Clarification on file move being treated as file deletion.

[K]

I've been asked to clarify the confusion behavior I've run into.

$ fossil open project.fossil
project files expand into current directory as expected
$ mkdir source
$ mkdir source/code
$ fossil mv file.h source/code/
RENAME file.h source/code/file.h
$ fossil changes
MISSINGsource/code/file.h
$ mv file.h source/code/
$ fossil changes
RENAMEDsource/code/file.h
$ fossil commit
$ fossil ui


* Timeline shows project history as I expect. I click the check-in hash to view 
its details.


* I see:
Deleted file.h version [...]

Name change from from file.h to source/code/file.h.

Issue #1 is from is repeated twice.
Issue #2 is file.h is being accounted as having been deleted, when it was 
moved/renamed. For the same reason I value the inability of Fossil to have 
commits changed, I expect that the same correctness would be demonstrated here.


* Next, being concerned, I click on file.h. I see its correct file history, 
except that the most recent entry claims the file is deleted. I think, this is 
bad, what is happening?

Issue #3 is file.h in its history is accounted as having been deleted, again, 
when it was moved/renamed.


* Next, I back out to the check-in overview, scroll down, and click on 
source/code/file.h. I see no file history aside from that of the check-in event.

Issue #4 is that when I am looking at a file's history, I want to see all of 
its history. Not just its history at file system location X.


* Finally, I click on the file hash and see 2 entries for the file: File 
file.h and File source/code/file.h, with the code below.

Issue #5 is that at this point, I'm confused and have no idea what's going on. 
What am I looking at? Why did my file get deleted and split from its history  
existence just because I moved it?


^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] Clarification on file move being treated as file deletion.

[K]

on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Dec 17, 2012 at 7:48 PM, K k...@lightpowered.org wrote:



I've been asked to clarify the confusion behavior I've run into.



$ fossil open project.fossil

project files expand into current directory as expected

$ mkdir source

$ mkdir source/code

$ fossil mv file.h source/code/

RENAME file.h source/code/file.h

$ fossil changes

MISSINGsource/code/file.h

$ mv file.h source/code/

$ fossil changes

RENAMEDsource/code/file.h

$ fossil commit

$ fossil ui





* Timeline shows project history as I expect. I click the check-in hash to 
view its
details.





* I see:

Deleted file.h version [...]



Name change from from file.h to source/code/file.h.



Issue #1 is from is repeated twice.

Issue #2 is file.h is being accounted as having been deleted, when it was 
moved/renamed.
For the same reason I value the inability of Fossil to have commits changed, I 
expect
that the same correctness would be demonstrated here.





Please rebuild Fossil using http://www.fossil-scm.org/fossil/info/4ac43fe6e3 
then do fossil rebuild then recheck the display.  I think the issues above 
will
be fixed.

#2 is fixed, no longer showing moved files as deleted in the check-in overview. 
Thank you. #1 is not fixed.



 



* Next, being concerned, I click on file.h. I see its correct file history, 
except
that the most recent entry claims the file is deleted. I think, this is bad, 
what
is happening?



Issue #3 is file.h in its history is accounted as having been deleted, again, 
when
it was moved/renamed.

#3 is fixed, no longer showing deletion in the file history.






* Next, I back out to the check-in overview, scroll down, and click on 
source/code/file.h.
I see no file history aside from that of the check-in event.



Issue #4 is that when I am looking at a file's history, I want to see all of 
its
history. Not just its history at file system location X.

New file history cites its origin as having been from some file renamed with a 
link to it. This helps, but I still don't understand why a file must split off 
from its history just because it's moved to another directory?

^K






* Finally, I click on the file hash and see 2 entries for the file: File 
file.h
and File source/code/file.h, with the code below.



Issue #5 is that at this point, I'm confused and have no idea what's going on. 
What
am I looking at? Why did my file get deleted and split from its history  
existence
just because I moved it?





^K

___

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

___
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] Clarification on file move being treated as file deletion.

[K]

on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Dec 17, 2012 at 9:00 PM, K k...@lightpowered.org wrote:







#2 is fixed, no longer showing moved files as deleted in the check-in 
overview. Thank
you. #1 is not fixed.


Alternative fix is here:  http://www.fossil-scm.org/fossil/info/aa9a2485de



You'll need to run fossil rebuild again coming from the previous attempted 
fix.

Let me know if this one works any better.  It seems to be working on my 
tests

It works better as it appears to show on old file history page what it was 
renamed to, so now there is bi-direction linking which is good given files 
split off from their history upon moving them. Thank you.

However, I'm still curious why files must split upon move? 

Issue #1 still exists btw.

^K


-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] File moves reported in commit as file deletion!

[K]

Thanks for sharing!

^K


on Dec 17, 2012, Michael Richter ttmrich...@gmail.com wrote:

You know, for someone using a tool that hasn't paid for it, you have a real 
tone of
overweening entitlement.  Perhaps you need to look up the definitions involved 
in
free software and open source software.  You may wish, in particular, to 
pay
attention to the portions of it that involve how to get people to work for you 
(for free, I remind you).


You should perhaps be thankful that Richard Hipp doesn't share my temperament. 
 Had
this been my project you would have been silently removed from a real mailing 
list
to a black hole one where every email you sent never made it to another 
person, even
though you could still read each and every message.


As for your later offer of a bounty?  Forget it.  Your attitude clearly marks 
you
as the kind of person who'd be a client from Hell.  I suspect that, given 
your
performance on the list so far, you'll find it difficult to hire anybody.  You 
probably
now rely on the good, kind, professional graces of Richard.  May God have 
mercy on
your code.



On 18 December 2012 04:58, K k...@lightpowered.org wrote:


I don't need to make assumptions, and therefore am not. I'm going off of the 
facts,
which I can observe, and which I can present to others.



The file was not deleted. It was moved using Fossil's own fossil mv command. 
It's
irrational to treat this as a deletion.



If you cannot provide justification for this behavior, we should move to 
discussing
the behavior Fossil should exhibit.



^K





on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:







On Mon, Dec 17, 2012 at 3:49 PM, K k...@lightpowered.org wrote:







As I said, I did not DELETE any files, but rather moved them. fossil changes 
reported

them as RENAMED. And in the check in, they are being reported as DELETED.







I'm just asking how in the design of Fossil you justified this decision. 
Please
directly

address this vs skirting it.



I would guess that when generating the DELETED text the code merely notes 
that
a

file with that name is no longer part of the check-in and that the code does 
not

go to the extra trouble to figure out if the filename changed.







You seem to be making the assumption that whoever wrote that bit of code made 
a
deliberate

decision to obscure the fact that the filename changed.  Why would you assume 
that?













^K











on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:















On Mon, Dec 17, 2012 at 2:55 PM, K k...@lightpowered.org wrote:























I'm looking at the page for my file and its history ends as deleted when I 
did
not



delete it. I moved it, which fossil changes reported as a RENAMED. I 
commited and



now have the surprise dumped on me that my file was deleted and whatever 
else,
when



it was not. This is not acceptable to lose the history of a file just 
because I

MOVE



it. I cannot believe this is how Fossil is operating and apparently is 
expected

to



operate. PLEASE JUSTIFY THIS.























I've very sorry that the file history report does not structure the 
information

as



you would prefer.







All of the information needed to track file changes across renames is 
contained

in



the repository.  And, in fact, the annotate screens do trace changes 
across renames.



But nobody has yet taken the time to write a report screen that displays a 
file

history



graph across renames.  Perhaps because nobody cares as passionately about 
this
as



you seem to.  The Fossil source code is open-source; you could contribute a 
solution



if you wanted to.















--



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 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



___

fossil-users mailing list

fossil-users@lists.fossil-scm.org

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Perhaps people don't believe this, but throughout all of the discussions of 
entering
China our focus has really been what's best for the Chinese people. It's not 
been
about our revenue or profit or whatnot.

--Sergey Brin, demonstrating the emptiness of the don't be evil mantra.




___
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] Clarification on file move being treated as file deletion.

[K]

on Dec 17, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Dec 17, 2012 at 9:12 PM, K k...@lightpowered.org wrote:





However, I'm still curious why files must split upon move?

It isn't a requirement.  The page is simply showing all artifacts that 
represent a
file with a given name.  That is one way to slice the data.  You are wanting 
to track
a file throughout its revision history and through name changes.  That is a 
different
way to slice the data.  Both views are useful.



The file-by-name view is currently used because it is the simplest to 
implement,
in several ways.  (1) The file you want to look at has a unique name, so you 
just
include that name as a query parameter on the URL.  (2)  You can look up all 
changes
by querying the database once by that name.



File-history-through-name-changes is more complicated.  For example, how do 
you specify
what file you want to look at in the URL.  You cannot just say file1.txt any 
more,
because two or more different files might have passed through that name during 
their
history.  I suppose you would have to specify the filename and a particular 
check-in
at which the file had that particular name.  So you have two query parameters 
instead
of one.  Then down in the implementation, it is now necessary to query the 
database
again for each name-change.  This all adds up to more complication. Since 
nobody
has (yet) requested file-history-through-name-changes, it was easier just to 
leave
it out.

Ok, I had suspected it was something along these lines.

So what happens now if I create another different file named file.h and add 
it to the root of my repo? (Which is the slot held by my old file.h which is 
now at /source/code/file.h) When viewed would it show the history from my first 
file.h?





 



Issue #1 still exists btw.

Fixed in the latest check-in.

Thank you.

^K

-- 
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problem encountered while attempting to reflect project file system reorganization in Fossil repo.

[K]

kk,

Thank you. Your timing is funny as I had *just* given up on waiting for help 
and tried again with success this time.

What I did was deleted my whole source/ dir, leaving only my foo.fossil. 
(Luckily I had just done a commit before any of this reorganization stuff) I 
did fossil open foo.fossil in my project/ dir, and it spewed all of my files 
into the dir, as expected.

Then I did mkdir source; mkdir source/code, then added both of those dirs to 
Fossil.

Then I did fossil mv file.h source/code/file.h for all of my files.

THEN I moved the actual files into that dir.

Now everything is happy apparently.

Thanks again for taking the time to write kk.

^K


on Dec 16, 2012, kk kkinn...@megagate.com wrote:

On 12/16/2012 K k...@lightpowered.org wrote:

  I'm new to Fossil SCM, have not used any other SCMs,
  and am trying to do something relatively complex for
  me. It involves moving from a model where files are
  directly added to my repo, rather than being organized
  in the repo within directories.
 
  I had my project organized as:
 
  project/
  * non versioned project files
  * foo.fossil - versioned file repo.
  * foo.xcodeproj - project configuration in Apple Xcode's format.
  * sourcecode/ - source code files and check out directory.
 
 
  I want to reorganize, and so I have:
 
  * moved (on my file system) foo.xcodeproj into the sourcecode/ dir.
  * renamed (on my file system) sourcecode/ to source/.
  * moved (on my file system) source code files from source/ into
source/code/.
 
  I also want to change from my check out being in
  source, to /containing/ source. So in my above file
  system layout, I want to promote my foo.fossil from
  project/code, to project/, so when it's checked out it
  produces a single directory named source. (As I
  expand use of Fossil SCM, I'll add other project/dirs)
 
  I ran into some problems and would appreciate help.
 
 
  
  Last login: Thu Dec 13 23:41:48 on console
  notebook:~ ktk$ cd source/
  notebook:source ktk$ ls -l
  total 0
  drwxr-xr-x  25 ktk  staff  850 Dec 15 22:37 code
  drwxr-xr-x   5 ktk  staff  170 Dec 15 22:39 foo.xcodeproj
  notebook:source ktk$ ls -la
  total 40
  drwxr-xr-x   6 ktk  staff204 Dec 15 22:37 .
  drwxr-xr-x   6 ktk  staff204 Dec 15 22:37 ..
  -rw-r--r--@  1 ktk  staff   6148 Dec 15 22:37 .DS_Store
  -rw-r--r--   1 ktk  staff  10240 Nov 30 22:31 .fslckout
  drwxr-xr-x  25 ktk  staff850 Dec 15 22:37 code
  drwxr-xr-x   5 ktk  staff170 Dec 15 22:39 foo.xcodeproj
  notebook:source ktk$ fossil changes
  MISSINGfoo.c
  MISSINGfoo.h
  notebook:source ktk$ fossil help mv
  Usage: fossil mv|rename OLDNAME NEWNAME
 or: fossil mv|rename OLDNAME... DIR
 
  Move or rename one or more files or directories within the
repository tree.
  You can either rename a file or directory or move it to
another subdirectory.
 
  This command does NOT rename or move the files on disk.  This
command merely
  records the fact that filenames have changed so that
appropriate notations can be made at the next commit/checkin.
 
  See also: changes, status

You were on the right track, here.  'mv' will tell fossil
that you have changed the path of an existing file.

  notebook:source ktk$ fossil help (At this point I was
  looking to see if I needed to fossil mkdir code to
  fossil mv foo.h code/)
  Usage: fossil help COMMAND
  Common COMMANDs:  (use fossil help --all for a complete list)
  add clean   gdiff   mv  rm  timeline
  addremove   clone   helpopensettingsui
  all commit  import  pullsqlite3 undo
  annotatediffinfopushstash   update
  bisect  export  initrebuild status  version
  branch  extras  ls  remote-url  sync
  changes finfo   merge   revert  tag
  This is fossil version 1.24 [8d758d3715] 2012-10-22 12:48:04 UTC
  notebook:source ktk$ fossil help add
  Usage: fossil add ?OPTIONS? FILE1 ?FILE2 ...?
 
  Make arrangements to add one or more files or directories to the
  current checkout at the next commit.
 
  When adding files or directories recursively, filenames that begin
  with . are excluded by default.  To include such files, add
  the --dotfiles option to the command-line.
 
  The --ignore option is a comma-separate list of glob patterns
for files
  to be excluded.  Example:  '*.o,*.obj,*.exe'  If the --ignore option
  does not appear on the command line then the ignore-glob setting is
  used.
 
  The --case-sensitive option determines whether or not filenames should
  be treated case sensitive or not. If the option is not given, the
default
  depends on the global setting, or the operating system default, if
not set.
 
  Options:
 
 --case-sensitive BOOL override case-sensitive setting
 --dotfiles  include files beginning with a dot (.)
 --ignore CSG  ignore files matching

[fossil-users] Ignoring Apple Xcode user files

[K]

Hello,

Now that I wish to keep my Xcode project configuration 'file' in my repo, I've 
run into some 'fun'.

I say 'file' because project.xcodeproj is actually a dir, with both project 
configuration and user data in it.

Apparently the Git workflow to handle this is: echo 'xcuserdata/'  
.gitignore  git add *.xcodeproj.

What would be the equivalent in Fossil please? Or equivalent aside, what is the 
proper solution to this when using Fossil?

Thank you in advance for any help.

Kind 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] Ignoring Apple Xcode user files

[K]

on Dec 16, 2012, Dmitry Chestnykh dmi...@codingrobots.com wrote:

I use the following string for Admin  Settings  ignore-glob:

*/xcuserdata/*,build/*,*.mode1v3,*.pbxuser,*.orig

Thank you Dmitry. What are your thoughts on:

*/xcuserdata/*,build/*,*.mode1v3,*.pbxuser,*.orig,*/DerivedData/*

^K


--
Dmitry Chestnykh
http://www.codingrobots.com

On Sun, Dec 16, 2012 at 10:19 PM, K k...@lightpowered.org wrote:
 Hello,

 Now that I wish to keep my Xcode project configuration 'file' in my repo, 
 I've run
into some 'fun'.

 I say 'file' because project.xcodeproj is actually a dir, with both project 
 configuration
and user data in it.

 Apparently the Git workflow to handle this is: echo 'xcuserdata/'  
 .gitignore
 git add *.xcodeproj.

 What would be the equivalent in Fossil please? Or equivalent aside, what is 
 the
proper solution to this when using Fossil?

 Thank you in advance for any help.

 Kind 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 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] Ignoring Apple Xcode user files

[K]

ps: I found the following; 
http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects

Xcode sure is a nightmare.

^K

on Dec 16, 2012, Dmitry Chestnykh dmi...@codingrobots.com wrote:

I use the following string for Admin  Settings  ignore-glob:

*/xcuserdata/*,build/*,*.mode1v3,*.pbxuser,*.orig

--
Dmitry Chestnykh
http://www.codingrobots.com

On Sun, Dec 16, 2012 at 10:19 PM, K k...@lightpowered.org wrote:
 Hello,

 Now that I wish to keep my Xcode project configuration 'file' in my repo, 
 I've run
into some 'fun'.

 I say 'file' because project.xcodeproj is actually a dir, with both project 
 configuration
and user data in it.

 Apparently the Git workflow to handle this is: echo 'xcuserdata/'  
 .gitignore
 git add *.xcodeproj.

 What would be the equivalent in Fossil please? Or equivalent aside, what is 
 the
proper solution to this when using Fossil?

 Thank you in advance for any help.

 Kind 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 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

[fossil-users] File moves reported in commit as file deletion!

[K]

Hello,

I've done a number of fossil mv file.h source/code/ today, then issued a 
commit. The check-in reports that all of the files I've moved have been deleted 
and renamed.

For example:

Deleted foo.c version [0e52b8b63a1e8c0d]

Name change from from foo.c to source/code/foo.c.

Why is a file I moved using fossil mv, then on the file system, being 
reported as deleted? Now when I look at the history of the 'new' files, they 
don't show their entire history.

What is going wrong please?

^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] Problem encountered while attempting to reflect project file system reorganization in Fossil repo.

[K]

Hello,

I'm new to Fossil SCM, have not used any other SCMs, and am trying to do 
something relatively complex for me. It involves moving from a model where 
files are directly added to my repo, rather than being organized in the repo 
within directories.

I had my project organized as:

project/
* non versioned project files
* foo.fossil - versioned file repo.
* foo.xcodeproj - project configuration in Apple Xcode's format.
* sourcecode/ - source code files and check out directory.


I want to reorganize, and so I have:

* moved (on my file system) foo.xcodeproj into the sourcecode/ dir.
* renamed (on my file system) sourcecode/ to source/.
* moved (on my file system) source code files from source/ into source/code/.

I also want to change from my check out being in source, to /containing/ 
source. So in my above file system layout, I want to promote my foo.fossil from 
project/code, to project/, so when it's checked out it produces a single 
directory named source. (As I expand use of Fossil SCM, I'll add other 
project/dirs)

I ran into some problems and would appreciate help.



Last login: Thu Dec 13 23:41:48 on console
notebook:~ ktk$ cd source/
notebook:source ktk$ ls -l
total 0
drwxr-xr-x  25 ktk  staff  850 Dec 15 22:37 code
drwxr-xr-x   5 ktk  staff  170 Dec 15 22:39 foo.xcodeproj
notebook:source ktk$ ls -la
total 40
drwxr-xr-x   6 ktk  staff204 Dec 15 22:37 .
drwxr-xr-x   6 ktk  staff204 Dec 15 22:37 ..
-rw-r--r--@  1 ktk  staff   6148 Dec 15 22:37 .DS_Store
-rw-r--r--   1 ktk  staff  10240 Nov 30 22:31 .fslckout
drwxr-xr-x  25 ktk  staff850 Dec 15 22:37 code
drwxr-xr-x   5 ktk  staff170 Dec 15 22:39 foo.xcodeproj
notebook:source ktk$ fossil changes
MISSINGfoo.c
MISSINGfoo.h
notebook:source ktk$ fossil help mv
Usage: fossil mv|rename OLDNAME NEWNAME
   or: fossil mv|rename OLDNAME... DIR

Move or rename one or more files or directories within the repository tree.
You can either rename a file or directory or move it to another subdirectory.

This command does NOT rename or move the files on disk.  This command merely
records the fact that filenames have changed so that appropriate notations
can be made at the next commit/checkin.

See also: changes, status
notebook:source ktk$ fossil help (At this point I was looking to see if I 
needed to fossil mkdir code to fossil mv foo.h code/)
Usage: fossil help COMMAND
Common COMMANDs:  (use fossil help --all for a complete list)
add clean   gdiff   mv  rm  timeline  
addremove   clone   helpopensettingsui
all commit  import  pullsqlite3 undo  
annotatediffinfopushstash   update
bisect  export  initrebuild status  version   
branch  extras  ls  remote-url  sync  
changes finfo   merge   revert  tag   
This is fossil version 1.24 [8d758d3715] 2012-10-22 12:48:04 UTC
notebook:source ktk$ fossil help add
Usage: fossil add ?OPTIONS? FILE1 ?FILE2 ...?

Make arrangements to add one or more files or directories to the
current checkout at the next commit.

When adding files or directories recursively, filenames that begin
with . are excluded by default.  To include such files, add
the --dotfiles option to the command-line.

The --ignore option is a comma-separate list of glob patterns for files
to be excluded.  Example:  '*.o,*.obj,*.exe'  If the --ignore option
does not appear on the command line then the ignore-glob setting is
used.

The --case-sensitive option determines whether or not filenames should
be treated case sensitive or not. If the option is not given, the default
depends on the global setting, or the operating system default, if not set.

Options:

   --case-sensitive BOOL override case-sensitive setting
   --dotfiles  include files beginning with a dot (.)   
   --ignore CSG  ignore files matching patterns from the 
   comma separated list of glob patterns.

See also: addremove, rm
notebook:source ktk$ fossil add code
ADDED  code/foo.c
ADDED  code/foo.h
notebook:source ktk$ fossil changes (Thinking at this point maybe Fossil can 
'see' the missing files now, and they will be 'FOUND'?)
MISSINGfoo.c
MISSINGfoo.h
ADDED  code/foo.c
ADDED  code/foo.h
notebook:source ktk$ fossil mv foo.c code/
RENAME foo.c code/foo.c
fossil: SQLITE_CONSTRAINT: abort at 38 in [UPDATE vfile SET 
pathname='code/foo.c' WHERE pathname='foo.c' AND vid=55]: columns pathname, vid 
are not unique
fossil: columns pathname, vid are not unique
UPDATE vfile SET pathname='code/foo.c' WHERE pathname='foo.c' AND vid=55

If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.
notebook:source ktk$ 


:(

Thank you for any help.

^K

___
fossil-users mailing list
fossil-users@lists.fossil

Re: [fossil-users] why does `fossil rm' not do the real thing?

[K]

I agree with Themba. I like that Fossil is a separate repo 'world' from my 
files. If this boundary is to be pierced, I think it should require passing in 
some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this 
example representing sync.

I would like some friendly tip text after rm/et al are ran, such as:

You have removed file1.h, file1.c from repo foo, you may want to remove them 
from your working copy.

Seems like a great way to remind, teach, and help all in-context and with 
minimal overhead.

^K


on Dec 11, 2012, Themba Fletcher themba.fletc...@gmail.com wrote:

Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.

On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek no...@thewordnerd.info wrote:
 Weighing in on this, finally:

 It's interesting to me that everyone speculates that this *might* break
 things for some hypothetical person, and *might* bite someone, but has
 anyone here ever been bitten by it?

It's the what if that bothers me. I use fossil as a safety net to
manage an ungodly number of small maintenance projects, so I'm often
not the original author of the project, and am almost never really
comfortable with the code base I'm modifying.

When I sync a code base to my machine and fossil add . --dotfiles I
really appreciate the fact that I can trust fossil not to touch the
disk if I accidentally add something that I don't want in there and
have to remove it.

In the presence of shabby and poorly maintained deploy/sync scripts,
solo use of fossil, unknown modifications to the master since the last
checkin, etc., the consequences of removing something from my local
copy could be pretty embarrassing -- ie I could potentially blow away
the only working copy of a new cusomer's web app. Not to say that I
couldn't adjust to a new set of danger points, but that I do really
appreciate fossil's current behavior.



 And is it not something that fossil revert could undo?


Is it? What about:

fossil add .
(whoops) - fossil rm something
fossil commit
(take a phone call and forget it's fossil 2.0)
sync up

Now the files are gone locally, they're gone on the remote site, and
fossil revert isn't going to help. This is obviously a workflow /
deploy problem at its root, but it's a bit of sloppiness that fossil's
current behavior forgives and the proposed behavior would not.


 I don't mind avoiding the change until a 2.0 release, but I worry about
 making it a setting, because I prescribe to the idea that settings add
 complexity both for users and developers.


I agree about minimizing the extra overhead of a setting, but I come
down personally on the side of it's working fine, so please don't
touch it. Maybe my use case varies from the norm, but I don't do
fossil rm all that often and, when I do, the extra overhead of having
to do Up arrow, Ctrl-A, Alt-D, Return afterwards doesn't bother me
at all. I like explicitly taking care of this as a second deliberate
step.

 My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then
 just change it. There are plenty of settings already, please don't add
 another, especially for something that we're all speculating might affect
 someone who can't just revert for whatever reason.

So, respectfully disagree. For me it's about not having to learn new
rules about when fossil will touch my files and when it will not.

Best Regards,

Themba
___
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

[fossil-users] How to migrate up a directory.

[K]

I am using Xcode as my IDE at the moment, which produces a project.xcodeproj 
file, and a projectsrc/ dir to contain source files. My .fossil is located in 
the project dir alongside the project.xcodeproj file. However, I type fossil 
UI in the projectsrc dir, and add files from there as well, as to date I've 
only wanted to keep source code files in the repository.

Now I want to keep my project.xcodeproj file in the repository as well. How do 
I change my fossil configuration from:

project/
  project.fossil
  project.xcodeproj
  projectsrc/

project/projectsrc/ fossil ui, fossil add source.h source.h, etc.


To:
  project.fossil
  project.xcodeproj
  projectsrc/

project/ fossil ui, fossil add projectsrc/source2.h projectsrc/source2.c, 
etc.


Thank you for your time.

Kind 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] serious problem with wiki editing

[K]

This is as a result of a featured added on my behalf, I'm afraid.

There should now be (I haven't found occasion to update my Fossil to 1.24 given 
I'd have to repatch the wiki page name length requirement) an option somewhere 
allowing the treatment of [xxx] as wiki mark up.

^K


on Nov 19, 2012, Ron Aaron r...@ronware.org wrote:

When I add a link [whatever] in my wiki page, as of fossil b058c8a944
I no longer see the link, but only get the literal text entered!

The repo is set for the default settings, no WYSIWG or HTML
___
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] [1.22] Easy way to cancel tentative changes?

[K]

on Nov 16, 2012, Carson Chittom car...@wistly.net wrote:

Richard Hipp d...@sqlite.org writes:

 Yes, this is an exceedingly newbie question.  But if you have never worked
 with a software configuration management (SCM) system and especially with a
 distributed SCM (DSCM) like Fossil, then the work-flow is probably pretty
 mysterious to you.  More experienced hands (read:  most others reading this
 list and especially those with check-in privileges to Fossil) need to
 figure out some way of better explaining how Fossil (and other DSCMs) work
 to people who have never seen the concepts before.  This is very hard for
 us since the core concepts of DSCM are like second nature - it is like
 trying to explain how to walk - we can't explain it; we just do it without
 thinking.

If I may suggest, from my own similarly newbie perspective, a good start
would be putting something on the lines of your message in this thread,
which I found very clear, as the (or at least, at the top of) the
documentation page on Branching, Forking, Merging, and Tagging[1].
What's there now is interesting--and worth having, I think--but it just
doesn't answer the user who looks at the docs thinking I've gotten to
the point in playing with Fossil that I need to branch. How do I do
that?

I would also agree with this in general.

Specifically, I'm now at the point mentioned of needing to branch as a matter 
of prudent workflow.

I see:
  * This is a useful mechanic in supporting highly dynamic exploration.
  * An opportunity to underscore Fossil's ability to this end.

Too often I'm encumbered by the overhead of movement in technological 
evolution. Naturally this shall change.

^K



[1] http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

___
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

[fossil-users] Timeline item presentation

[K]

I've just noticed that a commit message containing [  ] is presented in 
the web interface as underlined. I presume this is some kind of mark-up I 
stumbled into.

1. What is this?
2. How can I cause this to not happen? I'd prefer if timeline items were left 
'plain text'.

Thank you,
^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] Timeline item presentation

[K]

On Nov 05, 2012, Richard Hipp d...@sqlite.org wrote:



On Mon, Nov 5, 2012 at 7:03 PM, K k...@lightpowered.org wrote:



I've just noticed that a commit message containing [  ] is presented in 
the
web interface as underlined. I presume this is some kind of mark-up I stumbled 
into.



1. What is this?

Commit messages are wiki text.  This permits you to do things like insert the 
hash
of a ticket in the commit message in between [...] and Fossil will think 
automatically
generate links from the check-in to the ticket and from the ticket to the 
check-in.



See, for example, the check-in at 
http://www.fossil-scm.org/fossil/info/27298fffc8 which references ticket 
0ff64b0a5fc88e7e98b9db082c6928d6f63e3e6e.  You can click
on the link to go straight to the ticket.  Then on the ticket, select the 
Timeline
http://www.fossil-scm.org/fossil/tkttimeline/0ff64b0a5fc8 to see all the 
check-ins associated with that ticket.


 

2. How can I cause this to not happen? I'd prefer if timeline items were left 
'plain
text'.

nowiki.../nowiki around the check-in comment.

Or use #91; and #93; in place of [ and ].

Thanks for your reply.

How may I disable this feature? If that is impossible, for some reason, is 
there a way to change the 'special' symbol to one which isn't commonly used in 
the language? Perhaps [[[ and ]]]. I find it annoying to need to evade and 
escape this feature, vs having it be more of an opt-in model.

^K




 



Thank you,

^K

___

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

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