Move to Github!!?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
-------------------------


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Warren Young
In reply to this post by J Decker
On Dec 26, 2017, at 2:47 AM, J Decker <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Keith Medcalf
In reply to this post by Scott Doctor

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-
>[hidden email]] On Behalf Of Scott Doctor
>Sent: Tuesday, 26 December, 2017 14:07
>To: [hidden email]
>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
>[hidden email]
>-------------------------
>
>
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

John McKown
On Tue, Dec 26, 2017 at 3:31 PM, Keith Medcalf <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Warren Young
In reply to this post by Bob Friesenhahn
On Dec 26, 2017, at 12:07 PM, Bob Friesenhahn <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Jungle Boogie
In reply to this post by Damien Sykes-Lindley
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Jungle Boogie
In reply to this post by Warren Young
On Tue 26 Dec 2017  2:09 PM, Warren Young wrote:
> On Dec 26, 2017, at 2:47 AM, J Decker <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Rob Willett
In reply to this post by Jungle Boogie
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 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 +0000, 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: [hidden email]
website: http://www.iveqy.com
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

J Decker
In reply to this post by Fredrik Gustafsson
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]
<https://en.wikipedia.org/wiki/GitHub#cite_note-beginning-10>[11]
<https://en.wikipedia.org/wiki/GitHub#cite_note-githuboneyear-11>[12]
<https://en.wikipedia.org/wiki/GitHub#cite_note-githubfirstcommit-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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Warren Young
In reply to this post by Rob Willett
On Dec 27, 2017, at 3:23 AM, Rob Willett <[hidden email]> 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@.../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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Warren Young
In reply to this post by Nelson, Erik - 2
On Dec 27, 2017, at 7:49 AM, Nelson, Erik - 2 <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Simon Slavin-3
In reply to this post by Fredrik Gustafsson
On 27 Dec 2017, at 1:51pm, Fredrik Gustafsson <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Igor Korot
In reply to this post by Warren Young
Hi,

On Wed, Dec 27, 2017 at 12:00 PM, Warren Young <[hidden email]> wrote:

> On Dec 27, 2017, at 7:49 AM, Nelson, Erik - 2 <[hidden email]> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Simon Slavin-3
In reply to this post by Warren Young


On 27 Dec 2017, at 4:05pm, Warren Young <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Peter da Silva


On 12/27/17, 12:14 PM, "sqlite-users on behalf of Simon Slavin" <[hidden email] on behalf of [hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Simon Slavin-3
On 27 Dec 2017, at 6:49pm, Peter Da Silva <[hidden email]> wrote:

> On 12/27/17, 12:14 PM, "sqlite-users on behalf of Simon Slavin" <[hidden email] on behalf of [hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Warren Young
In reply to this post by Simon Slavin-3
On Dec 27, 2017, at 11:14 AM, Simon Slavin <[hidden email]> wrote:
>
> On 27 Dec 2017, at 4:05pm, Warren Young <[hidden email]> 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@.../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 originally a btrfs-specific feature, but was generalized for other filesystems in Linux kernel 4.5.)

I seem to recall that FreeBSD was talking about adding a similar syscall, but then you probably still wouldn’t get it on Solaris, OpenZFS-on-Linux, O3X…  Or, you’d get it, but then years late, as we see with built-in crypto.

And even if one were to add such a feature to Fossil making use of the macOS 10.13+, Linux 4.5+, and FreeBSD.next syscalls for this, you’re probably still only covering about 2% of the client systems Fossil is currently used on.


[4]: http://man7.org/linux/man-pages/man2/ioctl_fideduperange.2.html
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Move to Github!!?

Simon Slavin-3


On 27 Dec 2017, at 8:10pm, Warren Young <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
123