On Dec 27, 2017, at 3:23 AM, Rob Willett <[email protected]> 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/[email protected]/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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
