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: 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
