Re: [fossil-users] Fossil-NG Bloat?

[Warren Young]

On Nov 28, 2017, at 9:07 AM, Mike Burns  wrote:
> 
> > You won't get Fossil/SQLite running on a Commodore 64 without a lot of work.
> 
> What are the chances someone will take up take up this challenge, and have a 
> Commodore 64 or Apple II version of fossil up and running by the end of the 
> year?

I’m pretty sure you need at least a 32-bit processor to run SQLite, both for 
word size requirements and minimum memory access requirements.

My idea for getting most of Fossil’s functionality onto a PDP-11 — a 16-bit 
machine — involves creating a new client that uses Fossil’s existing HTTP 
and/or JSON APIs in REST fashion, letting the remote server pull most of the 
weight.  I’ve proposed calling it frapi, a combined coffee pun and acronym to 
make programmers happy: Fossil REST API client.

My frapi proposal makes Fossil work more like Subversion, going back to the 
remote server for each new version to save disk space and bandwidth.

You’d probably need a large fraction of 64k RAM to pull this off, but within 
those restrictions, it should be doable.  People have made TCP/IP stacks for 
8-bit microcontrollers many times.  Speaking HTTP and/or JSON over them is 
within the scope of an 8-bit microprocessor or microcontroller like the 6502 or 
8051.

You’d still be restricted in the types of repository you can check out due to 
memory and disk space limitations, of course.  The point would not be to let an 
Apple ][ check out the SQLite repository, but rather to allow a small computer 
to store versioned files durably in an off-machine repository.
___
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-NG Bloat?

[Joseph R. Justice]

On Nov 28, 2017 11:08 AM, "Mike Burns"  wrote:

As much as I agree, software in general has moved on. You won't get
> Fossil/SQLite running on a Commodore 64 without a lot of work.
> With legacy platforms come legacy software that is either no longer
> supported by the vendor, or is supported just because the vendor was paid
> by that client to keep on supporting it.
> If drh receives such payment to continue supporting such legacy cases then
> fair enough.
>

What are the chances someone will take up take up this challenge, and have
a Commodore 64 or Apple II version of fossil up and running by the end of
the year?


Does SQLite run on these platforms yet?  If not, need to port that over
*first*, so it's available for Fossil's use ...



Joseph
___
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-NG Bloat?

[Mike Burns]

>
> As much as I agree, software in general has moved on. You won't get
> Fossil/SQLite running on a Commodore 64 without a lot of work.
> With legacy platforms come legacy software that is either no longer
> supported by the vendor, or is supported just because the vendor was paid
> by that client to keep on supporting it.
> If drh receives such payment to continue supporting such legacy cases then
> fair enough.
>
>
What are the chances someone will take up take up this challenge, and have
a Commodore 64 or Apple II version of fossil up and running by the end of
the year?
___
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-NG Bloat?

[bytevolcano]

On Mon, 27 Nov 2017 13:58:14 -0700
Warren Young  wrote:

> On Nov 23, 2017, at 5:19 AM, bytevolc...@safe-mail.net wrote:
> > 
> > They want maximum results for minimum effort? That may be normal, but
> > it's still whiney.  
> 
> If “normal” is “whiney”, it ceases to be a useful disparagement unless you 
> intend to change society.  This mailing list is not a good place to start 
> doing that; few take social cues from geeks. :)

If your users want Git support, odds are they know how to use Git, and that's 
not something a "normal" person can do, or care about. ;)

> That should be tried, too.  I suspect it will make Git faster, at least up to 
> repo sizes that fit easily within a single process’s ability to grab 
> hard-wired RAM, based on the benchmark I pointed you to up-thread.
> 
> Interesting point about that benchmark: if you force it to create a DB much 
> larger than RAM, performance goes in the tank on the SQLite side.  And that 
> in turn may well be materially interesting to this very discussion.  Maybe 
> it’s why Git holds up better under load as repo size grows into the gigs.

May be worth testing that out on a restricted VM.

> VAX != “super unusual.”  It was one of the most popular computers of the 
> 1980s, dominating an entire market segment.  Therefore, a lot of software got 
> ported to it, including recent versions of GCC.  A huge hobbyist community 
> still exists for it, which also helps.

Although these days, it isn't very mainstream. When I say "unusual" I am 
talking about things that are either rare or not popular/mainstream in today's 
modern (and somewhat broken) world.

> 
> You want unusual, let’s talk about the Intel Paragon, based on the ill-fated 
> i860 microprocessor:
> 
> https://en.wikipedia.org/wiki/Intel_Paragon
> 
> I suspect it’s difficult to find a GCC fully supporting C99 on that, yet they 
> were powerhouses in their day, even grabbing the #1 spot in TOP500 list at 
> one point:
> 
> 
> https://www.top500.org/featured/systems/intel-xps-140-paragon-sandia-national-labs/
> 
> Now, let us say that I’m an underfunded government laboratory sharing time on 
> a third-hand Paragon that is still powered on only because it’s cheaper to 
> pay the power and cooling bill than buy a new massively parallel 
> supercomputer.  Do I not get to run the latest SQLite now?  Do I not get to 
> pull from public Fossil repos?

And how many systems like that require SQLite/Fossil in the first place? Let's 
be realistic here. If you spend time focusing on evey what-if/corner case when 
developing software, you are bound to become the next open-source Adobe sooner 
or later. There's an even better chance they run old archaic (versions of) 
software as well, and don't care much for SQLite/Fossil or anything that uses 
it.

> [citation needed]
> 
> I’m quite serious.  Who says C11 is a major factor in the maintainability of 
> C code, and by what measured factor?

Using standard types (uintXX_t, uint_fastXX_t, bool), and moving variables down 
scope makes it clearer as to where they are used.
I notice in a lot of the Fossil code, you have this situation:

void a_function(int this, int that)
{
  int i, variable1, variable2;
  /* long block of code */
  variable1 = this * that;
  /* long block of code */
  variable2 = that / this;
  /* long block of code */
  for( i = 0; i < variable1; i++ ) {
do_something(i);
  }
}

Now in this example, you can see that variable1 isn't used until after the 
first long block of code, and variable2 isn't used until the second one.
The variable i is only ever used in the for loop. With C99 you can write this 
as follows:

void a_function(int this, int that)
{
  /* long block of code */
  int variable1 = this * that;
  /* long block of code */
  int variable2 = that / this;
  /* long block of code */
  for( int i = 0; i < variable1; i++ ) {
do_something(i);
  }
}

Here it is clear where the variable is first used, particular in the situation 
of the for loop. Of course this is a case-by-case thing, up to the developer.

I should point out that I am not advocating use of C99/C11 just for the sake of 
using it, but why restrict to an obsolete standard when a better standard has 
been present since 18 years ago? Why penalize the development of Fossil just 
for a few corner cases?

> Ditto.  I suspect you’re chasing microoptimizations, which might amount to 
> single-digit percentage speed increases, all in.
> 
> Even at today’s far slower single-core speed increase rates, you’ll probably 
> get all of that performance and more from Intel just in the time it takes to 
> do the “upgrade.”  Why not spend the time elsewhere and let Intel deliver the 
> goods?

It's not about chasing microoptimizations, but does it hurt if you get even 
just a bit of performance for free, if code is more readable and workable?

> You’re going to change a bunch of variables’ locality and you think I can fix 
> it with a few #defines?  I don’t 

Re: [fossil-users] Fossil-NG Bloat?

[Warren Young]

On Nov 23, 2017, at 5:19 AM, bytevolc...@safe-mail.net wrote:
> 
> They want maximum results for minimum effort? That may be normal, but
> it's still whiney.

If “normal” is “whiney”, it ceases to be a useful disparagement unless you 
intend to change society.  This mailing list is not a good place to start doing 
that; few take social cues from geeks. :)

> It may be easier to implement Git in an SQLite database for the sake of
> comparison.

That should be tried, too.  I suspect it will make Git faster, at least up to 
repo sizes that fit easily within a single process’s ability to grab hard-wired 
RAM, based on the benchmark I pointed you to up-thread.

Interesting point about that benchmark: if you force it to create a DB much 
larger than RAM, performance goes in the tank on the SQLite side.  And that in 
turn may well be materially interesting to this very discussion.  Maybe it’s 
why Git holds up better under load as repo size grows into the gigs.

> 
> You should ask the OpenBSD folk for advise. They have run on super
> unusual systems with compilers that support C99, including the VAX.

VAX != “super unusual.”  It was one of the most popular computers of the 1980s, 
dominating an entire market segment.  Therefore, a lot of software got ported 
to it, including recent versions of GCC.  A huge hobbyist community still 
exists for it, which also helps.

You want unusual, let’s talk about the Intel Paragon, based on the ill-fated 
i860 microprocessor:

https://en.wikipedia.org/wiki/Intel_Paragon

I suspect it’s difficult to find a GCC fully supporting C99 on that, yet they 
were powerhouses in their day, even grabbing the #1 spot in TOP500 list at one 
point:


https://www.top500.org/featured/systems/intel-xps-140-paragon-sandia-national-labs/

Now, let us say that I’m an underfunded government laboratory sharing time on a 
third-hand Paragon that is still powered on only because it’s cheaper to pay 
the power and cooling bill than buy a new massively parallel supercomputer.  Do 
I not get to run the latest SQLite now?  Do I not get to pull from public 
Fossil repos?

> Just some of the features I mentioned would make things a lot easier to
> maintain

[citation needed]

I’m quite serious.  Who says C11 is a major factor in the maintainability of C 
code, and by what measured factor?

> and provide optimisation opportunities for compilers.

Ditto.  I suspect you’re chasing microoptimizations, which might amount to 
single-digit percentage speed increases, all in.

Even at today’s far slower single-core speed increase rates, you’ll probably 
get all of that performance and more from Intel just in the time it takes to do 
the “upgrade.”  Why not spend the time elsewhere and let Intel deliver the 
goods?

>> I don’t need to do that today, but I’d prefer that you don’t preclude
>> me doing it in the future just because you want to require C11 to
>> compile SQLite and Fossil.
> 
> It won't preclude you doing it if you try hard enough. All I am
> proposing here is basic C99 functionality such as postponed variable
> declarations, inline/restrict (maybe), stdint.h/stdbool.h, etc. to make
> the code neater. If your compiler doesn't support some of that stuff,
> #define is your best friend.

You’re going to change a bunch of variables’ locality and you think I can fix 
it with a few #defines?  I don’t think so.

>> If you are developing software for a company
>> whose marketing department decides that targeting only Windows 8 and
>> 10 is the best decision, then by all means, use C11 or C++14
>> exclusively; you can afford it.
> 
> Using C99/C11 doesn't require Windows 8/10 or Linux.

I didn’t say it did.  I simply gave an example where those signing the checks 
have decided that supporting only the latest platforms is acceptable from a 
business standpoint, therefore all of my arguments about legacy architecture 
support go out the window.

Wise man say, “God created the world in only 6 days because he didn’t have a 
legacy user base to support.”

> I recall
> a presentation by Andrew Tanenbaum (of MINIX fame) mentioning that
> software is becoming slower and larger at a faster rate than hardware
> is increasing in speed and capability. He compares running a word
> processor on the PDP-11 to running MS Office on modern Windows.

That’s rather unfair, since the PDP-11 word processor probably didn’t even 
support proportional fonts, much less any appreciable fraction of Word’s 
feature set.

Still, I have been dismayed since the 1980s that it still takes 15-90 seconds 
to boot a computer to a useful application, just like it did for my Apple ][.  
It’s long past time we achieved instant-on.
___
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-NG Bloat?

[Richard Hipp]

On 11/24/17, Ron W  wrote:
>
> Your wiki page summary and replies in this discussion imply you would
> implement interoperability with git by having fossil store git artifacts.

I don't know yet if it would be better to store Git artifacts
natively, or to translate them into Fossil artifacts.  The final
implementation might do either.  Or both.  We'll just have to wait and
see.

>
> Between your comments that git/Fossil artifact translation has significant
> overhear (and a claim that "git fast-export | (cd /new/path; git
> fast-import)" is not lossy), there is an implication that git artifacts do
> not support all of Fossil's metadata.
>
> What effect will this reduced metadata have on applying Fossil semantics to
> git artifacts?
>

Git artifacts do not support named branches, the ability to edit a
check-in comment, the ability to edit a check-in date/time, wiki, nor
tickets.  So if you do any of those things, they won't push back up to
the Git repo to which you are syncing.

I suppose that if Fossil knows that it is syncing with Git and you try
to do any of those things (and perhaps other stuff I haven't yet
thought of) then Fossil should show a scary warning to the effect that
"If you do this, the result of your actions will not be pushable to
Git - are you sure you want to continue?"

-- 
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] Fossil-NG Bloat?

[Ron W]

On Fri, Nov 24, 2017 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Fri, 24 Nov 2017 05:55:51 -0500
> From: Richard Hipp <d...@sqlite.org>
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> On 11/24/17, Johan Kuuse <jo...@kuu.se> wrote:
> > I agree on that we would give up Fossil semantics.
>
> I have no intent to "give up" or change the semantics of Fossil, and I
> see no reason why enabling Fossil to push and pull from Git
> repositories would require this.
>

Your wiki page summary and replies in this discussion imply you would
implement interoperability with git by having fossil store git artifacts.

Between your comments that git/Fossil artifact translation has significant
overhear (and a claim that "git fast-export | (cd /new/path; git
fast-import)" is not lossy), there is an implication that git artifacts do
not support all of Fossil's metadata.

What effect will this reduced metadata have on applying Fossil semantics to
git artifacts?
___
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-NG Bloat?

[j. van den hoff]

On Fri, 24 Nov 2017 15:25:25 +0100, Richard Hipp  wrote:


On 11/24/17, Johan Kuuse  wrote:


I think 'push' and 'pull' seems fair enough.
But what about 'rebase' and 'submodule'?
To what level should the Fossil-NG client support Git features not
present in Fossil?


Zero.


a good thing in my view ... but, consequently, users will run into the  
"impedance mismatch" problem between the different systems mentioned by  
several others, no?






If not supported, wouldn't there be a risk of users just sticking to
'git rebase' instead?



If users want to rebase, then they can use their Git client.


as they could for the rest of their interaction with the git repo. I  
presume exactly that will happen: existing primary git users won't switch  
to a different "git client" anyway. fossil users probably _would_ use the  
ability of fossil-NG to talk to a git repo, though, as long as they don't  
need to do git-specific fancy stuff. but I question whether implementing  
this ability could increase the user base notably.







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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-NG Bloat?

[Richard Hipp]

On 11/24/17, Johan Kuuse  wrote:
>
> I think 'push' and 'pull' seems fair enough.
> But what about 'rebase' and 'submodule'?
> To what level should the Fossil-NG client support Git features not
> present in Fossil?

Zero.

>
> If not supported, wouldn't there be a risk of users just sticking to
> 'git rebase' instead?
>

If users want to rebase, then they can use their Git client.

-- 
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] Fossil-NG Bloat?

[Johan Kuuse]

On Fri, Nov 24, 2017 at 11:55 AM, Richard Hipp  wrote:
>
> On 11/24/17, Johan Kuuse  wrote:
> > I agree on that we would give up Fossil semantics.
>
> I have no intent to "give up" or change the semantics of Fossil, and I
> see no reason why enabling Fossil to push and pull from Git
> repositories would require this.

I think 'push' and 'pull' seems fair enough.
But what about 'rebase' and 'submodule'?
To what level should the Fossil-NG client support Git features not
present in Fossil?

If supported, wouldn't there be a risk of confusion when the user
wants to 'rebase'?
Even if commands such as 'pull' and 'pull' could be used
transparently, the user would have to take in consideration what kind
of backend is in use (Git or Fossil) before using 'rebase'.

If not supported, wouldn't there be a risk of users just sticking to
'git rebase' instead?


Sorry for not grasping the advantages about this idea.


>
> Both Fossil 2.x and Fossil-NG will be able to read and write the same
> Fossil repos, as long as you do not run use Fossil-NG features.  After
> you "rebuild" and start using Fossil-NG specific features, legacy
> Fossil-2.x clients might no longer work with that particular repo.
> This is the same situation that came up in the Fossil-1.37 to
> Fossil-2.0 transition.  That transition went smoothly and I expect the
> transition to Fossil-NG to be just as smooth.

Not a big deal, but will Fossil-NG repos be readable (the same way as
Fossil repos are) by sqlite3 from the command line?
(Currently I have a few scripts using that feature.)

Best Regards,
Johan
___
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-NG Bloat?

[Richard Hipp]

On 11/24/17, Johan Kuuse  wrote:
> I agree on that we would give up Fossil semantics.

I have no intent to "give up" or change the semantics of Fossil, and I
see no reason why enabling Fossil to push and pull from Git
repositories would require this.

Adding the ability to interact with Git is very much the same kind of
change as adding support for SHA3 hashes.  When Fossil 2.0 came out,
we didn't "give up" on the semantics of Fossil 1.37.  Most users
upgraded to Fossil 2.0 and never noticed any change at all.  Fossil
2.0 reads and writes legacy repos the same as it always did.  The only
thing that changed is that Fossil 2.0 also included the ability to
read/write repos that included artifacts with SHA3 hashes.  If none of
your repos have SHA3 hashes, then Fossil 1.37 and Fossil 2.0 are
completely interchangeable.  You only need Fossil 2.0 if you start
using repos that do include SHA3 hashes.

Likewise, moving from Fossil 2.x to Fossil-NG (whatever the version
number turns out to be) will be a non-issue for most users.  All the
commands will work the same when using legacy repos.  Fossil-NG merely
adds the ability to push and pull from Git.  If you don't use that
feature, then nothing changes.

Both Fossil 2.x and Fossil-NG will be able to read and write the same
Fossil repos, as long as you do not run use Fossil-NG features.  After
you "rebuild" and start using Fossil-NG specific features, legacy
Fossil-2.x clients might no longer work with that particular repo.
This is the same situation that came up in the Fossil-1.37 to
Fossil-2.0 transition.  That transition went smoothly and I expect the
transition to Fossil-NG to be just as smooth.
-- 
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] Fossil-NG Bloat?

[Ron W]

On Wed, Nov 22, 2017 at 7:09 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Wed, 22 Nov 2017 19:09:21 -0500
> From: Richard Hipp <d...@sqlite.org>
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> On 11/22/17, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:
> > I'm dubious over making Fossil a client for
> > any other main DVCS out there.
>
> One important reason that many people use Git is because so much OSS
> is hosted on GitHub and everybody wants to be part of the action.  If
> developer Alice wants to play in the OSS world, she has to use Git.
> But if Fossil were able to clone, push, and pull from Git
> repositories, that would enable Alice to use Fossil instead, opening
> the door to wider adoption.
>

But we give up Fossil semantics. And some of git'd semantics will require
extending the Fossil UI. And, if some of the UI ideas suggested would
actually change (instead of extending) the behavior of existing Fossil
commands. At that point, to my thinking, will be easier to use a proper git
client rather than translate git commands to Fossil commands.

Also, FWIW, it's been years since I last actually used git to "play in the
Github world". The projects I have been contributing to accept patches just
as readily as they accept pull requests, so I can just download a zip file,
update the "vendor branch" in my Fossil repo for the project, make and test
my changes, then make and send a patch.

(Yes, many project only accept pull requests. Just been a long time since
I've had a reason to contribute beyond a bug report (possibly including a
tiny patch).)
___
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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 21:35:31 -0700
Warren Young  wrote:

> The Fossil vs Git UI situation has been studied before.  There’s a
> tremendous amount of logical mismatch between the two, such that
> commands for one often cannot be translated 1:1 to the other.
> 
> Just as a single example:
> 
> $ fossil ci
> 
> is not at all the same thing as 
> 
> $ git commit
> 
> A better approximation is:
> 
> $ git commit -a && git push
> 
> And even then I’m sure I’m missing some details.
> 
> Now, here we have an example where Fossil is far clearer, as is the
> typical case, but that won’t make all the Git fans you show this to
> squee and insist that their projects switch to Fossil.
> 
> I’m reporting results here, not speculating.  I’ve tried it, and some
> kind of dismissal is almost always the result.  Why do you suppose
> that is?

I'm not saying there's anything wrong with the UI. In fact one of the
biggest reasons I started off with Mercurial was that Git was unusable
for me at the time. Then I came across Fossil which worked even better
than Mercurial. UI wise, Fossil is a clear winner in my books. However
my books aren't someone elses' books.
 
> What keeps these people using Git are network effects.  Most people
> decide that it’s better to put up with its horrible CLI or tie
> themselves to proprietary GUIs/web services — most prominently,
> GitHub — rather than lose out on all the benefits they get by being
> in the Git world.
> 
> We’ve been to this party before.  Linux vs Windows,
> Pascal/D/ObjC/Go/Rust/... vs C, etc., etc.  “Better” doesn’t always
> win.

And in that case, adding Git support to Fossil is unlikely to increase
its user base much. I vaguely recall Mercurial trying that, and this
didn't help them much, even though Mercurial is much easier to use than
Git.

> I’d say I have normal users: they want maximum results for minimum
> effort.
> 
> As do I.  Since I run the project server, what I say generally goes,
> but I ignore my users’ wishes at peril of losing my user base, thus
> risking a waste of my time writing software that no one will use.
> 
> There is not black or white here.  There is only gray.

They want maximum results for minimum effort? That may be normal, but
it's still whiney. Everyone wants this (that's normal), but it's a
difficult balance here between maintainability and servicing users
properly.

> 
> > Fossil supports downloading entire
> > checkins in zip and tarball archives  
> 
> I often end up hand-constructing such URLs for my users to click,
> because they can’t be bothered to dig through the UI to figure it out.
> 
> Here we have a case where Git is actually faster and clearer:
> 
>$ git clone https://example.com
> 
> vs.
> 
> 1. Visit https://example.com
> 2. Click Timeline (and how would my users know to do that?)
> 3. Click checkin ID.
> 4. Find and click Tarball link
> 5. Unpack the tarball
> 
> Then they must do all 5 steps again every time there is a new version
> they want, vs:
> 
>$ git pull

I agree with Zoltan's assessment, in that this is exaggerated.

You can just give users a direct link: https://example.com/tarball
This gives them the latest tarball every time.
The second step on the user's part is extracting the tarball:

  $ curl https://example.com/tarball | tar xzf -
 
> Fossil often can’t get to the simplicity of Git here for two reasons:
> 
> 1. Fossil may not be in the end user’s stock OS package repo.  (e.g.
> RHEL, CentOS.)
> 
> 2. If it is, it may be far too outdated to even work with the central
> repo.  (e.g. Debian, Raspbian.)
> 
> Thus we have to point users at precompiled binaries or instruct them
> in building from source, all of which makes Fossil look even more
> complicated than Git, when day-to-day, the reverse is true.  But you
> only realize that *after* you get Fossil up and running on your
> system.

With all these odds stacked up against Fossil's favor, adding Git/Hg
support as per the proposal is not going to help at all.

> I’m just cheerleading here.  It’s drh’s call what he spends his time
> on.  I trust his judgement.

As much as I agree, this kind of attitude does very little if gaining
extra users is what he wants to do. Then again, perhaps he's not too
bothered, which isn't a bad thing per se.

> By controlling variables, as any good scientific experiment does.
> Here, that means using the same filesystem, disks, etc.  If Fossil is
> reworked to use a Git-compatible pile-of-files repository format and
> performance doesn’t improve, then either:
> 
> 1. That wasn’t the source of the difference, so now we can check it
> off the list of things to look at; or
> 
> 2. There is an important difference in the implementations, which
> will now be easier to find, since both code bases are trying to
> achieve precisely the same end.
> 
> Contrast the state of things today, where comparisons are almost
> pointless, because Git and Fossil are comparable only at a skin-deep
> level.  They’re 

Re: [fossil-users] Fossil-NG Bloat?

[j. van den hoff]

On Thu, 23 Nov 2017 01:09:21 +0100, Richard Hipp  wrote:


On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:

I'm dubious over making Fossil a client for
any other main DVCS out there.


But making Fossil work as a client for Git is the cornerstone of my
plan for world domination!  :-)

One important reason that many people use Git is because so much OSS
is hosted on GitHub and everybody wants to be part of the action.  If
developer Alice wants to play in the OSS world, she has to use Git.
But if Fossil were able to clone, push, and pull from Git
repositories, that would enable Alice to use Fossil instead, opening
the door to wider adoption.


this might be true, but ...

1.
mercurial has tried this (for many years there have been extensions to use  
it as a client for git and subversion) and it does not seem to have  
increased adoption of mercurial substantially (probably not at all but who  
knows?). this is my major concern: if one can extrapolate from the hg  
story, chances for massively (or even modestly) increasing the fossil user  
community by making it work as a git client might be slight. a poll on  
github would be interesting (if it were possible): how many users are  
using hg locally to talk to github?


2.
my use of the mentioned hg-extensions with git and svs led to assorted  
problems for the simple reason that functionalities of the different  
systems do not map one-to-one. so one has continuously to remember that  
one is working in a (local) hg clone that will sync against a remote git  
or svs repo in the end and to observe the necessary restrictions. this  
makes it potentially more difficult and error prone than using the other  
tool directly. it is not necessarily a good "PR move" for a inherently  
superior/easier system one wants to push.


of course, if your plans come to fruition, I still would be happy to use  
the new functionality if it helps to reduce the pain of working with git  
repos. I am just skeptical regarding effort invested vs. benefit gained.  
other things would be further up on my wish list, e.g. history  
tracking/finfo across renames, full grep of content across revisions (hg  
does this very nicely, e.g.).


and (of course): thanks for fossil

joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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-NG Bloat?

[Gour]

On Wed, 22 Nov 2017 19:09:21 -0500
Richard Hipp  wrote:

> But making Fossil work as a client for Git is the cornerstone of my
> plan for world domination!  :-)

Go for it!

> One important reason that many people use Git is because so much OSS
> is hosted on GitHub and everybody wants to be part of the action.  If
> developer Alice wants to play in the OSS world, she has to use Git.
> But if Fossil were able to clone, push, and pull from Git
> repositories, that would enable Alice to use Fossil instead, opening
> the door to wider adoption.

Nothing to add to it!!


Sincerely,
Gour

-- 


___
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-NG Bloat?

[Zoltán Kócsi]

On Wed, 22 Nov 2017 21:35:31 -0700
Warren Young  wrote:

> [...]
> 1. Visit https://example.com
> 2. Click Timeline (and how would my users know to do that?)
> 3. Click checkin ID.
> 4. Find and click Tarball link
> 5. Unpack the tarball

Well, that's a bit of an exaggeration, I think.
You can put the link, with automatic generation of the ZIP/tar file of
the latest source, onto the Fossil home page of the project.

So in reality:

1. visit https://example.com/myproject
2. Click on the Dowload link
3. Unpack

Not that hard *and* you don't have to have Fossil, git or any other VCS
installed on your machine to get the stuff.

Regards,

Zoltan
___
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-NG Bloat?

[Warren Young]

On Nov 22, 2017, at 7:43 AM, bytevolc...@safe-mail.net wrote:
> 
> On Tue, 21 Nov 2017 16:42:56 -0700
> Warren Young  wrote:
> 
>>> This seems more like a complaint about the user interface.  
>> 
>> How does that observation get us to a different solution?
> 
> Because you then focus on tweaking the UI to make it better, rather
> than just stuffing support for other VCSes because of a few complaints
> about the UI.

The Fossil vs Git UI situation has been studied before.  There’s a tremendous 
amount of logical mismatch between the two, such that commands for one often 
cannot be translated 1:1 to the other.

Just as a single example:

$ fossil ci

is not at all the same thing as 

$ git commit

A better approximation is:

$ git commit -a && git push

And even then I’m sure I’m missing some details.

Now, here we have an example where Fossil is far clearer, as is the typical 
case, but that won’t make all the Git fans you show this to squee and insist 
that their projects switch to Fossil.

I’m reporting results here, not speculating.  I’ve tried it, and some kind of 
dismissal is almost always the result.  Why do you suppose that is?

What keeps these people using Git are network effects.  Most people decide that 
it’s better to put up with its horrible CLI or tie themselves to proprietary 
GUIs/web services — most prominently, GitHub — rather than lose out on all the 
benefits they get by being in the Git world.

We’ve been to this party before.  Linux vs Windows, Pascal/D/ObjC/Go/Rust/... 
vs C, etc., etc.  “Better” doesn’t always win.

>> What many of my public repos’ users want is Git, and I’m refusing
>> (today) to give it to them.
> 
> You clearly have very whiney users.

I’d say I have normal users: they want maximum results for minimum effort.

As do I.  Since I run the project server, what I say generally goes, but I 
ignore my users’ wishes at peril of losing my user base, thus risking a waste 
of my time writing software that no one will use.

There is not black or white here.  There is only gray.

> Fossil supports downloading entire
> checkins in zip and tarball archives

I often end up hand-constructing such URLs for my users to click, because they 
can’t be bothered to dig through the UI to figure it out.

Here we have a case where Git is actually faster and clearer:

   $ git clone https://example.com

vs.

1. Visit https://example.com
2. Click Timeline (and how would my users know to do that?)
3. Click checkin ID.
4. Find and click Tarball link
5. Unpack the tarball

Then they must do all 5 steps again every time there is a new version they 
want, vs:

   $ git pull

Fossil often can’t get to the simplicity of Git here for two reasons:

1. Fossil may not be in the end user’s stock OS package repo.  (e.g. RHEL, 
CentOS.)

2. If it is, it may be far too outdated to even work with the central repo.  
(e.g. Debian, Raspbian.)

Thus we have to point users at precompiled binaries or instruct them in 
building from source, all of which makes Fossil look even more complicated than 
Git, when day-to-day, the reverse is true.  But you only realize that *after* 
you get Fossil up and running on your system.

>> This proposal seems like a good way to enlarge the Fossil user base
>> by leveraging the same network effects that today work against Fossil.
> 
> So you are suggesting compromise Fossil's code maintainability and
> simplicity just for the sake of marketing values?

I’m just cheerleading here.  It’s drh’s call what he spends his time on.  I 
trust his judgement.

> implementing support for
> every rinky-dink VCS out there won't expand Fossil's user base by much.

Of course not.  But adding Git support alone will expand Fossil’s applicability 
tremendously.  We could pick up probably 90% of the public source repositories 
with that one move.  Adding Hg would probably add most of the remaining 10%.

>> The thing is, we don’t yet know how well that test corresponds to the
>> way Git uses the filesystem.  All we know today is that Git tends to
>> be faster than Fossil for equal workloads, even when things like
>> repo-cksum are accounted for.
> 
> And how will you test this out anyway? Git uses the file system,
> meaning any performance comparison with Git will depend entirely on
> what file system is in use.

By controlling variables, as any good scientific experiment does.  Here, that 
means using the same filesystem, disks, etc.  If Fossil is reworked to use a 
Git-compatible pile-of-files repository format and performance doesn’t improve, 
then either:

1. That wasn’t the source of the difference, so now we can check it off the 
list of things to look at; or

2. There is an important difference in the implementations, which will now be 
easier to find, since both code bases are trying to achieve precisely the same 
end.

Contrast the state of things today, where comparisons are almost pointless, 
because Git and Fossil are comparable only at a skin-deep 

Re: [fossil-users] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

On 22/11/17 19:09, Richard Hipp wrote:
> On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:
>> I'm dubious over making Fossil a client for
>> any other main DVCS out there.
> But making Fossil work as a client for Git is the cornerstone of my
> plan for world domination!  :-)
>
> One important reason that many people use Git is because so much OSS
> is hosted on GitHub and everybody wants to be part of the action.  If
> developer Alice wants to play in the OSS world, she has to use Git.
> But if Fossil were able to clone, push, and pull from Git
> repositories, that would enable Alice to use Fossil instead, opening
> the door to wider adoption.
>

I understand better now, thanks. In that context, Warren's proposal of a
single step clone + open, should be considered and improved. As long as
Fossil use/install keep as simple as now for Fossil users and current
users don't end with a kitchen sink and huge binary with a lot of flags
to support any workflow, I think your world domination plan can continue
without problem ;-).

Cheers,

Offray


___
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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 23:43:07 +
Javier Guerra Giraldez  wrote:

> i _have_ used fossil running in a very small MIPS system.  as
> mentioned, it's really nice to pull versioned stuff like
> configurations, HTML, binary blobs.  yes, i used gcc to compile it,
> but what was small two years ago now might be in the same boat as
> that.

GCC has C99 support for a long time: https://gcc.gnu.org/c99status.html

> all those features have zero impact on the generated machine code.

Apart from inline functions and postponed variable declarations. Even
if other features don't have impact on generated machine code, they can
make the code neater.

> > What sort of weird targets does SQLite run on which require the use
> > of a very old (or broken) compiler that can't handle any C99
> > features?  
> 
> MS Visual Studio

That compiler will only work on Windows, and only compiles for Windows.
Hardly a weird target that requires a compiler that can't handle the
basic C99 feature set I mentioned earlier.

In fact the latest MS Visual Studio has been gaining C99 support since
2013, and IIRC is fully compatible since 2015. There are still better
compilers out there such as Pelles C and Open Watcom (which also has
Win16/MS-DOS support) can do better.
___
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-NG Bloat?

[Richard Hipp]

On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:
> I'm dubious over making Fossil a client for
> any other main DVCS out there.

But making Fossil work as a client for Git is the cornerstone of my
plan for world domination!  :-)

One important reason that many people use Git is because so much OSS
is hosted on GitHub and everybody wants to be part of the action.  If
developer Alice wants to play in the OSS world, she has to use Git.
But if Fossil were able to clone, push, and pull from Git
repositories, that would enable Alice to use Fossil instead, opening
the door to wider adoption.

-- 
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] Fossil-NG Bloat?

[Javier Guerra Giraldez]

On 22 November 2017 at 23:09,   wrote:
> On Wed, 22 Nov 2017 17:30:10 +
> Javier Guerra Giraldez  wrote:
>> why not?  fossil makes for a neat deployment client!  yes, it can also
>> be done with just an http client, but still is a nice option to have.
>
> Because people do not use compilers on such systems, but rather, they
> use other systems that can compile for the target system.

i _have_ used fossil running in a very small MIPS system.  as
mentioned, it's really nice to pull versioned stuff like
configurations, HTML, binary blobs.  yes, i used gcc to compile it,
but what was small two years ago now might be in the same boat as
that.



>> but i haven't seen any reason to promote a language switch.   nice as
>> they are, C11 features make only easier development; not better code,
>> much less any performance improvement or any user-visible advantage.
>
> I am not suggesting a language switch (C11 is still C) and I'm also
> not suggesting just use C11 for the sake of it. Rather, I am suggesing
> using modern C features to clean up the code and allow the compiler to
> optimise it better. For example, postponed variable declarations,
> inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
> it's all basic C99 functionality which has been around for 18 years.

all those features have zero impact on the generated machine code.


> What sort of weird targets does SQLite run on which require the use of
> a very old (or broken) compiler that can't handle any C99 features?

MS Visual Studio

-- 
Javier
___
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-NG Bloat?

[bch]

On Wed, Nov 22, 2017 at 3:11 PM bch  wrote:

>
> On Wed, Nov 22, 2017 at 3:10 PM  wrote:
>
>> On Wed, 22 Nov 2017 17:30:10 +
>> Javier Guerra Giraldez  wrote:
>> > why not?  fossil makes for a neat deployment client!  yes, it can also
>> > be done with just an http client, but still is a nice option to have.
>>
>> Because people do not use compilers on such systems, but rather, they
>> use other systems that can compile for the target system.
>>
>> > but i haven't seen any reason to promote a language switch.   nice as
>> > they are, C11 features make only easier development; not better code,
>> > much less any performance improvement or any user-visible advantage.
>>
>> I am not suggesting a language switch (C11 is still C) and I'm also
>> not suggesting just use C11 for the sake of it. Rather, I am suggesing
>> using modern C features to clean up the code and allow the compiler to
>> optimise it better. For example, postponed variable declarations,
>> inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
>> it's all basic C99 functionality which has been around for 18 years.
>>
>> > SQLite _is_ used on lots of weird targets, and there's much shared
>> > code, and most importantly, shared code style.  introducing an
>> > artificial split between them doesn't seem a good use of developer
>> > time.
>>
>> What sort of weird targets does SQLite run on which require the use of
>> a very old (or broken) compiler that can't handle any C99 features?
>
>
I don’t have access anymore, but I have supported “obscure” operating
systems on old hardware before for important production work. I wish I
could recall what the vintage of the required native compiler. Maybe it
*would* have passed C99 requirements. Some people will definitely know, but
for those that don’t, it’s important to know that all the Unix world is not
a modern Linux box.



>> ___
>> 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-NG Bloat?

[bch]

On Wed, Nov 22, 2017 at 3:10 PM  wrote:

> On Wed, 22 Nov 2017 17:30:10 +
> Javier Guerra Giraldez  wrote:
> > why not?  fossil makes for a neat deployment client!  yes, it can also
> > be done with just an http client, but still is a nice option to have.
>
> Because people do not use compilers on such systems, but rather, they
> use other systems that can compile for the target system.
>
> > but i haven't seen any reason to promote a language switch.   nice as
> > they are, C11 features make only easier development; not better code,
> > much less any performance improvement or any user-visible advantage.
>
> I am not suggesting a language switch (C11 is still C) and I'm also
> not suggesting just use C11 for the sake of it. Rather, I am suggesing
> using modern C features to clean up the code and allow the compiler to
> optimise it better. For example, postponed variable declarations,
> inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
> it's all basic C99 functionality which has been around for 18 years.
>
> > SQLite _is_ used on lots of weird targets, and there's much shared
> > code, and most importantly, shared code style.  introducing an
> > artificial split between them doesn't seem a good use of developer
> > time.
>
> What sort of weird targets does SQLite run on which require the use of
> a very old (or broken) compiler that can't handle any C99 features?
> ___
> 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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 17:30:10 +
Javier Guerra Giraldez  wrote:
> why not?  fossil makes for a neat deployment client!  yes, it can also
> be done with just an http client, but still is a nice option to have.

Because people do not use compilers on such systems, but rather, they
use other systems that can compile for the target system.

> but i haven't seen any reason to promote a language switch.   nice as
> they are, C11 features make only easier development; not better code,
> much less any performance improvement or any user-visible advantage.

I am not suggesting a language switch (C11 is still C) and I'm also
not suggesting just use C11 for the sake of it. Rather, I am suggesing
using modern C features to clean up the code and allow the compiler to
optimise it better. For example, postponed variable declarations,
inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
it's all basic C99 functionality which has been around for 18 years.

> SQLite _is_ used on lots of weird targets, and there's much shared
> code, and most importantly, shared code style.  introducing an
> artificial split between them doesn't seem a good use of developer
> time.

What sort of weird targets does SQLite run on which require the use of
a very old (or broken) compiler that can't handle any C99 features?
___
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-NG Bloat?

[Thomas]

On 2017-11-22 22:43, Thomas wrote:
That was also my understanding in the beginning but it turned out I was 
(terribly) wrong. You got to synchronise them manually, and then they're 
not pulled automatically either.


I second this approach. Since Fossil already uses "unversioned" for the 
current implementation, and I believe it might otherwise confuse users 
used to the current process, I'd suggest a different name for a more 
natural "unversioned" behaviour.


Laymen would understand "unversioned" like normal files (or artifacts) 
without history tracking. You just want to add them to the repository 
without keeping less recent versions. Absolutely natural in my opinion. 
The most recent version is uploaded and kept. Previous versions 
disappear into nimbo.


How about calling this suggested new behaviour "historyless artifacts"?


Or "historyless content"?

___
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-NG Bloat?

[Thomas]

On 2017-11-22 22:27, Offray Vladimir Luna Cárdenas wrote:

2) Allow me to designate any file in the directory structure as
unversioned.  The current unversioning model does not work well for
me.  It essentially is equivalent to Dropbox. I am working with
PharoJS which produces Javascript files from Smalltalk code. I want my
source code and the generated code in Fossil. I also have movies and
image files that I want in particular places.  I realize the Fossil
model is to be able to revert to exactly the state of things on
such-and-such a date, including the versions of movies and images as
they were, but I - at least - very rarely care that images and movies
are exactly as they were, I'd almost always be perfectly happy using
the current version. An ideal alternative would be to have versioned
files but where it only kept snapshots of versions I explicitly asked
for, otherwise it would just update the current version.


I'm still trying to understand unversioned files. What I would like is
to make them sync automatically when the rest of the repo is
synchronized (via sync or commit). Something like if the unversioned
file changed locally, just send the new version to the remote repo. If
that is the intended behavior, there is something in the workflow I'm
missing.


That was also my understanding in the beginning but it turned out I was 
(terribly) wrong. You got to synchronise them manually, and then they're 
not pulled automatically either.


I second this approach. Since Fossil already uses "unversioned" for the 
current implementation, and I believe it might otherwise confuse users 
used to the current process, I'd suggest a different name for a more 
natural "unversioned" behaviour.


Laymen would understand "unversioned" like normal files (or artifacts) 
without history tracking. You just want to add them to the repository 
without keeping less recent versions. Absolutely natural in my opinion. 
The most recent version is uploaded and kept. Previous versions 
disappear into nimbo.


How about calling this suggested new behaviour "historyless artifacts"?
___
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-NG Bloat?

[Offray Vladimir Luna Cárdenas]

Hi Dave,


On 22/11/17 15:27, David Mason wrote:
> Also as a mere fossil user, I would find it useful if fossil could
> respond to a git client and serve files. I use Pharo, which is working
> toward integrated support for git, but I'd much rather trust my bits
> to Fossil. While the Fossil UI is nice, I see much less value in using
> a local Fossil to access a remote git/hg repo.

I'm also a Pharo User. I think that is important let a Fossil be
employed by Git clients, but I'm dubious over making Fossil a client for
any other main DVCS out there. Fossil's web interface has been pretty
useful in our workshops on data activism and visualization over there to
teach newbies (like myself) about DVCS. BTW I understand that this is
not a discussion on the capability of more expert users and devs to
implement the idea, but about how it impacts the wider community. I for
example didn't understand the original discussion about ".fossil"
because I thought it was (only) about shallow copies instead of the
default behavior for making a single step clone and open, like Git.
Making Fossil a client of majors DVCS means learning a lot of variations
on what happens to make it behave like others. Of course, we need to see
where it makes sense, but the context/motivation of that discussion will
be difficult and sometimes will scape for those of us that chose Fossil
because it was like itself, instead of because was like others.

Support for multiple VCS formats is clear as a server, but the nuances
and complexities code/learning wise it will introduce as a client should
be considered for those of us that like/choose Fossil because of its
simplicity.


>
> 2) Allow me to designate any file in the directory structure as
> unversioned.  The current unversioning model does not work well for
> me.  It essentially is equivalent to Dropbox. I am working with
> PharoJS which produces Javascript files from Smalltalk code. I want my
> source code and the generated code in Fossil. I also have movies and
> image files that I want in particular places.  I realize the Fossil
> model is to be able to revert to exactly the state of things on
> such-and-such a date, including the versions of movies and images as
> they were, but I - at least - very rarely care that images and movies
> are exactly as they were, I'd almost always be perfectly happy using
> the current version. An ideal alternative would be to have versioned
> files but where it only kept snapshots of versions I explicitly asked
> for, otherwise it would just update the current version.

I'm still trying to understand unversioned files. What I would like is
to make them sync automatically when the rest of the repo is
synchronized (via sync or commit). Something like if the unversioned
file changed locally, just send the new version to the remote repo. If
that is the intended behavior, there is something in the workflow I'm
missing.

>
> Thanks for fossil!
>

Yes. Thanks a lot!

Offray

___
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-NG Bloat?

[David Mason]

Also as a mere fossil user, I would find it useful if fossil could respond
to a git client and serve files. I use Pharo, which is working toward
integrated support for git, but I'd much rather trust my bits to Fossil.
While the Fossil UI is nice, I see much less value in using a local Fossil
to access a remote git/hg repo.

There are two things that are much more relevant for me:

1) Improvements to ignoring files. One solution is per-directory .fslignore
file (like git and hg have) so I can get better granularity on ignoring
files. In particular I would like to generally ignore .class files as being
Java binaries, but another tool I use generates .class as an extension for
directories that contain class methods (as opposed to instance methods). An
alternative that works for this problem would be a way to specify in a glob
file that a match was for directories vs. files, or to have include globs
so I could ignore *.class but accept *.class/*

2) Allow me to designate any file in the directory structure as
unversioned.  The current unversioning model does not work well for me.  It
essentially is equivalent to Dropbox. I am working with PharoJS which
produces Javascript files from Smalltalk code. I want my source code and
the generated code in Fossil. I also have movies and image files that I
want in particular places.  I realize the Fossil model is to be able to
revert to exactly the state of things on such-and-such a date, including
the versions of movies and images as they were, but I - at least - very
rarely care that images and movies are exactly as they were, I'd almost
always be perfectly happy using the current version. An ideal alternative
would be to have versioned files but where it only kept snapshots of
versions I explicitly asked for, otherwise it would just update the current
version.

Thanks for fossil!

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

Re: [fossil-users] Fossil-NG Bloat?

[Javier Guerra Giraldez]

On 22 November 2017 at 14:43,   wrote:
> Nobody in their right mind would even consider Fossil (with its
> in-built web server, wiki, and bugtracker) to run on such a system, so
> why bother coding for it?

why not?  fossil makes for a neat deployment client!  yes, it can also
be done with just an http client, but still is a nice option to have.

but i haven't seen any reason to promote a language switch.   nice as
they are, C11 features make only easier development; not better code,
much less any performance improvement or any user-visible advantage.

SQLite _is_ used on lots of weird targets, and there's much shared
code, and most importantly, shared code style.  introducing an
artificial split between them doesn't seem a good use of developer
time.

-- 
Javier
___
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-NG Bloat?

[bytevolcano]

On Tue, 21 Nov 2017 16:42:56 -0700
Warren Young  wrote:

> > This seems more like a complaint about the user interface.  
> 
> How does that observation get us to a different solution?

Because you then focus on tweaking the UI to make it better, rather
than just stuffing support for other VCSes because of a few complaints
about the UI.
 
> If someone has been using Git for years and I point them at my fine
> Fossil repository, they’re not going to be happy switching, even if
> they do eventually agree that Fossil is better.  That transition cost
> must still be paid.
> 
> What many of my public repos’ users want is Git, and I’m refusing
> (today) to give it to them.
> 
> This proposed feature set might well fix that problem, with zero
> effort on my part.

You clearly have very whiney users. Fossil supports downloading entire
checkins in zip and tarball archives, so your users can just do that.
As far as I can tell, there is no problem. They can just download
Fossil and clone, then export to Git. It may be lossy, but Git!=Fossil.

> 
> What is your alternative?  Force the world to switch to Fossil?  Tell
> the Git fans to pound sand?

My alternative is to just use the right tools for the job. Sometimes
that is Fossil, sometimes that is Git, and sometimes that is Subversion.

> This proposal seems like a good way to enlarge the Fossil user base
> by leveraging the same network effects that today work against Fossil.

So you are suggesting compromise Fossil's code maintainability and
simplicity just for the sake of marketing values?

> 
> > Subversion should implement native Git support,
> > and Mercurial should implement native CVS support.  
> 
> The other VCSes will have to come to whatever accommodation with the
> realities of the Git network effects their developer communities are
> willing to strive for.

And Fossil is no different.

> Someone probably once told him it’s too difficult to implement a
> SQL92 compatible RDBMS, too.

I never said it would be too difficult for him, but rather it would
introduce unneeded code complexity and bloat. If people want to use
Git, they can use Git. Use the right tool for the job.

> > You will also find that tool developers may just get rid of existing
> > Fossil support (if it ever existed) because oh well, Fossil can
> > support Git so no problem.  
> 
> I’d bet there are many more tools that support Git but not Fossil
> today than those that support Fossil, irrespective of whether they
> also support Git.
> 
> If so, it’s a net win, even if it shakes out exactly like you
> suppose, which it won’t.

What I was trying to say here is that just implementing support for
every rinky-dink VCS out there won't expand Fossil's user base by much.
Those that want Git will use Git, those that want Subversion will use
Subversion.

> 
> > Let's face it, the SQLite single-file storage mechanism has a
> > number of other advantages over the pile-of-files methods, even if
> > performance isn't one of them.  
> 
> I didn’t mean to imply that I thought that was the case, only that we
> can’t know until it’s tested, because science.
> 
> We have some science that shows it’s the other way around:
> 
> https://www.sqlite.org/fasterthanfs.html
> 
> The thing is, we don’t yet know how well that test corresponds to the
> way Git uses the filesystem.  All we know today is that Git tends to
> be faster than Fossil for equal workloads, even when things like
> repo-cksum are accounted for.

And how will you test this out anyway? Git uses the file system,
meaning any performance comparison with Git will depend entirely on
what file system is in use.

> If that seems like a non sequitur with respect to Fossil, I’d be
> interested to see benchmark results that show any common use case
> where Fossil’s performance is dominated by time spent *outside*
> SQLite code.  Lacking such data, I’ll continue to assume that there’s
> little point optimizing Fossil proper.  The same effort spent
> optimizing SQLite and the SQL that Fossil gives to SQLite is time
> better spent.

You make a good point here, and I agree. SQLite is the majority of
Fossil's code base. It may be worth looking at queries to see how they
can be optimised as well.

> If you do come up with such a benchmark, and it involves the network,
> then be sure to account for the time spent waiting for network I/O
> separately, unless reworking Fossil somehow reduces time spent
> waiting on the network.  A 10 ms HTTP transaction where 999 µs of
> that is spent in Fossil and 1 µs is spent in SQLite doesn’t count as
> “dominated by Fossil code.”   Until you get the network time down
> from the 9 ms in this made-up example to more like 3 ms, there’s
> little point worrying about the Fossil contribution to the
> transaction time.

True, but I was thinking more in terms of local working directories
(commit/merge/etc rather than pull/push/sync/etc).

> Infrastructure software like Fossil generally needs to be able to
> 

Re: [fossil-users] Fossil-NG Bloat?

[Zoltán Kócsi]

On Tue, 21 Nov 2017 17:35:04 -0700
Warren Young  wrote:

> A great many embedded projects use Keil and IAR C, for example.  As
> far as I’m aware, Keil doesn’t do C11 yet, and IAR didn’t get support
> for it until earlier this year.  
> 
> It’s quite common in the embedded space to buy a version of the
> commercial compiler, let the one-year maintenance period expire, and
> keep using the old version rather than pay yearly maintenance.  I’ve
> heard of embedded projects where the compiler is checked into the VCS
> alongside the source, since they intend to never upgrade it.

Yes, I'm aware of that - I've been in the embedded system business for
a long time. In fact, if you use a commercial compiler, you'd better
save it, and the OS that can run it, and hardware to run the OS (or a
suitable emulator) for there's no guarantee that the compiler vendor or
any other part of the build chain will be around in 2, 5, 10, 20 years
time. Ever used Introl compilers? Or Lattice (later SAS)? 

But what I'm saying is that if you archive your compiler for the
project, then you can (and should) also archive whatever other 3rd party
software you use, for example SQLite. 

Even if you use open source tools that's the case. There are embedded
systems out there that can't be compiled with gcc more modern than 2.95
(i.e. pre-EGCS). But that hasn't stopped gcc to evolve. The fact that
there are devices that were built with SQLite 1.0 using WhizzBangC+-
0.01alpha 15+ years ago shouldn't hinder SQLite 3.x or 4.x and it could
safely step forward from C89 to C99. That standard is over 15 years old
and most commercial compilers has supported it for years.

Nevertheless, this has very little to do with the actual issue of
git/CVS/mercurial/whatever support in Fossil, so I shut up.

Regards,

Zoltan
___
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-NG Bloat?

[Offray Vladimir Luna Cárdenas]

On 21/11/17 19:42, Warren Young wrote:
> On Nov 21, 2017, at 5:22 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
>> I don't see the point of raising this in the users list if
>> any voice we raise as users is answered as dumb or rudely by more
>> experienced users or devs.
> Since you’re replying to me, I can only take that reply as saying that my 
> reply implies that you or others are dumb, or that I am being rude.
>
> I do not intend to be rude, and I don’t think anyone here is dumb.
>
> I thought we were having a rational discussion.  Are we not?

Mostly. Unfortunately rational and polite are not always in hand. Some
FLOSS communities are evolving into having both.

Offray

___
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-NG Bloat?

[Warren Young]

On Nov 21, 2017, at 5:22 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> I don't see the point of raising this in the users list if
> any voice we raise as users is answered as dumb or rudely by more
> experienced users or devs.

Since you’re replying to me, I can only take that reply as saying that my reply 
implies that you or others are dumb, or that I am being rude.

I do not intend to be rude, and I don’t think anyone here is dumb.

I thought we were having a rational discussion.  Are we not?
___
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-NG Bloat?

[Warren Young]

On Nov 21, 2017, at 5:21 PM, Zoltán Kócsi  wrote:
> 
> On Tue, 21 Nov 2017 16:42:56 -0700
> Warren Young  wrote:
> 
>> [...]
>> 
>> There are some truly bletcherous C compilers in the embedded space.
> 
> Well, I have some reservations about accepting that an embedded system
> that has KB range restrictions would use SQLite. 

I thought that went without saying.

There’s a big range of C compilers between my 4 kWord compiler and GCC.  
Switching to GCC is not always an option.

A great many embedded projects use Keil and IAR C, for example.  As far as I’m 
aware, Keil doesn’t do C11 yet, and IAR didn’t get support for it until earlier 
this year.  

It’s quite common in the embedded space to buy a version of the commercial 
compiler, let the one-year maintenance period expire, and keep using the old 
version rather than pay yearly maintenance.  I’ve heard of embedded projects 
where the compiler is checked into the VCS alongside the source, since they 
intend to never upgrade it.
___
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-NG Bloat?

[Scott Robison]

On phone, apologies in advance for top posting...

The value I see from multi vcs support isn't providing easy setup of
hosting one repo on multiple formats (though that would be awesome). I like
the idea of using fossil at work where I'm forced to use git (or Perforce,
though that hasn't been mentioned). I would love a sane command line with
integrated web UI to access multiple repository formats.

I support the idea and would love to help with it. I think a VFS-ish API to
"simplify" integration of multiple formats would be great. If you didn't
want to support multiple repository formats or use fossil with other
formats, I can imagine it being simple to compile the other ones out. But
if I never had to use another vcs directly ever again, I'd be happy.

On Nov 21, 2017 5:22 PM, "Offray Vladimir Luna Cárdenas" 
wrote:

> I agreed with Zoltán as also just a mortal Fossil user. Of course time
> will tell if the path of Fossil-NG serves well current and future users
> and others and of course everybody does what they want with their time
> and effort. I don't see the point of raising this in the users list if
> any voice we raise as users is answered as dumb or rudely by more
> experienced users or devs.
>
> Cheers,
>
> Offray
>
>
> On 21/11/17 18:52, Warren Young wrote:
> > On Nov 21, 2017, at 4:44 PM, Zoltán Kócsi  wrote:
> >> Adding unnecessary complexity to its innermost workings would open the
> >> door to a maintenance hell, I think.
> > If it were someone else proposing this feature as something for drh to
> do, then I might well agree with you, but since it is drh proposing work
> that drh will almost certainly end up doing, that changes things
> drastically.
> >
> > Not only is it his time to do with as he pleases, he also has a far
> better chance of pulling this off, any personal brilliance aside, purely
> because it’s apparently his own itch.
> >
> > Thus I cheerlead.
> > ___
> > 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] Fossil-NG Bloat?

[Offray Vladimir Luna Cárdenas]

I agreed with Zoltán as also just a mortal Fossil user. Of course time
will tell if the path of Fossil-NG serves well current and future users
and others and of course everybody does what they want with their time
and effort. I don't see the point of raising this in the users list if
any voice we raise as users is answered as dumb or rudely by more
experienced users or devs.

Cheers,

Offray


On 21/11/17 18:52, Warren Young wrote:
> On Nov 21, 2017, at 4:44 PM, Zoltán Kócsi  wrote:
>> Adding unnecessary complexity to its innermost workings would open the
>> door to a maintenance hell, I think.
> If it were someone else proposing this feature as something for drh to do, 
> then I might well agree with you, but since it is drh proposing work that drh 
> will almost certainly end up doing, that changes things drastically.
>
> Not only is it his time to do with as he pleases, he also has a far better 
> chance of pulling this off, any personal brilliance aside, purely because 
> it’s apparently his own itch.
>
> Thus I cheerlead.
> ___
> 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-NG Bloat?

[Zoltán Kócsi]

On Tue, 21 Nov 2017 16:42:56 -0700
Warren Young  wrote:

> [...]
> 
> There are some truly bletcherous C compilers in the embedded space.
> 
> I was trying to use one the other day that runs in 4 kwords of
> space.  Among its long list of misfeatures is that it will recognize
> a do/while loop, and it will produce assembly output for it, but the
> result either will not assemble or it won’t run correctly if you do
> manage to get it to assemble!

Well, I have some reservations about accepting that an embedded system
that has KB range restrictions would use SQLite. You won't compile
SQLite for an 8051 or PIC or 8-bit AVR. And if you're in the league of
M68K and up, gcc is there. Note the M68K is an almost 40 years old core.

If you have maintain a 10+ year old embedded system with a
non-mainstream chip, that was built using some weird compiler of *that*
day and which happened to use SQLite of *that* day, you can use the 10+
year old SQLite source, just as you have to use the 10+ year old
compiler to compile your own code for that system.

On the other hand, if you want to build an embedded system with SQLite
today, you would quite likely use a modern CPU (ARM chips are dirt
cheap, often cheaper than an 8-bitter) for which you can use a modern
compiler (e.g. gcc), so you're not restricted to C89 or earlier.

Regards,

Zoltan
___
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-NG Bloat?

[Warren Young]

On Nov 21, 2017, at 4:44 PM, Zoltán Kócsi  wrote:
> 
> Adding unnecessary complexity to its innermost workings would open the
> door to a maintenance hell, I think.

If it were someone else proposing this feature as something for drh to do, then 
I might well agree with you, but since it is drh proposing work that drh will 
almost certainly end up doing, that changes things drastically.

Not only is it his time to do with as he pleases, he also has a far better 
chance of pulling this off, any personal brilliance aside, purely because it’s 
apparently his own itch.

Thus I cheerlead.
___
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-NG Bloat?

[Zoltán Kócsi]

I'm just a Fossil user, not a developer. Don't want to intrude, just
share my thoughts from that perspective.

I work on open source as well as closed source commercial stuff. It's
usually relatively small projects, maybe a few hundred KLOC each.

When I had to select a VCS, I looked at all the usual suspects and then
settled on Fossil. Basically, because it was simple. Simple to install,
simple to use, simple to maintain. It had (almost) everything I needed,
including the bug tracking and the wiki, which makes project management
a breeze.

If someone wants more in-depth access to the projects than what they
can get through the web interface, they can install Fossil in about 5
minutes. If they have the slightest clue about distributed version
control, they will be able to clone, check out and check in stuff after
a few hours of digging around.

If I wanted to give git access to these projects, I would have chosen
git. There are people who keep their projects on git, others on CVS and
on whatever. If I want to get involved, I have to install and learn to
use git or CVS. This is the same with Fossil. Only that learning Fossil
is actually less work.

From my perspective, as a humble user, there are quite a handful of
things that could improve Fossil, like merging between branches on a
file by file basis (which, I believe, git can easily do), more capable
Tcl stuff (where the Tcl engine has more access to data as well as
operations). Not to mention proper documentation, however boring it is
to write it.

But Fossil being able to be Git and CVS and half a dozen other version
control systems simultaneously is most certainly not a feature I
miss. Fossil being able to do things that git can and Fossil can't
would be a lot more important to me.

Of course I'm just one user with my particular circumstances and goals.
But I believe Fossil serves a niche. It is a clean, lean yet reasonably
capable and efficient tool, quite good for relatively small projects.
Adding unnecessary complexity to its innermost workings would open the
door to a maintenance hell, I think.

Regards,

Zoltan
___
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-NG Bloat?

[Warren Young]

On Nov 21, 2017, at 3:55 PM, bytevolc...@safe-mail.net wrote:
> 
> On Mon, 20 Nov 2017 17:44:49 -0700
> Warren Young  wrote:
>> 
>> …muscle memory for both Fossil partisans and for partisans of other
>> VCSes.
> 
> This seems more like a complaint about the user interface.

How does that observation get us to a different solution?

If someone has been using Git for years and I point them at my fine Fossil 
repository, they’re not going to be happy switching, even if they do eventually 
agree that Fossil is better.  That transition cost must still be paid.

What many of my public repos’ users want is Git, and I’m refusing (today) to 
give it to them.

This proposed feature set might well fix that problem, with zero effort on my 
part.

What is your alternative?  Force the world to switch to Fossil?  Tell the Git 
fans to pound sand?

This proposal seems like a good way to enlarge the Fossil user base by 
leveraging the same network effects that today work against Fossil.

> Subversion should implement native Git support,
> and Mercurial should implement native CVS support.

The other VCSes will have to come to whatever accommodation with the realities 
of the Git network effects their developer communities are willing to strive 
for.

> The idea being proposed appears to be that Fossil repositories should
> be able to store artifacts in multiple different formats, which will
> only be a disaster since the "legacy" Git/SVN/CVS clients cannot read
> that kind of repository anyway.

I’m not enough of an expert on any of these file formats to know if the 
conclusion follows from the premise.  I assume drh is, who proposed it, and 
will likely be doing the bulk of the work.

So, let’s just wait and see.

Someone probably once told him it’s too difficult to implement a SQL92 
compatible RDBMS, too.

>>> svn > cvs > fossil, often stopping at git or hg.  If Fossil could
>>> offer a Git or Hg view of the same data and take pushes losslessly
>>> via that same format, we wouldn’t have to keep blindly hoping that
>>> tool developers would add Fossil support.
> 
> You will also find that tool developers may just get rid of existing
> Fossil support (if it ever existed) because oh well, Fossil can support
> Git so no problem.

I’d bet there are many more tools that support Git but not Fossil today than 
those that support Fossil, irrespective of whether they also support Git.

If so, it’s a net win, even if it shakes out exactly like you suppose, which it 
won’t.

> Let's face it, the SQLite single-file storage mechanism has a
> number of other advantages over the pile-of-files methods, even if
> performance isn't one of them.

I didn’t mean to imply that I thought that was the case, only that we can’t 
know until it’s tested, because science.

We have some science that shows it’s the other way around:

https://www.sqlite.org/fasterthanfs.html

The thing is, we don’t yet know how well that test corresponds to the way Git 
uses the filesystem.  All we know today is that Git tends to be faster than 
Fossil for equal workloads, even when things like repo-cksum are accounted for.

Also, realize that you’re talking to a raging Fossil partisan here.  You don’t 
need to sell me on its virtues.

> Profiling and optimising the most frequently called routines will help.

Do you believe that is not already being done?

How else do you suppose new versions of SQLite regularly come out showing 
faster performance for some use case?

If that seems like a non sequitur with respect to Fossil, I’d be interested to 
see benchmark results that show any common use case where Fossil’s performance 
is dominated by time spent *outside* SQLite code.  Lacking such data, I’ll 
continue to assume that there’s little point optimizing Fossil proper.  The 
same effort spent optimizing SQLite and the SQL that Fossil gives to SQLite is 
time better spent.

If you do come up with such a benchmark, and it involves the network, then be 
sure to account for the time spent waiting for network I/O separately, unless 
reworking Fossil somehow reduces time spent waiting on the network.  A 10 ms 
HTTP transaction where 999 µs of that is spent in Fossil and 1 µs is spent in 
SQLite doesn’t count as “dominated by Fossil code.”   Until you get the network 
time down from the 9 ms in this made-up example to more like 3 ms, there’s 
little point worrying about the Fossil contribution to the transaction time.

> Not coding like it's 1989 and use modern C99/C11 (eg. postpone variable
> declarations, declaring variables in a for(...) loop, uint_XX_t,
> inline, etc) will also help.

Infrastructure software like Fossil generally needs to be able to compile on 
~10 year old systems.  That means someone is probably still building Fossil 
today using Visual C++ 2005, which had terrible C99 support and likely 
supported little that eventually appeared in C11 aside from features that C 
borrowed from C++.

SQLite made up roughly half the Fossil C code 

Re: [fossil-users] Fossil-NG Bloat?

[bytevolcano]

On Mon, 20 Nov 2017 17:44:49 -0700
Warren Young  wrote:

> On Nov 20, 2017, at 4:57 PM, bytevolc...@safe-mail.net wrote:
> > 
> > Why add more complexity and bloat to the Fossil core?  
> 
> Because interoperability.  One of the major arguments against using
> Fossil is that it’s largely a one-way transition today, which messes
> up muscle memory for both Fossil partisans and for partisans of other
> VCSes.

This seems more like a complaint about the user interface.

> I’ve had people wish for Git access to my largest public Fossil
> repository multiple times, and it’s got a pretty small community.  I
> imagine providers of large public Fossil repos get this complaint all
> the time.

Of course. So next up, Subversion should implement native Git support,
and Mercurial should implement native CVS support.

> 
> fossil export solves this to only a limited extent.  The translation
> is lossy in the primary direction and even lossier in the reverse
> direction.
> 
> I assume the idea here is to reduce the impedance mismatch between
> the formats.

The idea being proposed appears to be that Fossil repositories should
be able to store artifacts in multiple different formats, which will
only be a disaster since the "legacy" Git/SVN/CVS clients cannot read
that kind of repository anyway. Thus, this idea is just bloat.

> 
> Also valuable is that developer tool support generally goes git > hg
> > svn > cvs > fossil, often stopping at git or hg.  If Fossil could
> > offer a Git or Hg view of the same data and take pushes losslessly
> > via that same format, we wouldn’t have to keep blindly hoping that
> > tool developers would add Fossil support.

You will also find that tool developers may just get rid of existing
Fossil support (if it ever existed) because oh well, Fossil can support
Git so no problem.

> 
> There’s precedence for having multiple backends, most notably svn.
> If nothing else, this will let us make apples-to-apples performance
> comparisons.  Is git’s speed advantage due in any meaningful part to
> its use of a pile-of-files repo format, or is SQLite’s single-file
> indexed declarative access approach superior?  We can largely only
> speculate today.  With this change, we can KNOW.

Adding tightly integrated support for other VCS software may just give
you an apples-to-gorillas comparison instead, since the overhead of the
proposed feature set will slow Fossil down even more and skew the
result. Let's face it, the SQLite single-file storage mechanism has a
number of other advantages over the pile-of-files methods, even if
performance isn't one of them.

There are other means of optimisation that can be used first.

Profiling and optimising the most frequently called routines will help.
Not coding like it's 1989 and use modern C99/C11 (eg. postpone variable
declarations, declaring variables in a for(...) loop, uint_XX_t,
inline, etc) will also help.
___
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-NG Bloat?

[Warren Young]

On Nov 20, 2017, at 4:57 PM, bytevolc...@safe-mail.net wrote:
> 
> Why add more complexity and bloat to the Fossil core?

Because interoperability.  One of the major arguments against using Fossil is 
that it’s largely a one-way transition today, which messes up muscle memory for 
both Fossil partisans and for partisans of other VCSes.

I’ve had people wish for Git access to my largest public Fossil repository 
multiple times, and it’s got a pretty small community.  I imagine providers of 
large public Fossil repos get this complaint all the time.

fossil export solves this to only a limited extent.  The translation is lossy 
in the primary direction and even lossier in the reverse direction.

I assume the idea here is to reduce the impedance mismatch between the formats.

Also valuable is that developer tool support generally goes git > hg > svn > 
cvs > fossil, often stopping at git or hg.  If Fossil could offer a Git or Hg 
view of the same data and take pushes losslessly via that same format, we 
wouldn’t have to keep blindly hoping that tool developers would add Fossil 
support.

There’s precedence for having multiple backends, most notably svn.  If nothing 
else, this will let us make apples-to-apples performance comparisons.  Is git’s 
speed advantage due in any meaningful part to its use of a pile-of-files repo 
format, or is SQLite’s single-file indexed declarative access approach 
superior?  We can largely only speculate today.  With this change, we can KNOW.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users