On Dec 27, 2017, at 3:23 AM, Rob Willett <rob.sql...@robertwillett.com> 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

Reply via email to