Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 27, 2017, at 1:49 PM, Bob Friesenhahn  
wrote:
> 
> Any DVCS is going to cause a penalty when the goal is to check out a 
> particular version of the files from a remote server

…the first time.

After you’ve got a clone, operations are usually much faster with a DVCS than a 
remote non-distributed VCS.

> the whole repository normally needs to be duplicated first.

Which is why narrow and shallow cloning features can make the difference 
between “impractical” and “practical” when converting a sufficiently large 
repository from a traditional non-distributed VCS to a DVCS.  In effect, they 
roll back some of the features you get from a DVCS, making it more like a 
non-distributed VCS.

When the repo size is on the order of that of sqlite.org, however, narrow and 
shallow clones buy you little, and they cost you the inherent backup you get by 
distributing your entire repository everywhere.

My war story above about about my lost repository on Gna! was because it was 
hosted in Subversion, so I lost all project history between the last svnadmin 
backup I made and the working copies on my development machines.  That won’t 
happen now that that project is hosted on Fossil: every user of that software 
project holds the whole project history now.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Bob Friesenhahn]

On Wed, 27 Dec 2017, Simon Slavin wrote:


I understand that ZFS does this too, though I’ve never used ZFS.


ZFS currently clones on the filesystem level.  Filesystems are easy to 
create/delete and only consume the space required.  Once a filesystem 
has been cloned, then only modified file blocks take new storage 
space.


ZFS and some other storage-pools/filesystems optionally support 
de-duplication at the block level so copying a block can imply 
incrementing a reference count.  The application might do quite a lot 
of work copying the data (slow) but the underlying store can realize 
that the block matches other copies and not store a new copy. 
Inserting just one byte early in a changed file may foil 
de-duplication.


Filesystem tricks still do not solve the most common problem that the 
master repository is usually accessed over a network, and networks are 
usually slow.


Any DVCS is going to cause a penalty when the goal is to check out a 
particular version of the files from a remote server and the 
repository is large.  A hosted VCS like CVS/SVN would deliver just the 
desired versions of the files (as long as the server remains available 
and working) whereas with a DVCS, the whole repository normally needs 
to be duplicated first.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Peter Da Silva]

On 12/27/17, 2:23 PM, "sqlite-users on behalf of Simon Slavin" 
 wrote:
> Fair point.  Automatic de-duplication would be more beneficial.  And it 
> wouldn’t require extreme cleverness to be separately written into each 
> application.  APFS does not do automatic de-duplication.

We had Netapp filers at my last gig. It’s about the only thing I really miss 
from there, but they were *nice*. And automatic deduplication  was not the 
least of the reasons.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Simon Slavin]

On 27 Dec 2017, at 8:10pm, Warren Young  wrote:

> It is almost certainly the case that some of the files in x and y are 
> identical so that those files could be cloned from those in the other at the 
> filesystem level by making one of these OS-specific API calls, but it would 
> require a lot of bookkeeping on Fossil’s part to pull this off.  And at the 
> end of the day, you’d only be getting the feature on macOS 10.13+ boxes.

Fair point.  Automatic de-duplication would be more beneficial.  And it 
wouldn’t require extreme cleverness to be separately written into each 
application.  APFS does not do automatic de-duplication.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 27, 2017, at 11:14 AM, Simon Slavin  wrote:
> 
> On 27 Dec 2017, at 4:05pm, Warren Young  wrote:
> 
>> DVCSes...by their very nature...want to clone the entire history of the 
>> whole project to every machine, then make a second copy of the tip of each 
>> working branch
> 
> Apple recently moved to APFS, a file system which supports file and folder 
> cloning.  If you copy a file or folder it doesn’t duplicate the data, it just 
> creates a pointer that points to the existing copy.  However, if you then 
> change one of the copies (e.g. change one byte of a huge file) it makes a new 
> copy (of the affected sectors) at that point, so that only that one copy of 
> the file has changed.

In addition to da Silva’s point about needing to use the OS-specific API to do 
this,[1] we couldn’t easily use it in Fossil anyway, for multiple reasons:

1. One of the duplicates is in the repository clone, which is 
delta-compressed,[2] and thus is not in the exact same form as when checked 
out, so you’ll still have at least two near-duplicate copies.  Only a more 
primitive version control system like RCS, CVS, or *maybe* Subversion which 
really does keep pure duplicates hidden away could get you around this problem.

2. Even if delta compression were disabled on purpose for some files, the 
repository copy is stuck in Fossil’s SQLite database file.  It is not an 
independent file that the filesystem could track anyway.

3. In the Fossil model, checkouts are independent.  (And this is one of the 
best things about Fossil relative to Git.)  Although Fossil keeps track of 
which repositories you’ve got open on your system so that “fossil all” can 
work, it currently makes no logical or filesystem ties between these 
independent checkouts, which it would need to do to make use of these 
OS-specific file cloning APIs you talk about.  Example:

$ mkdir ../x ; cd ../x ; fossil open ~/museum/x.fossil trunk
$ mkdir ../y ; cd ../y ; fossil open ~/museum/x.fossil y-branch

It is almost certainly the case that some of the files in x and y are identical 
so that those files could be cloned from those in the other at the filesystem 
level by making one of these OS-specific API calls, but it would require a lot 
of bookkeeping on Fossil’s part to pull this off.  And at the end of the day, 
you’d only be getting the feature on macOS 10.13+ boxes.

Git isn’t much better on these points:

1. Git also uses delta compression in the repo.

2. Git’s “pile of files” repo format still keeps most repo data in “packfiles”, 
which are not loose independent copies of the checked-out files.

3. This is the only place where Git’s design helps, because its git-worktree 
feature is a cheesy hack compared to the way Fossil separates the checkout and 
repository clone.[3]  This design inherently keeps track of which repos are 
linked to which others, so the bookkeeping of figuring out which files to call 
clonefile(2) or similar on would be easier.  It’s a high cost to pay to save 
some disk space, though.


[1]: https://developer.apple.com/library/content/samplecode/APFSCloning/
[2]: 
https://fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki
[3]: 
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25686.html

> I understand that ZFS does this too, though I’ve never used ZFS.

I’ve used ZFS for years, so I can tell you that in almost every way, ZFS is 
greatly superior to APFS.  One of the few ways where APFS is superior is in 
this clonefile(2) syscall.  There is no equivalent under ZFS: cloning is done 
at the filesystem level, not per-file.

Apple’s model is traditional “applications,” and they want “File > Save As” to 
make copies where possible, rather than duplicate most of the bytes on disk.

ZFS’s model is snapshots and clones of entire filesystems.  A single file can 
then be modified and only the updated blocks are tracked separately from the 
blocks that all clones share, but I don’t believe you can simply tell the 
filesystem to clone a file under a new name, short of link(2).

And no, we can’t just use link(2) for this, because the two names only refer to 
separate sets of block data on disk when the application makes a copy of the 
file, rather than rewriting the data in place.  So, if you edit a source file 
with a text editor that rewrites in place, all linked versions get changed, 
which is almost certainly not what you want when you’re using it to save space 
between independent VCS repository checkouts.  ZFS and APFS style cloning have 
different semantics, more appropriate to this proposed usage.

Linux got something similar in kernel 4.5, ioctl(FIDEDUPERANGE),[4] which 
incidentally shows the problem we face here: without a standard, applications 
have to be coded for each OS specifically.  I don’t know if ZFS-on-Linux 
understands this ioctl yet; last I heard, the answer was, “no,” but that might 
have changed.  (This ioctl was 

Re: [sqlite] Move to Github!!?

[Simon Slavin]

On 27 Dec 2017, at 6:49pm, Peter Da Silva  wrote:

> On 12/27/17, 12:14 PM, "sqlite-users on behalf of Simon Slavin" 
>  slav...@bigfraud.org> wrote:
> 
>> Would running git/fossil on a filesystem like that solve the problem ?
> 
> You would have to modify it to use the new APIs for things like copying files.

If it uses the "cp" utility it’ll happen automatically.

It is silly that POSIX/unix/linux/macOS doesn’t have an "fcopy" API call that 
"cp" calls.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Peter Da Silva]

On 12/27/17, 12:14 PM, "sqlite-users on behalf of Simon Slavin" 
 wrote:
> Would running git/fossil on a filesystem like that solve the problem ?

You would have to modify it to use the new APIs for things like copying files.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Simon Slavin]

On 27 Dec 2017, at 4:05pm, Warren Young  wrote:

> Fossil has that problem, too.  Most DVCSes do, because by their very nature, 
> they want to clone the entire history of the whole project to every machine, 
> then make a second copy of the tip of each working branch you check out.  
> That’s a lot of I/O for a big, old, project.

Please allow for my ignorance of source-control systems here.

Apple recently moved to APFS, a file system which supports file and folder 
cloning.  If you copy a file or folder it doesn’t duplicate the data, it just 
creates a pointer that points to the existing copy.  However, if you then 
change one of the copies (e.g. change one byte of a huge file) it makes a new 
copy (of the affected sectors) at that point, so that only that one copy of the 
file has changed.

I understand that ZFS does this too, though I’ve never used ZFS.

Would running git/fossil on a filesystem like that solve the problem ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Igor Korot]

Hi,

On Wed, Dec 27, 2017 at 12:00 PM, Warren Young  wrote:
> On Dec 27, 2017, at 7:49 AM, Nelson, Erik - 2 
>  wrote:
>>
>>> Also when you're forced to use a third party ticket system, fossil i 
>>> missing one of its big advantages.
>>
>> I'm no Fossil expert, but it does seem to have a ticketing system.  Is there 
>> something in particular functionality missing?
>
> I think he’s saying that being forced to use a third-party ticketing system 
> is a problem in itself, and it means you lose out on some of the features you 
> get by integrating the bug tracker tightly with the VCS as Fossil and GitHub 
> do: cross-linking checkin comments and bug IDs, etc.
>
> Some people like running a separate bug tracker to get more features, but of 
> course you can do that with Fossil as well.
>
> Third-party bug trackers often have built-in ways to integrate with Git — 
> network effects again — whereas to integrate Random Bug Tracker III with 
> Fossil, you’d probably have to do a lot of local scripting.
>
> One thing about evaluating Fossil’s ticket tracker: it’s quite configurable.  
> Don’t judge it solely on how it ships out of the box.  It may be easy to 
> adjust it to fix any mismatches between your expectations and the default 
> configuration.

I'm curious - is there a way for a Git{Hub}/Fossil to set up a
synchronized ticketing system?
If I have a trac and my project is on Git{Hub} - how hard wll it be to
synchronize between a trac tickets and Git{Hub} PR?

Moreover - it looks like this should be pushed further and further
away, because there is so much in-needed stuff to implement

Thank you.

> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Simon Slavin]

On 27 Dec 2017, at 1:51pm, Fredrik Gustafsson  wrote:

> - What are our demands for a ticket system, would fossil or gitlab (for
>  example) suit us better?

Here’s something from experience.

You can have three types of ticket:

A) Internal tickets.  These are raised by employees of your company who 
understand your software, understand the ticketing system, and submit bugs only 
after they’ve done some forensic investigation to prove they are what they look 
like.

B) External tickets, submitted by employees of your own company who may not 
really understand your software, may not be tech-clever, and may not understand 
how to investigate a bug.  They are called 'the internal customer'.

C) External tickets, submitted by people who don’t work for your company.

If you have a ticketing system tied to your source depository, use it only for 
category (A) customers.  If you want one for (B) and (C) (and you may not) set 
up a different one, with a web-facing GUI, which has no internal details (e.g. 
source code filenames) in.

A customer of mine lost customer confidence because those customers got to 
learn too much about how their software worked, but not enough programming to 
see why things weren’t fixed the way they thought they should be fixed.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 27, 2017, at 7:49 AM, Nelson, Erik - 2  
wrote:
> 
>> Also when you're forced to use a third party ticket system, fossil i missing 
>> one of its big advantages.
> 
> I'm no Fossil expert, but it does seem to have a ticketing system.  Is there 
> something in particular functionality missing?

I think he’s saying that being forced to use a third-party ticketing system is 
a problem in itself, and it means you lose out on some of the features you get 
by integrating the bug tracker tightly with the VCS as Fossil and GitHub do: 
cross-linking checkin comments and bug IDs, etc.

Some people like running a separate bug tracker to get more features, but of 
course you can do that with Fossil as well.

Third-party bug trackers often have built-in ways to integrate with Git — 
network effects again — whereas to integrate Random Bug Tracker III with 
Fossil, you’d probably have to do a lot of local scripting.

One thing about evaluating Fossil’s ticket tracker: it’s quite configurable.  
Don’t judge it solely on how it ships out of the box.  It may be easy to adjust 
it to fix any mismatches between your expectations and the default 
configuration.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 27, 2017, at 3:23 AM, Rob Willett  wrote:
> 
> I know RCS is possibly older than the average reader on this mailing list, 
> but it works very well for us and the workflow 'just works’.

Fossil “just works” for me, too.

I’m curious why Subversion never appealed to you, being that it’s RCS-derived 
and offers things like atomic multi-file commits.

I find the day-to-day operation of Fossil is pretty much about the same as with 
Subversion, which also had an uncommonly clear command line interface for its 
day.

Given that svn didn’t attract you, though, I’m wondering if you’ll find fault 
with Fossil for some related reason.

> we didn't want to be tied into Github financially (small though it might be) 
> and technically.

Also consider security.  Lots and lots of people are trying to break into 
GitHub, and they occasionally succeed.

There are also some problems with GitHub’s security design that you might not 
be able to live with:

https://stackoverflow.com/a/8011897

While your new private Git/Fossil server probably won’t be as well-managed as 
GitHub [1], it’s a distributed risk, so you don’t face the same problem GitHub, 
Inc. does.  Even if they break into *my* repo, they probably won’t be able to 
use what they learned from that to break into *yours*.


[1]: According to Wikipedia, GitHub, Inc. currently has 723 employees, and 
*some* of those must be sysadmins and netsec types.  How many do you have?

> We have spent a month looking at how we use Git and we don't feel a 100% 
> happy with it

It’s easy to export from Git to Fossil. :)

https://fossil-scm.org/index.html/doc/trunk/www/inout.wiki

And yes, vice versa.

> 75M other people seem to think its OK

Much of Git’s popularity is due to network effects, rather than to its inherent 
virtues.  “Everyone” uses Git because everyone uses Git.

Git can be highly problematic, but you can Google for all of those problems and 
quickly find some kind of answer.  Most often the answer amounts to this, sadly:

   https://xkcd.com/1597/

> It's pretty easy to setup Git on a VPS

Whether it’s easier to set up Fossil or not depends on how you compare it.

If you use ssh access only, it’s equally easy as Git, since it’s pretty much 
the same process.

If you use plain HTTP access, Fossil is probably a whole lot easier, but then 
you’ve got unencrypted comms, which probably won’t work for you.

If you want to put Fossil behind HTTPS, it can be quite a lot of work:

   https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg22907.html

(Beware, that HOWTO dates from a time before Let’s Encrypt had built-in nginx 
integration.  Much of what it talks about no longer needs to be done by hand.)

On the other hand, setting up Fossil-over-HTTPS is probably still a lot easier 
than setting up something more nearly equivalent, such as Gitlab-over-HTTPS.

> The next issue we found was that large binary files can be problematic.

Fossil has that problem, too.  Most DVCSes do, because by their very nature, 
they want to clone the entire history of the whole project to every machine, 
then make a second copy of the tip of each working branch you check out.  
That’s a lot of I/O for a big, old, project.

When you need to have large binary files and only want one copy of just the 
working branch(es) on the developer machines, traditional VCSes are a better 
plan.

There are hybrid systems which end up not fully distributing the repositories 
in some way.

Git has some of thee hybrid modes, in fact, in its narrow and shallow clones.  
(Narrow = don’t clone the entire tree, only maybe a single subdirectory; 
shallow = don’t pull the entire history of all files.)

Fossil does not yet have narrow or shallow clone features.

> we have 20GB of video and pictures we've created over the last few months.

If these files don’t need to have version history, you could use Fossil’s 
unversioned file feature:

   https://fossil-scm.org/index.html/doc/trunk/www/unvers.wiki

That allows you to push a single copy to the remote repository.  Unversioned 
files are included in clones, but they are not checked out on individual 
developer machines by default.  You have to specifically pull files from the 
unversioned file store whenever you want them.

Otherwise, it’s probably better to store such files in a traditional VCS, like 
Subversion.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J Decker]

While this is really entirely derailed I'll add...
If monotone wasn't dead 6 years now I'd be using that...but it doesn't
support unicode filenames very well; and they haven't wanted to do updates.

I was really resistant to migrating to Git; actually almost any other
alternaitve of them.  Monotone, like fossil, was a single executable that
did everything all in one.  It also uses a sqlite database for storage, and
tracks things like renames, and has propagation between branches that works
better than git.  At the time I knew sqlite used fossil, and did search for
information on using it; but never actually found it, and decided it must
be a in-house tool that they didn't give for others to use.  ('sides fossil
was a com port driver from days long ago.. just to make searching for it
that much harder)

The choices got slim though... mercurial, SVN (at the time it still
littered the whole directory structure with .svn directories like CVS) and
was server based... and so very slow... and only used that for a short
time; mercurial was much more performant, and before github existed, was
the only alternative sourceforge supported that was decent.

I even used code.google.com for a while with mercurial, while github was
becoming a thing, until google closed that, and the only migration path was
from there to Github... I avoided migrating as long as possible hoping
someone would object and google could change their minds... they never did.
But, as time went on, and I dealt with lots of projects were moving to
github.  Bullet Physics, MS Net FX core, Mono, Go, NodeJS, Vulkan,
Libressl, Unreal, the list goes on... it's become unavoidable to have Git;
unless you live in a not-written-here world and don't care to contribute to
anyone else.

So, having had my arm twisted and choices narrowed to 1 (or 0), I've come
to appreciate the speed and utility of github.  I don't trust it for sole
storage though and have other backup repositories.  Given that there are a
lot of companies using github for private repositories and they are very
inexpensive (when compared with something like Perforce, which I dabbled in
a while, because Openwatcom)  I doubt they'll have to resort to adware.
(could happen) but it's been near a decade ( Development of the GitHub
platform began on 19 October 2007.[10]
[11]
[12]
 The
site was launched in April 2008 .) and it hasn't happened.  And it's still
quite fast ( Unlike sourceforge )
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Nelson, Erik - 2]

Fredrik Gustafsson Sent: Wednesday, December 27, 2017 8:52 AM

>Ask yourself if you want a system that is easy to use or easy to learn.

That feels like a false choice- why can't it be both easy to learn and easy to 
use?  That's a hallmark of good engineering.

>Also when you're forced to use a third party ticket system, fossil i missing 
>one of its big advantages.

I'm no Fossil expert, but it does seem to have a ticketing system.  Is there 
something in particular functionality missing?

Erik

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Fredrik Gustafsson]

Hi,
I'm a former git developer and have been lurking on this maillist (since
I work with sqlite3) and followed fossil (since I'm interested in scm).

On Wed, Dec 27, 2017 at 10:23:57AM +, Rob Willett wrote:
> the commands were exceptionally confusing. It appeared to us that most of
> the documentation seems self referential and we kept going round and round
> in circles trying to understand why something was written the way it was.
> Even though 75M people seem to use Git, it was a struggle to understand it.
> We except that it might be us, but we felt like we were walking through
> treacle.

The man files that comes with git requires quite a bit of basic
understanding of git before they start to make sense. However there's
plenty of other beginner places to look at which are superb. For example
the gitbook on the git homepage, I also use to recommend a youtube
lecture by Jessica Kerr.

> 
> The next issue we found was that large binary files can be problematic. We
> have started making Twitter video ads to promote our apps. In the interest
> of fairness and not to self advertise I won't promote them here :) However
> we have 20GB of video and pictures we've created over the last few months.
> It's amazing how much space (and time) can be taken up with this sort of
> thing. We found that by itself Git doesn't really like binary files that
> much and that you tend to need an extension to handle Large Binary Files.
> There also appears to be different extensions to handle this sort of stuff
> which is painful to work out which is the best system. It could also be that
> we simply haven't got the hang of Git.

This is a problem with most distributed version control systems. The
problem here is that when you do a clone, you get all the history of the
system and each change to a binary file, is a complete copy of that
file. Now git has ways around this, for example git lfs, shallow clones
and now latest, the filesystem solution from Microsoft. However, each of
these includes a step more to learn.

> 
> So we started looking again at Fossil and like what we saw. We have no
> emotional commitment to Git, we want an easy to use SCM that works with
> Emacs (I know, I know), and runs on Linux and Macs. Fossil looks like it
> might fit the bill. There's an Emacs mode so that box is ticked, there's a
> command line mode, so thats easy, the command set seems to be orthogonal
> which is important.

Ask yourself if you want a system that is easy to use or easy to learn.
If a scm is a daily tool that will be important in your workflow, I
would say that it can be worth to invest some learning time if the
system is easy to use once you've learned it.

What I've seen, fossil is a great system. I would love to use it, but it
has two deal breakers for me, there's no way to do a interactive rebase
and there's no good way of doing code reviews (the
gitlab/github/bitbucket style). Also when you're forced to use a third
party ticket system, fossil i missing one of its big advantages.

You should ask yourself:
- How do we want to do code review?
- What are our demands for a ticket system, would fossil or gitlab (for
  example) suit us better?
- Is a rebase workflow something we would benefit from?

All other questions, it seems like you're on top of already.

-- 
Fredrik Gustafsson

phone: +46 733-608274
e-mail: iv...@iveqy.com
website: http://www.iveqy.com
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Rob Willett]

Dear all,

I've enjoyed reading about the Github vs Fossil discussion. There's been 
some passionate and provocative statements :)


What its done for me is make me think again about how we manage our 
source code control which is always good. We very recently moved from 
our existing text based RCS system to a privately hosted Git system. I 
know RCS is possibly older than the average reader on this mailing list, 
but it works very well for us and the workflow 'just works'. Until 
recently we haven't needed anything more so why change.


RCS started showing its age as we have moved to more and more people 
working out of the office more and more, often with no internet access, 
and we became more distributed. So after an extensive checking of the 
various SCM systems out there, which lasted almost a whole hour, we 
decided to try out Git on a private server. Private servers are pretty 
cheap and we didn't want to pay Github. We were also acutely aware that 
business models change on a whim and we didn't want to be tied into 
Github financially (small though it might be) and technically.


We have spent a month looking at how we use Git and we don't feel a 100% 
happy with it, mind you 75M other people seem to think its OK, but this 
mailing list started us thinking about Fossil. This mailing list has 
always been a source of accurate (and sometimes passionate) information. 
It has rarely (never?) had much 'fluff' in it. (Fluff is a English 
phrase meaning ephemeral or lightweight). Whilst I may not agree with 
everything or even understand most of the SQL, the quality is very, very 
high and when people state something, its normally worth listening to. 
We tend to lurk rather than contribute as other people know SQLite far, 
far better than we do. If you have any Perl questions please ask :)


It's pretty easy to setup Git on a VPS, took an hour or so before we had 
it going and it started well. What we then found was that the 
documentation and the commands were exceptionally confusing. It appeared 
to us that most of the documentation seems self referential and we kept 
going round and round in circles trying to understand why something was 
written the way it was. Even though 75M people seem to use Git, it was a 
struggle to understand it. We except that it might be us, but we felt 
like we were walking through treacle.


The next issue we found was that large binary files can be problematic. 
We have started making Twitter video ads to promote our apps. In the 
interest of fairness and not to self advertise I won't promote them here 
:) However we have 20GB of video and pictures we've created over the 
last few months. It's amazing how much space (and time) can be taken up 
with this sort of thing. We found that by itself Git doesn't really like 
binary files that much and that you tend to need an extension to handle 
Large Binary Files. There also appears to be different extensions to 
handle this sort of stuff which is painful to work out which is the best 
system. It could also be that we simply haven't got the hang of Git.


So we started looking again at Fossil and like what we saw. We have no 
emotional commitment to Git, we want an easy to use SCM that works with 
Emacs (I know, I know), and runs on Linux and Macs. Fossil looks like it 
might fit the bill. There's an Emacs mode so that box is ticked, there's 
a command line mode, so thats easy, the command set seems to be 
orthogonal which is important.


The one area we struggled with is how we might handle large binary files 
(video files). These are made in Final Cut Pro X (FCPX), please don't 
get us started on the backup capability of FCPX,, Screenflow, an 
excellent video editing system that doesn't try to do what FCPX does, 
but does 'simple' videos very well and is fantastically quick to work 
with, Affinity Designer and Affinity Photo. None of these really produce 
XML files so are genuine binary files. It appears that Fossil seems to 
handle binary files 
(https://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) 
but we struggled to work out how these really work. We'd be very 
interested in peoples experiences here with Fossil with large binary 
files (300MB). It would be great to have a single repository where we 
can store text files, binary files and have these managed easily.


Am aware that this discussion might be better on the Fossil mailing 
list, but since there's so much information on here, we thought we'd ask 
this group first.


Thanks very much for reading,

Rob

On 26 Dec 2017, at 22:47, Jungle Boogie wrote:


On Tue 26 Dec 2017  3:08 PM, Damien Sykes wrote:

Hi,
This is a question I have asked myself many times (I.E. Git projects 
moving

to Fossil).
GitHub is well known and boasts over 74 million repositories, yet 
Fossil,
which both hosts and utilises one of the most well-known database 
systems in
the world, I doubt can count a thousand. Even the ChiselApp hosting 
platform
hosts a mere 360 public 

Re: [sqlite] Move to Github!!?

[Jungle Boogie]

On Tue 26 Dec 2017  2:09 PM, Warren Young wrote:
> On Dec 26, 2017, at 2:47 AM, J Decker  wrote:
> > 
> > doesn't require a fee unless they want to amke it private.
> 
> You’re speaking of today’s benevolent policies.
> 

Yes, I completely agree with everything you said. Nicely said! 

While freeBSD is on github, the code is still hosted on their systems
via svn. They don't really want to break away from this, because it
would be foolish to trust any third party company with your entire code
base.

Which makes me wonder...those super large companies that host code on
github, are they also internally keeping it under src control, either
git/fossil/svn?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Jungle Boogie]

On Tue 26 Dec 2017  3:08 PM, Damien Sykes wrote:
> Hi,
> This is a question I have asked myself many times (I.E. Git projects moving
> to Fossil).
> GitHub is well known and boasts over 74 million repositories, yet Fossil,
> which both hosts and utilises one of the most well-known database systems in
> the world, I doubt can count a thousand. Even the ChiselApp hosting platform
> hosts a mere 360 public repositories, Hydra hosts 11, WanderingHorse hosts
> 23, outside of which lie Fossil itself, the Fossil book, SQLite and friends
> (5 publicly accessible repositories in all), and TCL and friends (7
> repositories), making a total of 408. Add SQLite private repositories, and
> private repositories that I host, have access to or otherwise generally know
> exist, and I come up with an estimate of roughly 470 repositories. Of course
> this is not an accurate statistic since it may exclude more private
> repositories, and definitely excludes any local repositories (I for one have
> about a dozen Git repositories as Fossil repositories).

I understand that github's numbers are larger, but is that figure
including unique repos and forks, because of pull requests? For instance,
we already know of at least two sqlite repos on github from this mailing
list.

Some repos are junk and so are the user accounts. I.e. accounts made by
bots for whatever reasons. Some contain very little data. Some are from
very large companies, i.e. google/facebook/netflix/microsoft.

It's kinda funny that git is a decentralized repo but github is quite
centralized. 

> While I am making every attempt to try to persuade friends towards Fossil,
> they are also choosing Git. Looks to me like the only people who seem to use
> Fossil are those who are most associated with it, which is a real shame.

Yes, that's quite a good point, but I don't know how to turn that corner
and have it more mainstream.

> The only advantage I can see with GitHub is that it's the source code
> Twitter equivalent. Everybody's repository is in one place. As long as you
> know the username and repository name you know the full repository URL, and
> you don't have to worry about server administration. 

I'm not so concerned about the server admin aspect of fossil, but I do
understand if your twitter handle matches your github repo name, it can
make things easier, but this also goes to my statement above - it's
ironic that github is very large and for distributed.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 26, 2017, at 12:07 PM, Bob Friesenhahn  
wrote:
> 
> On Tue, 26 Dec 2017, J Decker wrote:
>>> Why aren't you moving all of your GitHub projects over to Fossil!
>>> 
>> Because Pull Requests, and a larger variety of tools to deal with Git
>> repositories.
> 
> It is good that such tools are available to help surmount Git's extreme 
> complexity.  Are there such tools available for Fossil?

Fossil already offers a large subset of what GitHub adds to Git:

1. Issue tracker -> ticket tracker.

2. Wiki

3. Markdown file rendering, including README.md rendering in file view, 
allowing embedded web documentation.

4. Graphical commit history.

5. Branch and tag displays.

6. Web user management, role-based access control.

7. Full-text repository search.

8. Automatic cross-linking of tickets/issues, comments, wiki articles, etc.


There are still some things GitHub does which Fossil does not, usually on 
purpose:

1. Pull request tracking.  This falls out of GitHub’s centralization, which as 
I argued in a separate post is one of the risks of using GitHub.

2. Gists.  Fossil has other ways of accomplishing much the same end, but 
nothing exactly like it.

3. Code review between push and pull.  Fossil is intended for teams small 
enough where social solutions to bogus checkins are usually sufficient, with 
technical measures to back that up.  (e.g. fossil merge --backout, fossil amend 
--branch bogus, etc.)

4. Social networking.  (@ mentions, etc.)  Again something that requires 
centralization.

5. github.io: Not needed with Fossil, since by using it, you’re already running 
a server of some kind, so you have the ability to run a web site alongside your 
code repository.  My two largest public Fossils are hybrids of this sort, with 
some URLs served by Fossil and some by the static web server.

6. More and prettier graphs and such.  Woo.  :)


And there are several things that Fossil does which GitHub does not:

1. Easy diffing between two checkins from the timeline view.

2. .wiki embedded documentation rendering in addition to .md

3. Skinning.  Every GitHub-hosted project looks the same.  Many built-in skins 
if you just want to pick one rather than design one, or if you’d rather riff 
off of someone else’s core design.

4. Single-executable, truly free, with no tie to a central authority.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[John McKown]

On Tue, Dec 26, 2017 at 3:31 PM, Keith Medcalf  wrote:

>
> Heavens forbid!
>
> How is it possible to work if not from a Command-Line window?  That is,
> YUCK.
> Seriously how can anyone get any work done at all without having a command
> prompt at which one, how to put this, types commands?
>
> I happen to be one of those that holds Ashton-Tate's dBase II (or was it
> III, anyway, one of them) had the absolute best interface ever designed --
> a completely blank screen with a . in the upper left corner as a prompt at
> which you entered commands.  Absolutely beautiful design with absolutely no
> useless crap to get in the way!
>
> The first thing be consigned to the bitbucket on *ANY* Operating System
> worth using is the "Graphical User Interface".  And if you cannot get rid
> of it (like windows) its sole purpose is to open a command prompt to, you
> know, prompt for commands.
>
> Graphical User Interfaces are mostly designed by maroons for use by other
> maroons.  There are a few (very few) things which a GUI is any good for.
> Issuing commands and software development is not one of them.  (I have
> never seen a Graphical Editor that works worth a pinch of coon-poo, and
> so-called IDE's are useless steaming turds as well, most dependent on
> completely unusable editors -- the absolute worst abomination being, of
> course, Visual Studio).
>

​Well, this is very off-topic for this forum. But I'll interject that I
generally agree with you. However, I do think that some things are better
in a graphical environment. Such as, say, a paint program? {grin}. Now, for
an interactive SQL interface, I like using SQLite's command program; or
PostgreSQL's psql. I haven't really tried any SQL GUI interfaces other than
Oracle's. I use it mainly because it's all that I was given on the Windows
desktop at work. I haven't seen very many "character mode" applications any
more for things such as Word Processing or Spreadsheets. I did use Word
Perfect and​ Lotus 1-2-3 back in the MS-DOS days. But today's users want a
word process which is WYSIWYG and want their spreadsheets to create pretty
*π* charts.



>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Keith Medcalf]

Heavens forbid!

How is it possible to work if not from a Command-Line window?  That is, YUCK.
Seriously how can anyone get any work done at all without having a command 
prompt at which one, how to put this, types commands?

I happen to be one of those that holds Ashton-Tate's dBase II (or was it III, 
anyway, one of them) had the absolute best interface ever designed -- a 
completely blank screen with a . in the upper left corner as a prompt at which 
you entered commands.  Absolutely beautiful design with absolutely no useless 
crap to get in the way!

The first thing be consigned to the bitbucket on *ANY* Operating System worth 
using is the "Graphical User Interface".  And if you cannot get rid of it (like 
windows) its sole purpose is to open a command prompt to, you know, prompt for 
commands.

Graphical User Interfaces are mostly designed by maroons for use by other 
maroons.  There are a few (very few) things which a GUI is any good for.  
Issuing commands and software development is not one of them.  (I have never 
seen a Graphical Editor that works worth a pinch of coon-poo, and so-called 
IDE's are useless steaming turds as well, most dependent on completely unusable 
editors -- the absolute worst abomination being, of course, Visual Studio).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Scott Doctor
>Sent: Tuesday, 26 December, 2017 14:07
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] Move to Github!!?
>
>
>What fossil needs is for the UI to perform ALL normal common
>functions (new, commit, clone,...) WITHOUT having to open a
>command line window. That is imo the main limitation.
>
>
>-
>Scott Doctor
>sc...@scottdoctor.com
>-
>
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Warren Young]

On Dec 26, 2017, at 2:47 AM, J Decker  wrote:
> 
> doesn't require a fee unless they want to amke it private.

You’re speaking of today’s benevolent policies.

Let’s review:

1. SourceForge: Once the largest host of FOSS software, eventually became 
“evil” in the eyes of many of its users: lots of ads, removal of download 
options, delays in downloads, injection of adware into FOSS binaries uploaded 
by their customers…

2. Google Code: fully beneveolent…until Google got bored and quit.

3. Gna!:  A clone of GNU Savannah without the strict GNU policies, they 
announced that they were going to stop offering service, then cut it off 
without even providing the read-only access that Google Code did.  This 
announcement only went out on one of their own mailing lists; I never saw it 
echoed on the other FOSS news channels I monitor.  So one day, one of my 
project repositories just disappeared off the web, with no way to recover it.

4. CodePlex: A huge project host once upon a time, it was shut down less than 2 
weeks ago.

So instead of keeping control of our own tooling, we’re going to hand off 
control to yet another benevolent-for-now free software host?  This time for 
sure?

Keep in mind that the things people like about GitHub do not go with a project 
when someone takes their Git clone of the project and pushes it to the next big 
FOSS project hosting provider, whatever that may be.  The community, the issue 
tracker, the pull tracker, github.io, and more all go away.  So, you get to 
keep all of these nice improvements over Git only as long as GitHub, Inc. is 
willing to let you have them.

It’s important that GitHub, Inc. does so only as long as they have serious 
competition.  There are a few major FOSS hosts left, but they’re getting 
scarce, and they’re often hosted by companies with motives no purer.  
(Atlassian, Microsoft, etc.)

> I have a version on github I've been keeping up to date for the last month
> or so...  https://github.com/d3x0r/sqlite3

That’s another problem with GitHub: everyone can fork, so finding the “best” 
fork is often a matter of relying on Google juice, hearsay, and luck.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Scott Doctor]

What fossil needs is for the UI to perform ALL normal common 
functions (new, commit, clone,...) WITHOUT having to open a 
command line window. That is imo the main limitation.



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


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Keith Medcalf]

On Tuesday, 26 December, 2017 13:28, J Decker <d3c...@gmail.com> wrote:

>On Tue, Dec 26, 2017 at 12:25 PM, Keith Medcalf <kmedc...@dessus.com>
>wrote:

>> Isn't GitHub a place for Gits to hang out, sort of like Twitter is
>> a place for Twits to hang out?

>Nope that's gitter.im (related, and integrates well with github for
>talking about issues and pull requests.  Will even pull information about
>issues creates/commented on and commits.  Really nice for talking about code
>fragments since it supports markdown.

I just looked at Git (for Windows).  What a horrid abomination it is!

Fossil does all the same things in a SINGLE < 5 Megabyte executable.  

Git is a horrid huge pile of crap that is several orders of magnitude larger 
and includes a whole mess of crap with built-in interferences with other 
software.  There is no way that I would permit it to be installed on any 
computer of mine.  At least it does not appear to use CYGWIN (which would 
preclude it from being in the same building as a computer).

Since I already appeared to have a copy from some time ago in a repository, I 
expect that I looked at it once before and arrived at the same conclusion -- it 
is not software that one ought to allow to be installed on a 
non-entertainment-only computer that runs Windows.

>> ---
>> The fact that there's a Highway to Hell but only a Stairway to
>> Heaven says a lot about anticipated traffic volume.

>> >-Original Message-
>> >From: sqlite-users [mailto:sqlite-users-
>> >boun...@mailinglists.sqlite.org] On Behalf Of Bob Friesenhahn
>> >Sent: Tuesday, 26 December, 2017 12:08
>> >To: SQLite mailing list
>> >Subject: Re: [sqlite] Move to Github!!?
>> >
>> >On Tue, 26 Dec 2017, J Decker wrote:
>> >>> Why aren't you moving all of your GitHub projects over to
>Fossil!
>> >>>
>> >> Because Pull Requests, and a larger variety of tools to deal
>with
>> >Git
>> >> repositories.
>> >
>> >It is good that such tools are available to help surmount Git's
>> >extreme complexity.  Are there such tools available for Fossil?
>> >
>> >Bob
>> >--
>> >Bob Friesenhahn
>> >bfrie...@simple.dallas.tx.us,
>> >http://www.simplesystems.org/users/bfriesen/
>> >GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
>> >___
>> >sqlite-users mailing list
>> >sqlite-users@mailinglists.sqlite.org
>> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Simon Slavin]

On 26 Dec 2017, at 7:07pm, Bob Friesenhahn  wrote:

> On Tue, 26 Dec 2017, J Decker wrote:
> 
>>> Why aren't you moving all of your GitHub projects over to Fossil!
>> 
>> Because Pull Requests, and a larger variety of tools to deal with Git
>> repositories.
> 
> It is good that such tools are available to help surmount Git's extreme 
> complexity. Are there such tools available for Fossil?

Your question assumes that Fossil has such extreme complexity that such tools 
are needed.  And that Fossil has drawbacks that needs surmounting.

I bet you tell people not to move from Windows to the Mac for the same reason.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J Decker]

On Tue, Dec 26, 2017 at 12:25 PM, Keith Medcalf <kmedc...@dessus.com> wrote:

>
> Isn't GitHub a place for Gits to hang out, sort of like Twitter is a place
> for Twits to hang out?
>

Nope that's gitter.im (related, and integrates well with github for talking
about issues and pull requests.  Will even pull information about issues
creates/commented on and commits.  Really nice for talking about code
fragments since it supports markdown.


>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
> >-Original Message-
> >From: sqlite-users [mailto:sqlite-users-
> >boun...@mailinglists.sqlite.org] On Behalf Of Bob Friesenhahn
> >Sent: Tuesday, 26 December, 2017 12:08
> >To: SQLite mailing list
> >Subject: Re: [sqlite] Move to Github!!?
> >
> >On Tue, 26 Dec 2017, J Decker wrote:
> >>> Why aren't you moving all of your GitHub projects over to Fossil!
> >>>
> >> Because Pull Requests, and a larger variety of tools to deal with
> >Git
> >> repositories.
> >
> >It is good that such tools are available to help surmount Git's
> >extreme complexity.  Are there such tools available for Fossil?
> >
> >Bob
> >--
> >Bob Friesenhahn
> >bfrie...@simple.dallas.tx.us,
> >http://www.simplesystems.org/users/bfriesen/
> >GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> >___
> >sqlite-users mailing list
> >sqlite-users@mailinglists.sqlite.org
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Keith Medcalf]

Isn't GitHub a place for Gits to hang out, sort of like Twitter is a place for 
Twits to hang out?

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Bob Friesenhahn
>Sent: Tuesday, 26 December, 2017 12:08
>To: SQLite mailing list
>Subject: Re: [sqlite] Move to Github!!?
>
>On Tue, 26 Dec 2017, J Decker wrote:
>>> Why aren't you moving all of your GitHub projects over to Fossil!
>>>
>> Because Pull Requests, and a larger variety of tools to deal with
>Git
>> repositories.
>
>It is good that such tools are available to help surmount Git's
>extreme complexity.  Are there such tools available for Fossil?
>
>Bob
>--
>Bob Friesenhahn
>bfrie...@simple.dallas.tx.us,
>http://www.simplesystems.org/users/bfriesen/
>GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Bob Friesenhahn]

On Tue, 26 Dec 2017, J Decker wrote:

Why aren't you moving all of your GitHub projects over to Fossil!


Because Pull Requests, and a larger variety of tools to deal with Git
repositories.


It is good that such tools are available to help surmount Git's 
extreme complexity.  Are there such tools available for Fossil?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J Decker]

On Tue, Dec 26, 2017 at 5:10 AM, Richard Hipp  wrote:

> On 12/25/17, Shekhar Reddy  wrote:
> >
> > Is there any particular reason that the source is not moved to GitHub? I
> > think that would reach more number of people there.
> >
>
> There is a mirror of the SQLite repository on GitHub at
> https://github.com/mackyle/sqlite (maintained by GitHub user "mackyle"
> whom I do not know, but whose efforts I do appreciate).
>
> SQLite uses a different version control system called Fossil.  See
> https://www.fossil-scm.org/ for more information about Fossil.  Fossil
> is superior to Git+GitHub in many respects.  You can easily see this
> by doing a side-by-side comparison of the SQLite Fossil repository
> against the GitHub mirror.
>
> For example, here is the GitHub view of the "dbpage" branch of SQLite:
>
>  https://github.com/mackyle/sqlite/commits/dbpage
>
> Compare the above against the equivalent Fossil view:
>
>  https://www.sqlite.org/src/timeline?p=dfdebd12bfc80b91
>
> The Fossil view clearly shows that the head of "dbpage" is the merger
> of two other branches, and Fossil shows clearly where the branch
> diverged from trunk.  That information is very difficult to discern
> from the GitHub view.
>

That's a limitation of the webpage interface not of git itself...  (would
include a picture but I can't... well maybe I can indirectly...

 https://drive.google.com/open?id=1mhDcCotCMVyI3PF70dCvD4AAyVZGVoWW


> Fossil also has the ability to show the complete context of an
> individual branch.  For the "dbpage" branch, the context is shown
> here:
>
>  https://www.sqlite.org/src/timeline?r=dbpage
>
> Note in particular that Fossil clearly shows that the "dbpage" branch
> was ultimately merged back into trunk.  GitHub does not provide that
> information, as far as I can tell.
>

Or all the forks of a popular project...
https://github.com/bulletphysics/bullet3/network


>
> The basic problem with Git (apart from its notoriously convoluted user
> interface) is that it is based on a (bespoke) key/value database - the
> "packfile".  Fossil, on the other hand, is based on the most widely
> used relational database in the world.  This make information much
> easier to extract from Fossil than from Git.  For example, given a
> commit in Git (perhaps one reported by a customer or one found via
> bisect) there is no easy way in Git to find out what comes next - what
> commits were entered using your commit as a baseline.  Git shows
> ancestors, but not descendants.  Fossil, on the other hand, easily
> shows both descendants and ancestors of a check-in. You see this in
> the "Context" section of any Fossil commit page, such as
> https://www.sqlite.org/src/info/dfdebd12bfc80b91
>
> The fact that Git/GitHub does not show the descendants of a commit is
> a show-stopper for me.
>
> For t he view around a single commit I can see that might be something you
could get used to... but the graph line is complete and available to know
what is both before and after a commit in overall views.


> Finally, the use of GitHub would create a reliance on an outside
> company over which we have no influence.  The people who run GitHub
> today seem like great folks.  But the company might be sold or fall
> under new management tomorrow, and the friendly and open policies that
> govern GitHub today might change in an instant.  Fossil, on the other
> hand, is very simple to self-host on a $5/month VPS. (SQLite uses
> https://www.linode.com/ for its main servers and
> https://www.digitalocean.com for the https://www3.sqlite.org/ backup.
> There are lots of others.)
>
> So, given that Fossil is freer than Git (BSD vs. GPL), that Fossil
> embodies all of the functionality of both Git and GitHub, that Fossil
> is more capable than Git/GitHub, that Fossil has a friendly user
> interface than Git, and that Fossil is very easy to self-host and thus
> frees you of any dependencies on third-party companies, the question
> becomes:
>
> Why aren't you moving all of your GitHub projects over to Fossil!
>
>
Because Pull Requests, and a larger variety of tools to deal with Git
repositories.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J Decker]

On Tue, Dec 26, 2017 at 5:10 AM, Richard Hipp  wrote:

>
> Finally, the use of GitHub would create a reliance on an outside
> company over which we have no influence.  The people who run GitHub
> today seem like great folks.  But the company might be sold or fall
> under new management tomorrow, and the friendly and open policies that
> govern GitHub today might change in an instant.  Fossil, on the other
> hand, is very simple to self-host on a $5/month VPS. (SQLite uses
> https://www.linode.com/ for its main servers and
> https://www.digitalocean.com for the https://www3.sqlite.org/ backup.
> There are lots of others.)
>
>
And there's nothing stopping anyone from hosting their own git repositories
with or without a web interface.  I have a backup repos at work, on my home
server and github.

A large list of extra tools ... probably at least one has immediate
descendents available.

https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools


> So, given that Fossil is freer than Git (BSD vs. GPL), that Fossil
> embodies all of the functionality of both Git and GitHub, that Fossil
> is more capable than Git/GitHub, that Fossil has a friendly user
> interface than Git, and that Fossil is very easy to self-host and thus
> frees you of any dependencies on third-party companies, the question
> becomes:
>
> Why aren't you moving all of your GitHub projects over to Fossil!
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Eduardo]

On Tue, 26 Dec 2017 10:27:39 -0500
"J. King"  escribió:

> I use Git, but I'm not attached to it. I run my own publicly-accessible 
> remote (using Gitea), but that would be completely replaceable with Fossil 
> (which I am very impressed by).
> 
> What's not so easy to replace is the Git integration in my editor (Visual 
> Studio Code) which allows me to easily perform basic operation like commit, 
> push, pull, and rebase. 
> 
> Even just to the ability to review diffs and perform checkins in my editor 
> would be enough, but I doubt it will happen anytime soon, if ever, and I 
> don't have the expertise required to hack it on myself. 
> 
> Until the landscape changes (or someone can suggest suitable Windows 
> software), I will continue to admire Fossil from afar.
> 


When I used VS2015 in the past, I followed this steps:

Create a new menu entry for Fossil:
a) Menu Tools->Customize, "Commands" tab, "Add New Menu" button  // This create 
a new menu on tool bar
b) Select the "New Menu" created, click on "Modify Selection" button and change 
its name to "Fossil"
c) Move it up or down and click "Close" button when finished

Create "External Tools"
a) Menu Tools->External Tools..., 
b) Click on "Add" button
c) Fill data: "Title=Commit", "Command=C:\Fossil\fossil.exe", "Argument=commit 
-m", "Initial Directory=$(ProjectDir)"
d) Check the check boxes "Use Output Windows", "Prompt for Argument"
e) Annotate the entry number of the external command, if it's the 3rd or 7th.

Add created external tool to Fossil menu
a) Menu Tools->Customize, "Commands" tab,
b) Check "Menu bar" radius button and select "Fossil" from the selectable list 
(Default value is "Menu Bar")
c) The "Controls" display should be empty for the first fossil command, 
d) Click "Add Command" button, select "Tools" from "Categories" left list and 
"External Command XX" where XX is the number annotated,
e) Click "Modify Selection" to change name to "Fossil Commit"


Add commands as needed, but don't change the order in "Tools" menu, the number 
annotated correspond with the "Fossil" menu entry, if you rearrange them, 
you'll call the wrong external tool.

HTH, but command prompt is easier for me.

-- 
Eduardo 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[John McKown]

On Tue, Dec 26, 2017 at 9:45 AM, Don V Nielsen 
wrote:

> > What's not so easy to replace is the Git integration in my editor (Visual
> Studio Code)
>
> Same here, but I use JetBrains products. I put a bug in the ear of
> JetBrains. At least its something.
>
> Have a good one, all
>

​I don't know either of those products. Mainly because I'm not a Windows'
developer. Do they have a publicly documented interface between their
product and a source maintenance system (e.g. git, cvs, ...)? If not, then
I guess they are dependent on writing a "one off" for every SCM that they
want to support. IMO, that would be very short sighted. ​

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Don V Nielsen]

> What's not so easy to replace is the Git integration in my editor (Visual
Studio Code)

Same here, but I use JetBrains products. I put a bug in the ear of
JetBrains. At least its something.

Have a good one, all

On Tue, Dec 26, 2017 at 9:27 AM, J. King <jk...@jkingweb.ca> wrote:

> I use Git, but I'm not attached to it. I run my own publicly-accessible
> remote (using Gitea), but that would be completely replaceable with Fossil
> (which I am very impressed by).
>
> What's not so easy to replace is the Git integration in my editor (Visual
> Studio Code) which allows me to easily perform basic operation like commit,
> push, pull, and rebase.
>
> Even just to the ability to review diffs and perform checkins in my editor
> would be enough, but I doubt it will happen anytime soon, if ever, and I
> don't have the expertise required to hack it on myself.
>
> Until the landscape changes (or someone can suggest suitable Windows
> software), I will continue to admire Fossil from afar.
>
> On December 26, 2017 10:08:08 AM EST, Damien Sykes <
> dam...@dcpendleton.plus.com> wrote:
> >Hi,
> >This is a question I have asked myself many times (I.E. Git projects
> >moving
> >to Fossil).
> >GitHub is well known and boasts over 74 million repositories, yet
> >Fossil,
> >which both hosts and utilises one of the most well-known database
> >systems in
> >the world, I doubt can count a thousand. Even the ChiselApp hosting
> >platform
> >hosts a mere 360 public repositories, Hydra hosts 11, WanderingHorse
> >hosts
> >23, outside of which lie Fossil itself, the Fossil book, SQLite and
> >friends
> >(5 publicly accessible repositories in all), and TCL and friends (7
> >repositories), making a total of 408. Add SQLite private repositories,
> >and
> >private repositories that I host, have access to or otherwise generally
> >know
> >exist, and I come up with an estimate of roughly 470 repositories. Of
> >course
> >this is not an accurate statistic since it may exclude more private
> >repositories, and definitely excludes any local repositories (I for one
> >have
> >about a dozen Git repositories as Fossil repositories).
> >While I am making every attempt to try to persuade friends towards
> >Fossil,
> >they are also choosing Git. Looks to me like the only people who seem
> >to use
> >Fossil are those who are most associated with it, which is a real
> >shame.
> >The only advantage I can see with GitHub is that it's the source code
> >Twitter equivalent. Everybody's repository is in one place. As long as
> >you
> >know the username and repository name you know the full repository URL,
> >and
> >you don't have to worry about server administration. With Fossil, if I
> >wanted to make it feel like github, I.E. address.tld/user/repo, I would
> >have
> >to script it and serve it via a webserver rather than Fossil's own
> >server,
> >two processes which I am not at all skilled enough, at least at the
> >moment,
> >to undertake. To give you an example, I am currently having to run two
> >systems, one for my website and one for Fossil, so that they can both
> >work
> >on port 80, because I know nothing about networking in order to
> >understand
> >IP addresses, ports and connections in the way I'd need to get a server
> >and
> >Fossil to run on port 80 on the same machine, nor do I know enough
> >about
> >webservers to be able to get it to work with CGI. In fact I know so
> >little
> >that I follow installation guides to the letter and have to do a
> >complete
> >fresh server reset and reinstall from scratch when something goes wrong
> >
> >because I haven't a clue how to fix it. If I'm to be totally honest at
> >the
> >moment I'm even beginning to doubt my own software development skills.
> >If there were a Fossil-based github-like system, and both Fossil and
> >the
> >hosting system were well promoted, Fossil may or may not become the
> >norm.
> >Having said that, the advantage of Fossil over Git is that, thanks to
> >the
> >webserver, you can easily look at your changes in a laid-out website,
> >even
> >on your own machine. I've many a time found myself importing Git
> >repositories into Fossil just to look at the timeline. Plus, you don't
> >have
> >to worry about complicated concepts like pull requests, synchronising
> >forks
> >and submodules etc. Though it doesn't matter what VCS I use I always
> >seem to
> >come across, and struggle with, the concept of branching and merging!
> >In any case, my incompeten

Re: [sqlite] Move to Github!!?

[J. King]

I use Git, but I'm not attached to it. I run my own publicly-accessible remote 
(using Gitea), but that would be completely replaceable with Fossil (which I am 
very impressed by).

What's not so easy to replace is the Git integration in my editor (Visual 
Studio Code) which allows me to easily perform basic operation like commit, 
push, pull, and rebase. 

Even just to the ability to review diffs and perform checkins in my editor 
would be enough, but I doubt it will happen anytime soon, if ever, and I don't 
have the expertise required to hack it on myself. 

Until the landscape changes (or someone can suggest suitable Windows software), 
I will continue to admire Fossil from afar.

On December 26, 2017 10:08:08 AM EST, Damien Sykes 
<dam...@dcpendleton.plus.com> wrote:
>Hi,
>This is a question I have asked myself many times (I.E. Git projects
>moving 
>to Fossil).
>GitHub is well known and boasts over 74 million repositories, yet
>Fossil, 
>which both hosts and utilises one of the most well-known database
>systems in 
>the world, I doubt can count a thousand. Even the ChiselApp hosting
>platform 
>hosts a mere 360 public repositories, Hydra hosts 11, WanderingHorse
>hosts 
>23, outside of which lie Fossil itself, the Fossil book, SQLite and
>friends 
>(5 publicly accessible repositories in all), and TCL and friends (7 
>repositories), making a total of 408. Add SQLite private repositories,
>and 
>private repositories that I host, have access to or otherwise generally
>know 
>exist, and I come up with an estimate of roughly 470 repositories. Of
>course 
>this is not an accurate statistic since it may exclude more private 
>repositories, and definitely excludes any local repositories (I for one
>have 
>about a dozen Git repositories as Fossil repositories).
>While I am making every attempt to try to persuade friends towards
>Fossil, 
>they are also choosing Git. Looks to me like the only people who seem
>to use 
>Fossil are those who are most associated with it, which is a real
>shame.
>The only advantage I can see with GitHub is that it's the source code 
>Twitter equivalent. Everybody's repository is in one place. As long as
>you 
>know the username and repository name you know the full repository URL,
>and 
>you don't have to worry about server administration. With Fossil, if I 
>wanted to make it feel like github, I.E. address.tld/user/repo, I would
>have 
>to script it and serve it via a webserver rather than Fossil's own
>server, 
>two processes which I am not at all skilled enough, at least at the
>moment, 
>to undertake. To give you an example, I am currently having to run two 
>systems, one for my website and one for Fossil, so that they can both
>work 
>on port 80, because I know nothing about networking in order to
>understand 
>IP addresses, ports and connections in the way I'd need to get a server
>and 
>Fossil to run on port 80 on the same machine, nor do I know enough
>about 
>webservers to be able to get it to work with CGI. In fact I know so
>little 
>that I follow installation guides to the letter and have to do a
>complete 
>fresh server reset and reinstall from scratch when something goes wrong
>
>because I haven't a clue how to fix it. If I'm to be totally honest at
>the 
>moment I'm even beginning to doubt my own software development skills.
>If there were a Fossil-based github-like system, and both Fossil and
>the 
>hosting system were well promoted, Fossil may or may not become the
>norm.
>Having said that, the advantage of Fossil over Git is that, thanks to
>the 
>webserver, you can easily look at your changes in a laid-out website,
>even 
>on your own machine. I've many a time found myself importing Git 
>repositories into Fossil just to look at the timeline. Plus, you don't
>have 
>to worry about complicated concepts like pull requests, synchronising
>forks 
>and submodules etc. Though it doesn't matter what VCS I use I always
>seem to 
>come across, and struggle with, the concept of branching and merging!
>In any case, my incompetencies aside. People seem to be slowly moving
>away 
>from SourceForge in favour of GitHub. If only we could make the same 
>revolution with Fossil! Ironically when I first came across a site
>called 
>FossHub I actually thought that was an attempt to make a Fossil-based 
>GitHub. Seems that isn't the case after all.
>Cheers.
>Damien.
>-Original Message- 
>From: Richard Hipp
>Sent: Tuesday, December 26, 2017 1:10 PM
>To: SQLite mailing list
>Cc: shekharreddy.k...@gmail.com
>Subject: Re: [sqlite] Move to Github!!?
>
>On 12/25/17, Shekhar Reddy <shekharreddy.k...@gmail.com> wrote:
>>
>> Is there any particular reason that the source is not mo

Re: [sqlite] Move to Github!!?

[Damien Sykes]

Hi,
This is a question I have asked myself many times (I.E. Git projects moving 
to Fossil).
GitHub is well known and boasts over 74 million repositories, yet Fossil, 
which both hosts and utilises one of the most well-known database systems in 
the world, I doubt can count a thousand. Even the ChiselApp hosting platform 
hosts a mere 360 public repositories, Hydra hosts 11, WanderingHorse hosts 
23, outside of which lie Fossil itself, the Fossil book, SQLite and friends 
(5 publicly accessible repositories in all), and TCL and friends (7 
repositories), making a total of 408. Add SQLite private repositories, and 
private repositories that I host, have access to or otherwise generally know 
exist, and I come up with an estimate of roughly 470 repositories. Of course 
this is not an accurate statistic since it may exclude more private 
repositories, and definitely excludes any local repositories (I for one have 
about a dozen Git repositories as Fossil repositories).
While I am making every attempt to try to persuade friends towards Fossil, 
they are also choosing Git. Looks to me like the only people who seem to use 
Fossil are those who are most associated with it, which is a real shame.
The only advantage I can see with GitHub is that it's the source code 
Twitter equivalent. Everybody's repository is in one place. As long as you 
know the username and repository name you know the full repository URL, and 
you don't have to worry about server administration. With Fossil, if I 
wanted to make it feel like github, I.E. address.tld/user/repo, I would have 
to script it and serve it via a webserver rather than Fossil's own server, 
two processes which I am not at all skilled enough, at least at the moment, 
to undertake. To give you an example, I am currently having to run two 
systems, one for my website and one for Fossil, so that they can both work 
on port 80, because I know nothing about networking in order to understand 
IP addresses, ports and connections in the way I'd need to get a server and 
Fossil to run on port 80 on the same machine, nor do I know enough about 
webservers to be able to get it to work with CGI. In fact I know so little 
that I follow installation guides to the letter and have to do a complete 
fresh server reset and reinstall from scratch when something goes wrong 
because I haven't a clue how to fix it. If I'm to be totally honest at the 
moment I'm even beginning to doubt my own software development skills.
If there were a Fossil-based github-like system, and both Fossil and the 
hosting system were well promoted, Fossil may or may not become the norm.
Having said that, the advantage of Fossil over Git is that, thanks to the 
webserver, you can easily look at your changes in a laid-out website, even 
on your own machine. I've many a time found myself importing Git 
repositories into Fossil just to look at the timeline. Plus, you don't have 
to worry about complicated concepts like pull requests, synchronising forks 
and submodules etc. Though it doesn't matter what VCS I use I always seem to 
come across, and struggle with, the concept of branching and merging!
In any case, my incompetencies aside. People seem to be slowly moving away 
from SourceForge in favour of GitHub. If only we could make the same 
revolution with Fossil! Ironically when I first came across a site called 
FossHub I actually thought that was an attempt to make a Fossil-based 
GitHub. Seems that isn't the case after all.

Cheers.
Damien.
-Original Message- 
From: Richard Hipp

Sent: Tuesday, December 26, 2017 1:10 PM
To: SQLite mailing list
Cc: shekharreddy.k...@gmail.com
Subject: Re: [sqlite] Move to Github!!?

On 12/25/17, Shekhar Reddy <shekharreddy.k...@gmail.com> wrote:


Is there any particular reason that the source is not moved to GitHub? I
think that would reach more number of people there.



There is a mirror of the SQLite repository on GitHub at
https://github.com/mackyle/sqlite (maintained by GitHub user "mackyle"
whom I do not know, but whose efforts I do appreciate).

SQLite uses a different version control system called Fossil.  See
https://www.fossil-scm.org/ for more information about Fossil.  Fossil
is superior to Git+GitHub in many respects.  You can easily see this
by doing a side-by-side comparison of the SQLite Fossil repository
against the GitHub mirror.

For example, here is the GitHub view of the "dbpage" branch of SQLite:

https://github.com/mackyle/sqlite/commits/dbpage

Compare the above against the equivalent Fossil view:

https://www.sqlite.org/src/timeline?p=dfdebd12bfc80b91

The Fossil view clearly shows that the head of "dbpage" is the merger
of two other branches, and Fossil shows clearly where the branch
diverged from trunk.  That information is very difficult to discern
from the GitHub view.

Fossil also has the ability to show the complete context of an
individual branch.  For the "dbpage" branch, the cont

Re: [sqlite] Move to Github!!?

[Richard Hipp]

On 12/25/17, Shekhar Reddy  wrote:
>
> Is there any particular reason that the source is not moved to GitHub? I
> think that would reach more number of people there.
>

There is a mirror of the SQLite repository on GitHub at
https://github.com/mackyle/sqlite (maintained by GitHub user "mackyle"
whom I do not know, but whose efforts I do appreciate).

SQLite uses a different version control system called Fossil.  See
https://www.fossil-scm.org/ for more information about Fossil.  Fossil
is superior to Git+GitHub in many respects.  You can easily see this
by doing a side-by-side comparison of the SQLite Fossil repository
against the GitHub mirror.

For example, here is the GitHub view of the "dbpage" branch of SQLite:

 https://github.com/mackyle/sqlite/commits/dbpage

Compare the above against the equivalent Fossil view:

 https://www.sqlite.org/src/timeline?p=dfdebd12bfc80b91

The Fossil view clearly shows that the head of "dbpage" is the merger
of two other branches, and Fossil shows clearly where the branch
diverged from trunk.  That information is very difficult to discern
from the GitHub view.

Fossil also has the ability to show the complete context of an
individual branch.  For the "dbpage" branch, the context is shown
here:

 https://www.sqlite.org/src/timeline?r=dbpage

Note in particular that Fossil clearly shows that the "dbpage" branch
was ultimately merged back into trunk.  GitHub does not provide that
information, as far as I can tell.

The basic problem with Git (apart from its notoriously convoluted user
interface) is that it is based on a (bespoke) key/value database - the
"packfile".  Fossil, on the other hand, is based on the most widely
used relational database in the world.  This make information much
easier to extract from Fossil than from Git.  For example, given a
commit in Git (perhaps one reported by a customer or one found via
bisect) there is no easy way in Git to find out what comes next - what
commits were entered using your commit as a baseline.  Git shows
ancestors, but not descendants.  Fossil, on the other hand, easily
shows both descendants and ancestors of a check-in. You see this in
the "Context" section of any Fossil commit page, such as
https://www.sqlite.org/src/info/dfdebd12bfc80b91

The fact that Git/GitHub does not show the descendants of a commit is
a show-stopper for me.

Finally, the use of GitHub would create a reliance on an outside
company over which we have no influence.  The people who run GitHub
today seem like great folks.  But the company might be sold or fall
under new management tomorrow, and the friendly and open policies that
govern GitHub today might change in an instant.  Fossil, on the other
hand, is very simple to self-host on a $5/month VPS. (SQLite uses
https://www.linode.com/ for its main servers and
https://www.digitalocean.com for the https://www3.sqlite.org/ backup.
There are lots of others.)

So, given that Fossil is freer than Git (BSD vs. GPL), that Fossil
embodies all of the functionality of both Git and GitHub, that Fossil
is more capable than Git/GitHub, that Fossil has a friendly user
interface than Git, and that Fossil is very easy to self-host and thus
frees you of any dependencies on third-party companies, the question
becomes:

Why aren't you moving all of your GitHub projects over to Fossil!

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J Decker]

On Mon, Dec 25, 2017 at 8:24 PM, Jay Kreibich  wrote:

>
> > On Dec 25, 2017, at 12:24 PM, J. King  wrote:
> >
> > SQLite source is managed in a Fossil (not Git)  repository, which is
> software itself designed by Dr. Hipp and based on SQLite. GitHub would be
> an entirely inappropriate venue.
> >
> > SQLite is also not open source software in the conventional sense.
> SQLite is written by a small team of people, and outside contributions are
> far less common than in most open source software.
>
>
> Indeed.  The core SQLite source code is free (as in beer, as in freedom),
> but its development is carefully controlled by Hwaci, the company
> responsible for employing SQLite developers.  Hwaci also owns the trademark
> to the name SQLite. Hwaci has several products, including extensions such
> as the SQLite encryption extensions, that are NOT free (as in beer, nor as
> in freedom).  The testing system used for SQLite, which represents a source
> base several times larger than the SQLite core, is also completely
> private.  Hosting such systems on Github would require a subscription fee
> and, frankly, why should they bother?
>
>
doesn't require a fee unless they want to amke it private.  It's not
private as it is (though it is a bit more work to track down how to get it).
They could still maintain strict control over merges as a public project.

I have a version on github I've been keeping up to date for the last month
or so...  https://github.com/d3x0r/sqlite3
  (And no, I don't plan to
maintain this forever; although it might end up that way)

Migrating the original fossil to github would be a lot of work to rebuild
the history in git format; plus they would lose color tagging on
branches...
Fossil is actually simpler to deal with since it's a single executable.


   -j
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Jay Kreibich]

> On Dec 25, 2017, at 12:24 PM, J. King  wrote:
> 
> SQLite source is managed in a Fossil (not Git)  repository, which is software 
> itself designed by Dr. Hipp and based on SQLite. GitHub would be an entirely 
> inappropriate venue. 
> 
> SQLite is also not open source software in the conventional sense. SQLite is 
> written by a small team of people, and outside contributions are far less 
> common than in most open source software. 


Indeed.  The core SQLite source code is free (as in beer, as in freedom), but 
its development is carefully controlled by Hwaci, the company responsible for 
employing SQLite developers.  Hwaci also owns the trademark to the name SQLite. 
Hwaci has several products, including extensions such as the SQLite encryption 
extensions, that are NOT free (as in beer, nor as in freedom).  The testing 
system used for SQLite, which represents a source base several times larger 
than the SQLite core, is also completely private.  Hosting such systems on 
Github would require a subscription fee and, frankly, why should they bother?

   -j

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Jungle Boogie]

On Mon 25 Dec 2017 11:49 PM, Shekhar Reddy wrote:
> Hi,
> 
> Is there any particular reason that the source is not moved to GitHub? I
> think that would reach more number of people there.
> 

So are you saying it would be the most used in the galaxy?
SQLite is the most used database engine in the world.[0]

[0] https://sqlite.org/about.html


> Regards
> Shekhar
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Keith Medcalf]

Heavens forbid!

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Shekhar Reddy
>Sent: Monday, 25 December, 2017 11:19
>To: sqlite-users@mailinglists.sqlite.org
>Subject: [sqlite] Move to Github!!?
>
>Hi,
>
>Is there any particular reason that the source is not moved to
>GitHub? I
>think that would reach more number of people there.
>
>Regards
>Shekhar
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[Stephen Chrzanowski]

As stated, SQLite is managed by Fossil, and Fossil is managed by SQLite.
(I think it was) Dr Hipp that stated that "Fossil is eating its own dog
food".

https://www.google.ca/search?q=eating+your+own+dog+food=utf-8=utf-8=firefox-b_rd=cr=0=SENBWvCGOs6fXo7ynMAJ

https://www.investopedia.com/terms/e/eatyourowndogfood.asp


On Mon, Dec 25, 2017 at 1:24 PM, J. King  wrote:

> SQLite source is managed in a Fossil (not Git)  repository, which is
> software itself designed by Dr. Hipp and based on SQLite. GitHub would be
> an entirely inappropriate venue.
>
> SQLite is also not open source software in the conventional sense. SQLite
> is written by a small team of people, and outside contributions are far
> less common than in most open source software.
>
> On December 25, 2017 1:19:18 PM EST, Shekhar Reddy <
> shekharreddy.k...@gmail.com> wrote:
> >Hi,
> >
> >Is there any particular reason that the source is not moved to GitHub?
> >I
> >think that would reach more number of people there.
> >
> >Regards
> >Shekhar
> >___
> >sqlite-users mailing list
> >sqlite-users@mailinglists.sqlite.org
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Move to Github!!?

[J. King]

SQLite source is managed in a Fossil (not Git)  repository, which is software 
itself designed by Dr. Hipp and based on SQLite. GitHub would be an entirely 
inappropriate venue. 

SQLite is also not open source software in the conventional sense. SQLite is 
written by a small team of people, and outside contributions are far less 
common than in most open source software. 

On December 25, 2017 1:19:18 PM EST, Shekhar Reddy 
 wrote:
>Hi,
>
>Is there any particular reason that the source is not moved to GitHub?
>I
>think that would reach more number of people there.
>
>Regards
>Shekhar
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users