[fossil-users] Fossil-NG ideas

[Warren Young]

I see a new wiki article:

https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

I’m glad to see shallow and narrow clones being planned.

The section on narrow clones should specify whether these can take on a life independent of the parent repository. That is, can they be used to shard a repository, such as one where each top level directory (TLD) is a separate project with no cross-TLD checkins? What happens if the narrow clone is re-shared?

$ fossil clone --narrow src https://example.com/x x-src.fossil
$ mkdir x
$ cd x
$ fossil open ../x-src.fossil
$ fossil server

If I then clone this narrow repository, does the clone’s /file URL show files present at the root of the grandparent repository and not available in the parent?

I’d also like to be able to choose to make this permanent, popping a layer of the directory hierarchy, so that the narrow clone’s /file URL shows the contents of /src by default, not a lone “src” subdirectory.

If there are cross-TLD checkins in this scenario, does the clone fail, warn, or proceed silently? It may be an important matter of policy since if checkin [1234abcd] is a cross-TLD checkin, “fossil up 1234abcd” means something different in a narrow clone than in a complete clone.

I bring all of this up because I’d like both major behaviors for different use cases:

1. Sharded repositories where the permanently-narrow clones are re-shared under new names with no intention of going back and widening any of them, so the clone operation should warn if the clone has checkins that are incomplete because of the narrowing. This would be used to break up multi-project repositories into individual repositories.

2. Temporary narrow clones which simply save bandwidth and disk space, which automatically widen later on demand. If you roll back to a checkin that refers to artifacts not present in the local clone but they are present in the remote, the artifacts should be fetched at that point.

It wouldn’t break my heart if we only get behavior #2 at first, since the resulting repository should still be faster as well as smaller, simply due to the limits of logarithmic scaling. But I would like frosting on my cupcake, too, if I can get it. :)


Topic shift:

There is one more thing Git really gets right compared to Fossil: single-step clone-and-open. We should be able to do the same:

$ fossil clone https://fossil-scm.org

When the FILENAME parameter is not given, it produces a “Fossil” subdirectory containing the contents of tip-of-trunk, with the directory name coming from the project configuration under Admin. The SQLite repo file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

[Carlo Miron]

Post by Warren Young
$ fossil clone https://fossil-scm.org
When the FILENAME parameter is not given, it produces a “Fossil” subdirectory containing the contents of tip-of-trunk, with the directory name coming from the project configuration under Admin. The SQLite repo file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

Or maybe `.fossil`, as in Kyle's golang contribution?
https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330

㎝

[Offray Vladimir Luna Cárdenas]

Post by Carlo Miron

Post by Warren Young
$ fossil clone https://fossil-scm.org
When the FILENAME parameter is not given, it produces a “Fossil” subdirectory containing the contents of tip-of-trunk, with the directory name coming from the project configuration under Admin. The SQLite repo file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

Or maybe `.fossil`, as in Kyle's golang contribution?
https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330
㎝

I would go also with ".fossil" as default extension (is the one I use
right now).

Cheers,

Offray

[Warren Young]

Post by Offray Vladimir Luna Cárdenas

Post by Carlo Miron

Post by Warren Young
When the FILENAME parameter is not given, it produces a “Fossil” subdirectory containing the contents of tip-of-trunk, with the directory name coming from the project configuration under Admin. The SQLite repo file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

Or maybe `.fossil`, as in Kyle's golang contribution?
https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330

I would go also with ".fossil" as default extension (is the one I use
right now).

.fossil as an extension for clones is one thing: it is not simply a convention due to “fossil server /DIRECTORY” scanning behavior.

There is no reason the hidden file need follow this convention. In fact, it would be harmful:

$ fossil server /path/to/clone-and-open/checkout/directory

This would find .fossil and require that you pass an empty name in the clone URL. Confusing and maybe not even possible, since http://localhost:8080 and http://localhost:8080/ are normally treated as equivalent.

Furthermore, we already have .fsl* at the root of a checkout. Shouldn’t we follow the existing convention?

[Offray Vladimir Luna Cárdenas]

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas

Post by Carlo Miron

Post by Warren Young
When the FILENAME parameter is not given, it produces a “Fossil” subdirectory containing the contents of tip-of-trunk, with the directory name coming from the project configuration under Admin. The SQLite repo file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

Or maybe `.fossil`, as in Kyle's golang contribution?
https://go.googlesource.com/go/+/master/src/cmd/go/internal/get/vcs.go#330

I would go also with ".fossil" as default extension (is the one I use
right now).

.fossil as an extension for clones is one thing: it is not simply a convention due to “fossil server /DIRECTORY” scanning behavior.
$ fossil server /path/to/clone-and-open/checkout/directory
This would find .fossil and require that you pass an empty name in the clone URL. Confusing and maybe not even possible, since http://localhost:8080 and http://localhost:8080/ are normally treated as equivalent.
Furthermore, we already have .fsl* at the root of a checkout. Shouldn’t we follow the existing convention?

OK. I didn't understand this totally. I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

Cheers,

Offray

[Warren Young]

Post by Offray Vladimir Luna Cárdenas
I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

If you say

$ fossil clone https://fossil-scm.org fossil

You get a repository file called “fossil”, not “fossil.fossil”.

In my clone-and-open scheme, leaving off the final parameter above would give you a directory called “Fossil”, since I propose that we reuse the /zip and /tarball option from Admin > Configuration. Since Fossil’s own repository leaves that option unset, it uses the project name, which is capital-F “Fossil”.

The argument in this sub-thread, then, is what to call the actual repository file. I’m not wedded to .fslrepo, but it does follow established conventions nicely. .fslclone could also work, for example, though it would break the 8.3 restriction that Fossil once upon a time held itself to for such critical file names, since the equivalent on Windows would presumably be _fslclone.

[Offray Vladimir Luna Cárdenas]

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas
I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

If you say
$ fossil clone https://fossil-scm.org fossil
You get a repository file called “fossil”, not “fossil.fossil”.

No. I was referring to the later case (fossil.fossil)

Post by Warren Young
In my clone-and-open scheme, leaving off the final parameter above would give you a directory called “Fossil”, since I propose that we reuse the /zip and /tarball option from Admin > Configuration. Since Fossil’s own repository leaves that option unset, it uses the project name, which is capital-F “Fossil”.
The argument in this sub-thread, then, is what to call the actual repository file. I’m not wedded to .fslrepo, but it does follow established conventions nicely. .fslclone could also work, for example, though it would break the 8.3 restriction that Fossil once upon a time held itself to for such critical file names, since the equivalent on Windows would presumably be _fslclone.

Well my argument is related with how I setup the web server to serve
files ended in ".fossil", but I can just add more extensions as the
community decides.

Cheers,

Offray

[Warren Young]

Post by Offray Vladimir Luna Cárdenas

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas
I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

If you say
$ fossil clone https://fossil-scm.org fossil
You get a repository file called “fossil”, not “fossil.fossil”.

No. I was referring to the later case (fossil.fossil)

If you’re simply arguing that .fossil should be appended if a clone file name is given but no extension is given, that’s a separate topic from anything I’ve brought up. I’m ambivalent about the idea: I’m fine with the current behavior and I wouldn’t be upset if it changed.

Post by Offray Vladimir Luna Cárdenas

Post by Warren Young
In my clone-and-open scheme, leaving off the final parameter above would give you a directory called “Fossil”

Well my argument is related with how I setup the web server to serve
files ended in ".fossil", but I can just add more extensions as the
community decides.

I don’t see that clone-and-open impacts that either way. This feature would be used primarily by people who want to use someone else’s repository. If they re-serve it at all, it’ll probably be via a bare “fossil server” command, not pointing to a directory of fossils at all or using a front-end proxy layer.

I’m targeting the GitHub use case here: someone publishes a project and people want to just copy the repo contents down into a local directory to mess with, in the fewest steps possible. Git allows you to do this in 2 steps: clone & cd. Fossil currently requires 5, as I showed up-thread. That’s a problem.

[Warren Young]

Post by Warren Young
Git allows you to do this in 2 steps: clone & cd. Fossil currently requires 5, as I showed up-thread.

4 steps. The fifth step in the post starting this thread is part of a separate thought.

[Offray Vladimir Luna Cárdenas]

OK. My mistake. I misunderstood the post.

Cheers,

Offray

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas
I thought that was the extension
the shallow cloned repository would get if no extension name was specified.

If you say
$ fossil clone https://fossil-scm.org fossil
You get a repository file called “fossil”, not “fossil.fossil”.

No. I was referring to the later case (fossil.fossil)

If you’re simply arguing that .fossil should be appended if a clone file name is given but no extension is given, that’s a separate topic from anything I’ve brought up. I’m ambivalent about the idea: I’m fine with the current behavior and I wouldn’t be upset if it changed.

Post by Offray Vladimir Luna Cárdenas

Post by Warren Young
In my clone-and-open scheme, leaving off the final parameter above would give you a directory called “Fossil”

Well my argument is related with how I setup the web server to serve
files ended in ".fossil", but I can just add more extensions as the
community decides.

I don’t see that clone-and-open impacts that either way. This feature would be used primarily by people who want to use someone else’s repository. If they re-serve it at all, it’ll probably be via a bare “fossil server” command, not pointing to a directory of fossils at all or using a front-end proxy layer.
I’m targeting the GitHub use case here: someone publishes a project and people want to just copy the repo contents down into a local directory to mess with, in the fewest steps possible. Git allows you to do this in 2 steps: clone & cd. Fossil currently requires 5, as I showed up-thread. That’s a problem.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Warren Young]

Post by Warren Young
https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

Shallow clones bear some thinking, too.

Let us posit that “fossil clone” takes a -shallow option with no argument, telling it to fetch only the artifacts for the files at the tip-of-trunk. A -shallow clone should also pull non-closed tickets and wiki articles where the latest checkin is not empty.

To allow shallow clones of a different branch than trunk, “fossil clone” could take a -branch option. If you then say “fossil up trunk” from the checkout of such a clone, it would fetch all artifacts checked in on the trunk since clone time.

More broadly, “fossil update” of a shallow clone never pulls history past the clone date unless you specify an older date or checkin ID with the VERSION argument.

Then let us add -limit which takes the same VERSION argument as fossil update, which limits the depth of the history:

$ fossil clone -limit 2017-11-01 https://fossil-scm.org
$ fossil clone -limit abcde12345 https://fossil-scm.org
$ fossil clone -limit release https://fossil-scm.org

(Here you see me using the new clone-and-open behavior we will shortly be getting. Ehehm. ;) )

The last is interesting: it means “give me the latest tagged release plus all changes made since then.”

I’d like to see a small expansion of VERSION:

$ fossil clone -limit "30 days" https://fossil-scm.org

It needs a new syntax because you can’t just take a bare integer as a day count, since that could be ambiguous with checkin IDs. Simple suffixes like “30d” are also ambiguous, so if we require the space, then it breaks the ambiguity. It lets us add other multipliers, too, like “1 year”. All of this should be easy to do with SQLite date arithmetic.

I say it should modify the meaning of VERSION because it has applicability outside of shallow clones. “fossil update ’30 days’” means “check out the version closest to 30 days ago.” It could even take an ignored “ ago” suffix purely for readability, such as in scripts. This might make starting a bisect a bit easier.

If multiple -limit arguments are given, Fossil will take the oldest one as the true limit, so you can use it to list all the tags and branches that must be present in the clone; if the oldest listed item is a branch, you get the tip of that branch and everything newer than it. This would be useful in automated system deployment scenarios, where a script must specify the requirements for the checkout without knowing in advance which of the -limit values are oldest at any given point in time. (Puppet, Chef, Ansible…)

My current sense is that -shallow and -narrow should interact with AND logic. This:

$ fossil clone -limit release -narrow src https://fossil-scm.org

should result in only a src subdirectory which won’t build because it’s missing Makefile.in, configure, auto.def, and autosetup/ at least. If the user wanted a buildable “release” clone, he should have left off the -narrow option; else, why allow these options to interact at all?

[Warren Young]

I’ve prototyped this as a simple shell script:



#!/bin/sh -e
url=$1
shift

tmprepo=`mktemp .fslrepo-XXXXXXXXXX`
rm $tmprepo
fossil clone "$url" $tmprepo

name=`fossil sql -R "$tmprepo" \
"select value from config where name='short-project-name' \
or name='project-name' and value != '' limit 1"`
if [ -z "$name" ] ; then echo "No project name in $tmprepo!" ; exit 1 ; fi
if [ -d "$name" ] ; then echo "Already checked out as $name!" ; exit 1 ; fi
if [ -e "$name" ] ; then echo "$name in the way; aborting!" ; exit 1 ; fi

mkdir "$name"
cd "$name"
mv ../"$tmprepo" .fslrepo
fossil open .fslrepo "$@"



This is not useful as-is, since the whole point of this feature is that clone-and-open should be a single step with no other messing about by the user. What it proves, however, is that Fossil has everything needed to do this today. The existing pieces just need to be rearranged to allow it.

[b***@safe-mail.net]

In light of the new wiki article:

https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

I suggest not getting too carried away with adding features after
features. Most of the stuff here seems good, but everything under
"Support For Multiple VCS Formats" seems unnecessary.

Fossil should only work with Fossil's native format, and have
import/export tools do the rest. A repository with "a mixture of
artifacts in various formats" is asking for trouble. No other program
will be able to read such a repository anyway, so what is the point?

Why add more complexity and bloat to the Fossil core?

[Warren Young]

Post by b***@safe-mail.net
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.

[b***@safe-mail.net]

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

Post by Warren Young

Post by b***@safe-mail.net
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.

Post by Warren Young
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.

Post by Warren Young
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.

Post by Warren Young
Also valuable is that developer tool support generally goes git > hg

Post by b***@safe-mail.net
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.

Post by Warren Young
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.

[Warren Young]

Post by b***@safe-mail.net
On Mon, 20 Nov 2017 17:44:49 -0700

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

Post by b***@safe-mail.net
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.

Post by b***@safe-mail.net
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.

Post by b***@safe-mail.net

Post by Warren Young
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.

Post by b***@safe-mail.net
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.

Post by b***@safe-mail.net
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.

Post by b***@safe-mail.net
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 base the last time I checked, and it not only needs to build 10 year old systems, but many of those are *embedded* and not served by any of the Big Four C compilers. (GCC, VC++, Clang, and Intel.)

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! This particular C compiler only compiles while/do correctly, and then only on alternate Monday mornings when the mad god Murphy is too drunk to get out of bed and meddle.

[Zoltán Kócsi]

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

Post by Warren Young
[...]
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

[Warren Young]

Post by Zoltán Kócsi
On Tue, 21 Nov 2017 16:42:56 -0700

Post by Warren Young
[...]
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.

[Zoltán Kócsi]

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

Post by Warren Young
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

[b***@safe-mail.net]

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

Post by Warren Young

Post by b***@safe-mail.net
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.

Post by Warren Young
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.

Post by Warren Young
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.

Post by Warren Young
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?

Post by Warren Young

Post by b***@safe-mail.net
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.

Post by Warren Young
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.

Post by Warren Young

Post by b***@safe-mail.net
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.

Post by Warren Young

Post by b***@safe-mail.net
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.
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.

Post by Warren Young
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.

Post by Warren Young
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).

Post by Warren Young
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 base the last time I
checked, and it not only needs to build 10 year old systems, but many
of those are *embedded* and not served by any of the Big Four C
compilers. (GCC, VC++, Clang, and Intel.)
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! This particular C compiler only
compiles while/do correctly, and then only on alternate Monday
mornings when the mad god Murphy is too drunk to get out of bed and
meddle.

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? Nobody in their right mind would even
consider using Git, Subversion, Mercurial, or even Bazaar on those
severely limited systems.

As for that particular C compiler you are using, it is broken. So is
Microsoft's older Visual C compilers. You can use other compilers to
compile Fossil and still get reasonable results. I use MinGW-w64/MSYS2
to compile on Windows, which works very well. No need to be stuck with a
medieval compiler which can't even support the most basic of C99 stuff
since there is enough competition there even on Windows, that Microsoft
had to support C99/C11 eventuallly.

There is no need for Fossil or SQLite to comply with broken or heavily
out-of-date compilers when Fossil/SQLite won't even run on such
platforms.

BTW, OpenWatcom supports many C99 features and can compile for 16-bit
Windows, so perhaps 16-bit Fossil is in order.

[Javier Guerra Giraldez]

Post by b***@safe-mail.net
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.

[b***@safe-mail.net]

On Wed, 22 Nov 2017 17:30:10 +0000

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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?

[bch]

Post by b***@safe-mail.net
On Wed, 22 Nov 2017 17:30:10 +0000

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[bch]

Post by b***@safe-mail.net
On Wed, 22 Nov 2017 17:30:10 +0000

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez
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.

Post by b***@safe-mail.net
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Javier Guerra Giraldez]

Post by b***@safe-mail.net
On Wed, 22 Nov 2017 17:30:10 +0000

Post by Javier Guerra Giraldez
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.

Post by b***@safe-mail.net

Post by Javier Guerra Giraldez
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.

Post by b***@safe-mail.net
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

[b***@safe-mail.net]

On Wed, 22 Nov 2017 23:43:07 +0000

Post by Javier Guerra Giraldez
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

Post by Javier Guerra Giraldez
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.

Post by Javier Guerra Giraldez

Post by b***@safe-mail.net
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.

[Warren Young]

Post by Zoltán Kócsi
On Tue, 21 Nov 2017 16:42:56 -0700

Post by Warren Young

Post by b***@safe-mail.net
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.

Post by Zoltán Kócsi

Post by Warren Young
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.

Post by Zoltán Kócsi
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.

Post by Zoltán Kócsi

Post by Warren Young
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.

Post by Zoltán Kócsi
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%.

Post by Zoltán Kócsi

Post by Warren Young
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 level. They’re both DVCSes, and that’s about the extent of the similarity. How then can you know why one is faster than the other?

Post by Zoltán Kócsi
Nobody in their right mind would even consider Fossil (with its
in-built web server, wiki, and bugtracker) to run on such a system

There’s a wide rainbow between my 4 kWord C compiler and modern GCC.

It wasn’t that long ago that I worked out a plan, here on the mailing list, for a way to get a good portion of Fossil onto a PDP-11. I didn’t get any responses that told me why it was impossible.

I suspect you have too narrow a view of what being in one’s right mind is. It takes all kinds of crazy to make up today’s F/OSS world.

"Here's to the crazy ones, the misfits, the rebels, the
troublemakers, the round pegs in the square holes…
the ones who see things differently — they're not fond
of rules… You can quote them, disagree with them,
glorify or vilify them, but the only thing you can't do
is ignore them because they change things… they push
the human race forward, and while some may see them as
the crazy ones, we see genius, because the ones who are
crazy enough to think that they can change the world,
are the ones who do.”

— Steve Jobs

Post by Zoltán Kócsi
As for that particular C compiler you are using, it is broken.

Therefore…what? No good work can be done with such compilers? The platforms they support must be relegated to the dustbin of history?

Would you write off the entirety of the retrocomputing and retrogaming movements plus a good chunk of the embedded space just to defend your idea of what a “good” C compiler must be?

I’m all for standards and progress, but I also recognize that we cannot always drag elements of the past up to current standards, and that there is value in past systems and purposely limited modern systems.

Much of the problems we’re having with IoT these days comes from trying to put a 32-bit processor running a multitasking GCC and Linux based OS into lightbulbs.

Post by Zoltán Kócsi
There is no need for Fossil or SQLite to comply with broken or heavily
out-of-date compilers when Fossil/SQLite won't even run on such
platforms.

You’re focusing on my one extreme example and ignoring the rainbow between that and your apparent conception of minimal acceptable platform.

I expect I could get SQLite and Fossil to run on a PIC32, for example. The current version of Microchip’s XC32 compiler for that chip family only supports C89 and some C99 features. It also supports up to C++03, which means it might implicitly understand some C11 as well, but certainly not all of it.

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.

Infrastructure software should live by different rules than user-facing software. 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.

Post by Zoltán Kócsi
BTW, OpenWatcom supports many C99 features and can compile for 16-bit
Windows, so perhaps 16-bit Fossil is in order.

I think Microsoft’s unmcommon success at maintaining backwards compatibility makes 16-bit Windows an uninteresting platform from a retrocomputing standpoint.

More interesting are platforms like the PDP-11, SNES, etc., which require simulators/emulators to run software for those machines on modern hardware. Programmers wanting to produce new software for those machines must either use compilers of the day or retarget current tools for them, often dropping features along the way to squeeze into the old footprint.

[Zoltán Kócsi]

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

Post by Warren Young
[...]
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

[b***@safe-mail.net]

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

Post by Warren Young
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.
$ fossil ci
is not at all the same thing as
$ git commit
$ 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.

Post by Warren Young
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.

Post by Warren Young
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.

Post by Warren Young

Post by b***@safe-mail.net
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.
$ 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
$ 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 -

Post by Warren Young
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.

Post by Warren Young
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.

Post by Warren Young
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
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 both DVCSes, and that’s about the extent of the
similarity. How then can you know why one is faster than the other?

It may be easier to implement Git in an SQLite database for the sake of
comparison. Your point is valid especially with the rise of high-speed
SSDs (NVMe and what not).

Post by Warren Young
There’s a wide rainbow between my 4 kWord C compiler and modern GCC.
It wasn’t that long ago that I worked out a plan, here on the mailing
list, for a way to get a good portion of Fossil onto a PDP-11. I
didn’t get any responses that told me why it was impossible.
I suspect you have too narrow a view of what being in one’s right
mind is. It takes all kinds of crazy to make up today’s F/OSS world.

Indeed. Crazy = not in the right mind. Nothing wrong with being a
little crazy, considering the sort of junky people I've met in my
lifetime. But it is important to be realistic, and Fossil/SQLite should
not be coded just because a small minority will use it in corner cases
like this.

Post by Warren Young

Post by b***@safe-mail.net
As for that particular C compiler you are using, it is broken.

Therefore…what? No good work can be done with such compilers? The
platforms they support must be relegated to the dustbin of history?
Would you write off the entirety of the retrocomputing and
retrogaming movements plus a good chunk of the embedded space just to
defend your idea of what a “good” C compiler must be?

Perhaps I worded it poorly. What I meant was, is that compiler is no
good for building modern applications like Fossil.

A better example: if you were trying to screw something using a hammer,
would you like the manufacturer to make screws that can be installed
using a hammer just for your corner case, or would it be better just to
use the right tools for the job?

Post by Warren Young
I’m all for standards and progress, but I also recognize that we
cannot always drag elements of the past up to current standards, and
that there is value in past systems and purposely limited modern
systems.

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

Post by Warren Young
Much of the problems we’re having with IoT these days comes from
trying to put a 32-bit processor running a multitasking GCC and Linux
based OS into lightbulbs.

Actually the real problem with IoT is that people think they need
32-bit internet-connected light bulbs to begin with, and companies
making shoddy internet-connected devices are selling these "smart"
gadgets as a must-have tool. Some are quite pointless too, like Google
Home for example. Or that wi-fi connected juicer that cost $600.

Post by Warren Young
I expect I could get SQLite and Fossil to run on a PIC32, for
example. The current version of Microchip’s XC32 compiler for that
chip family only supports C89 and some C99 features. It also
supports up to C++03, which means it might implicitly understand some
C11 as well, but certainly not all of it.

I don't think at this stage a lot of the C11 standard is necessary for
Fossil's codebase to become a bit cleaner and more, well, standard.
Just some of the features I mentioned would make things a lot easier to
maintain and provide optimisation opportunities for compilers.

Post by Warren Young
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.

Post by Warren Young
Infrastructure software should live by different rules than
user-facing software. 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. It is just a C
language standard, not an API standard or minimum OS/system requirement.

Post by Warren Young
More interesting are platforms like the PDP-11, SNES, etc., which
require simulators/emulators to run software for those machines on
modern hardware. Programmers wanting to produce new software for
those machines must either use compilers of the day or retarget
current tools for them, often dropping features along the way to
squeeze into the old footprint.

This is all interesting from an academic perspective at least. 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.

[Warren Young]

Post by b***@safe-mail.net
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. :)

Post by b***@safe-mail.net
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.

Post by b***@safe-mail.net
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?

Post by b***@safe-mail.net
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?

Post by b***@safe-mail.net
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?

Post by b***@safe-mail.net

Post by Warren Young
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.

Post by b***@safe-mail.net

Post by Warren Young
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.”

Post by b***@safe-mail.net
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.

[b***@safe-mail.net]

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

Post by Warren Young

Post by b***@safe-mail.net
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. ;)

Post by Warren Young
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.

Post by Warren Young
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.

Post by Warren Young
https://en.wikipedia.org/wiki/Intel_Paragon
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.

Post by Warren Young
[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?

Post by Warren Young
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?

Post by Warren Young
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.

Touche, to some extent. Though the point is that if you want to get things to work on old architectures, prepare to do some work.

Post by Warren Young

Post by b***@safe-mail.net
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.”

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.

Post by Warren Young

Post by b***@safe-mail.net
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.

I think his point was that it got the job done. It is possible to contrast Word 6.0 for Windows with modern Word. I would be OK with Word 6.0 as I wouldn't need much more than what Word 6.0 provided in the first place.

Post by Warren Young
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.

Alas, the situation is unlikely to get better.

[Mike Burns]

Post by b***@safe-mail.net
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?

[Joseph R. Justice]

On Nov 28, 2017 11:08 AM, "Mike Burns" <***@afoundria.com> wrote:

As much as I agree, software in general has moved on. You won't get

Post by b***@safe-mail.net
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

[Warren Young]

Post by b***@safe-mail.net
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.

[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

[Warren Young]

Post by Zoltán Kócsi
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.

[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

Post by Warren Young

Post by Zoltán Kócsi
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

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

Post by Warren Young

Post by Zoltán Kócsi
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.

Post by Warren Young
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.

Post by Warren Young
Thus I cheerlead.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Warren Young]

Post by Offray Vladimir Luna Cárdenas
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?

[Offray Vladimir Luna Cárdenas]

Post by Warren Young

Post by Offray Vladimir Luna Cárdenas
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

[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

[Offray Vladimir Luna Cárdenas]

Hi Dave,

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

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.

Post by David Mason
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.

Post by David Mason
Thanks for fossil!

Yes. Thanks a lot!

Offray

[Thomas]

Post by Offray Vladimir Luna Cárdenas

Post by David Mason
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"?

[Thomas]

Post by Thomas
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"?

[Richard Hipp]

Post by Offray Vladimir Luna Cárdenas
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.

[Offray Vladimir Luna Cárdenas]

Post by Richard Hipp

Post by Offray Vladimir Luna Cárdenas
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

[Gour]

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

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

Go for it!

Post by Richard Hipp
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

--

[j. van den hoff]

Post by Richard Hipp

Post by Offray Vladimir Luna Cárdenas
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

[Gour]

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

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

I forgot to mention that maybe it's worth to explore support for Pijul
(https://pijul.org/) which might becomne big in the future having solved Darcs'
historical performance-related problems.


Sincerely,
Gour

[b***@safe-mail.net]

One of the #ifdef guards in src/utf8.c can be moved up since the
fossil_utf8_to_console() function is only ever called on WIN32
platforms anyway.

BTW, many guards are "#if defined(_WIN32)" rather than "#ifdef _WIN32"
but I'm not sure what is preferred here.


Index: src/utf8.c
==================================================================
--- src/utf8.c
+++ src/utf8.c
@@ -305,16 +305,16 @@
** Display UTF-8 on the console. Return the number of
** Characters written. If stdout or stderr is redirected
** to a file, -1 is returned and nothing is written
** to the console.
*/
+#ifdef _WIN32
int fossil_utf8_to_console(
const char *zUtf8,
int nByte,
int toStdErr
){
-#ifdef _WIN32
int nChar, written = 0;
wchar_t *zUnicode; /* Unicode version of zUtf8 */
DWORD dummy;
Blob blob;

@@ -352,9 +352,7 @@
zUnicode + written, size, &dummy, 0);
written += size;
}
fossil_free(zUnicode);
return nChar;
-#else
- return -1; /* No-op on unix */
-#endif
}
+#endif

[Ron W]

Date: Mon, 20 Nov 2017 13:33:11 -0700
Subject: [fossil-users] Fossil-NG ideas
$ fossil clone https://fossil-scm.org
When the FILENAME parameter is not given, it produces a “Fossil”
subdirectory containing the contents of tip-of-trunk, with the directory
name coming from the project configuration under Admin. The SQLite repo
file is stored inside the subdirectory in a hidden file; I propose .fslrepo.

While I like the idea of a "smart default" for the file name, I'd rather
have an "--open" (or "-o") option to trigger the automatic "fossil open".

1. If the user actually wants to specify the name, the option would be
needed, anyway.

2. By not requiring the option, it would be hiding one of Fossil's
advantages over git and Hg: Multiple working copies without the overhead of
multiple repository copies. (Granted, more likely SVN users migrating to
Fossil will appreciate this, but I know some former git and Hg users that
quickly learned to appreciate this.)

3. Adopting features from git is good, but let's not make Fossil too much
like git.

[Warren Young]

While I like the idea of a "smart default" for the file name, I'd rather have an "--open" (or "-o") option to trigger the automatic "fossil open”.

So…you want to remain more difficult to use than Git in this regard?

That’s not very Fossil.

(Yes, I just adjectived your noun. Deal with it.)

1. If the user actually wants to specify the name, the option would be needed, anyway.

No, they’d pass the FILENAME argument to “fossil clone,” just as you do today.

This does open a new issue, however. What does this mean:

$ fossil clone https://fossil-scm.org/ fsl

Do you:

a) get a fsl subdirectory containing the contents of the Fossil trunk checkout, as Git would do; or

b) get a fsl.fossil file, as someone up-thread apparently wants. That is, assume the FILENAME argument is still a repository file name, and that if .fossil is not given as an extension, add it? Or

c) get a fsl file, as Fossil 2.4 and all prior versions do?

2. By not requiring the option, it would be hiding one of Fossil's advantages over git and Hg: Multiple working copies without the overhead of multiple repository copies.

Easily handled via either:

$ mkdir ../x ; cd ../x ; fossil open ../y/.fslrepo branch-x
$ mkdir ../x ; cd ../x ; fossil open ../y branch-x

In the second case, it sees that you’ve given it a directory name and that it contains a .fslrepo repository file.

3. Adopting features from git is good, but let's not make Fossil too much like git.

Where it costs us nothing but development time and makes Fossil easier to use, let’s steal as much as possible. :)

[Ron W]

Date: Tue, 21 Nov 2017 16:08:20 -0500
The overhead for a small batch of commits non-zero but it is
manageable. A full clone, on the other hand, is too expensive. To
give Fossil the ability to service clone requests from git or hg
clients, it would be necessary to implement some kind of cache wherein
all of the artifacts have been pre-translated. That means that the
storage space requirements on the server would be multiplied by 2 or 3
(depending on whether your wanted to service just git or just hg or
both).

I assumed a full clone would be far too much. Thus why I was thinking that
non-Fossil VCS clients would be served via shadow repositories, despite
doubling (or more) the repository storage needs.

If a project were so big that the storage requirements became an issue,
then maybe make the shadow repositories be shallow and/or narrow.

(If I'm correctly understanding how git implements branches, it would be
possible to keep the git shadow shallow by periodically deleting old branch
labels/tags (which would allow the referenced commits to be garbage
collected (if not otherwise referenced by other means).)

[Joerg Sonnenberger]

Post by Warren Young
https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

There are two central design flaws in Fossil that affect larger
repositories and those are the repos that primarily benefit from
narrow/shallow clones. Properly addressing them is kind of a requirement
for either.

(1) The need to parse all artifacts on clone. Artificates should be
strongly typed, i.e. the system should at the very least distinguish
fully between "content" blobs and "meta data" blobs. Only the latter
have and should be parsed. This has a number of important implications,
but the easiest is that the number of artificates a rebuild or even just
a sync has to look at goes down by a factor of 2 at the very least. For
something like NetBSD src or pkgsrc, more like a factor of 10 (number of
blobs in total / number of commits, i.e. the average commit touches 10
files).

(2) Store true differential manifests. The current base line approach is
a somewhat crude approximation. It has the advantage that only two
manifests have to be parsed, but it makes the average manifest size much
larger for larger file trees. The same benefit could be obtained by
caching the file list, either every so often like the current base line
or on-demand. The difference is that the cached manifests are not
persistent meta data and don't have to be transfered.

I would also add a point (3) which is kind of related to (1):

(3) Make cluster manifests non-permanent artifacts. They can also
consume a good amount of space and their purpose could be served by a
Merkle tree as well. This is even more important when doing single
branch sync.

Joerg

[Richard Hipp]

Post by Joerg Sonnenberger
(1) The need to parse all artifacts on clone. Artificates should be
strongly typed, i.e. the system should at the very least distinguish
fully between "content" blobs and "meta data" blobs. Only the latter
have and should be parsed.

That is a good point. I had already planned to do this, though for
reasons other than what you propose. The fact that it reduces the
amount of parsing work on a rebuild is a bonus that I had not
previously thought of.

Post by Joerg Sonnenberger
(2) Store true differential manifests.

I'm thinking that Fossil-NG will probably do like Git and store
separate artifacts holding the content of each directory. (Git calls
these "Tree Objects"). I need to do more research, but I'm thinking
that for most check-ins, only one or two directory artifacts will
actually change, even if there are dozens or hundreds (or multiple
thousands as in NetBSD) of directory artifacts in a single check-out.

Post by Joerg Sonnenberger
(3) Make cluster manifests non-permanent artifacts.

I'm thinking of doing away with cluster artifacts entirely, and
managing sync in some other way.

[Joerg Sonnenberger]

Post by Richard Hipp

Post by Joerg Sonnenberger
(2) Store true differential manifests.

I'm thinking that Fossil-NG will probably do like Git and store
separate artifacts holding the content of each directory. (Git calls
these "Tree Objects"). I need to do more research, but I'm thinking
that for most check-ins, only one or two directory artifacts will
actually change, even if there are dozens or hundreds (or multiple
thousands as in NetBSD) of directory artifacts in a single check-out.

I'm not sure splitting it up on a per-directory level well help that
much. If you change a number of files in the same directory, they will
have the same prefix and compress well (even without doing any adhoc
prefix compression schemes). Changes are quite high that larger commits
will scatter around many directories, it's a common theme i.e. for API
changes in larger projects. The primary reason for storing tree objects
in something like git is the lack of better indexing structures, I would
say. In short, I would strongly distinguish between storage format and
working format, optimizing the former for compactness and building up
the latter when necessary.

Post by Richard Hipp

Post by Joerg Sonnenberger
(3) Make cluster manifests non-permanent artifacts.

I'm thinking of doing away with cluster artifacts entirely, and
managing sync in some other way.

Having something like cluster artifacts can be useful, i.e. consider the
typical case of one central main server and many clients pulling from
it. If the server builds a ephemeral cluster ever so often and the
clients remember the last cluster they got, they can just ask the server
"what changed since this point". If the implementation of the
communication process is actually asynchronous, adding a few round trips
is not that bad as long as the waiting time is minimized. If the first
request from the client starts with the last "cluster", the server can
answer with the commits added on top. Client can filter out those it
already has and request the new ones. While it gets the new commits, it
can start requesting the file changes. Non-commit artifacts would
essentially work like new leaf commits. A new "cluster" can either
reference an existing one as delta or be send from scratch. It would
still allow the server to do regular garbage collection.

Joerg

[Ron W]

Date: Wed, 22 Nov 2017 19:09:21 -0500
Subject: Re: [fossil-users] Fossil-NG Bloat?

Post by Offray Vladimir Luna Cárdenas
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).)

[Johan Kuuse]

Post by Ron W

Date: Wed, 22 Nov 2017 19:09:21 -0500
Subject: Re: [fossil-users] Fossil-NG Bloat?

Post by Offray Vladimir Luna Cárdenas
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

I agree on that we would give up Fossil semantics.

I use Git on a daily basis at work, while I personally prefer Fossil, which
I always use for my own projects.
I can only speak for myself, but in the situation given to Alice, I would
still be using Git with .git repositories, and Fossil with .fossil
repositories.
One single reason is my FAQ to my colleagues: "How do I do this in Git?"
As I am lucky enough to have helpful colleagues, I sometimes even run some
advanced Git commands at work.

Imagine the following situation:
I would like check the history of my suddenly currupted git repository at
work, so 'git log' doesn't work as expected.
If I would have been Alice, I would have typed 'fossil timeline' but as I
only see weird output, I ask my colleague for help.
I bet that even the most helpfule colleague would answer: "Oh, you don't
use Git. Sorry, then you are on your own."


To me it's similar to the UNIX philosophy - keep it simple.
One tool should be really good at one thing, IMHO.

Let's compare with the 'sox' audio tool, which tries really hard to handle
all kind of existing file formats for audio.
Audio file formats are specified, fixed, and do not change over time.
In that case I think it is legitimate for a software project to try to be
"as universal as possible".

But repository formats are not audio formats, they change over time.
And what if, in the secret Git or Hg developer camp, someone is trying to
do a similar universal VCS container (including Fossil),
just to discover that the Fossil repository format has changed?
Maybe I am pessimistic about this, but maintaining up-to-date/in-sync new
features/formats continously developed in the Git and Hg (and SVN?)
community seems not only a daunting task,
but also a way of trying to reinventing the wheel. Why spend time on
porting Git/Hg features instead of creating new Fossil features?

Another doubt I have after reading this thread:

Sometimes I literally browse my repository/global settings/checkout DB, may
it be of curiosity, forgotten username, or just to learn a bit more of the
Fossil DB structure.
I think the third-party http://sqlitebrowser.org/ is just great for this
task.
Will that option get lost with the new repository format?

Best Regards,
Johan

[Richard Hipp]

Post by Johan Kuuse
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.

[Johan Kuuse]

Post by Richard Hipp

Post by Johan Kuuse
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.

Post by Richard Hipp
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

[Richard Hipp]

Post by Johan Kuuse
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.

Post by Johan Kuuse
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.

[j. van den hoff]

Post by Richard Hipp

Post by Johan Kuuse
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?

Post by Richard Hipp

Post by Johan Kuuse
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.

[Ron W]

Date: Fri, 24 Nov 2017 05:55:51 -0500
Subject: Re: [fossil-users] Fossil-NG Bloat?

Post by Johan Kuuse
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?

[Richard Hipp]

Post by Ron W
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.

Post by Ron W
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?"

[Ron W]

Date: Tue, 21 Nov 2017 15:25:37 -0700
Subject: Re: [fossil-users] Fossil-NG ideas

Post by Ron W
While I like the idea of a "smart default" for the file name, I'd rather

have an "--open" (or "-o") option to trigger the automatic "fossil open”.
So
you want to remain more difficult to use than Git in this regard?

"fossil clone -o URL" would still be 1 step instead of 4 steps.

Post by Ron W
1. If the user actually wants to specify the name, the option would be

needed, anyway.
No, they’d pass the FILENAME argument to “fossil clone,” just as you do
today.

My understanding of your proposal was that leaving off the file name would
be the trigger for the git-like behavior.

So, I would expect "fossil clone URL filename" to do what it does today:
Create a repository file with the specified filename. No more.

$ fossil clone https://fossil-scm.org/ fsl
a) get a fsl subdirectory containing the contents of the Fossil trunk
checkout, as Git would do; or
b) get a fsl.fossil file, as someone up-thread apparently wants. That is,
assume the FILENAME argument is still a repository file name, and that if
.fossil is not given as an extension, add it? Or
c) get a fsl file, as Fossil 2.4 and all prior versions do?

I would expect c - do as Fossil does, today.

If I want the git-like behavior, I'd type "fossil clone -o
https://fossil-scm.org/ fsl"

I'm all for "stealing" features from other VCSs. Just don't change break
existing command syntax.

As for something I'd suggest stealing, how about enhancing "fossil
checkout" to accept an optional URL?

When I first started using Fossil, one of the things that was confusing to
me is that "svn checkout" maps to "fossil open", not "fossil checkout". It
is still something I help others migrating from SVN to Fossil. If Fossil
did not have a checkout command, it would have been less confusing. What I
tell those I help is "Just use 'fossil open' and pretend there is no
'fossil checkout'."

Anyway, "fossil checkout" could be made more like "svn checkout" merely by
extending the syntax to allow an optional URL.