20190823-1623.txt (3211B)
1 ------------------------------------------------------------------------ 2 2019-08-23 16:24:08 UTC 3 ------------------------------------------------------------------------ 4 5 I've been playing with [VCSs][1] lately. 6 7 Is not that [Git][2] does not do all I need ... Is that sometimes is a 8 bit obscure, the ui is exasperating, and the documentation is terrible. 9 Luckily, there's a lot of info scattered on the webs, but I get tired of 10 looking for common stuff there every time I want to do something a bit 11 out of the ordinary workflow (or in a book or something). 12 13 Man pages exists, but the people that do git seem to not remember that 14 sometimes ... 15 16 I tried [fossil][3] and [mercurial][4]. I also work from time to time 17 with [CVS][5], as this is what the OpenBSD team uses, and I've sent some 18 patches for ports. 19 20 Although I have a couple of personal CVS repos, is not my first option 21 for version control, just because it makes pretty difficult to rearrange 22 folders and things like that. Also, the commands and options are not 23 that simple. If it wasn't for those two, it would be more than enough 24 for me. 25 26 About fossil, I have to say it impressed me. It's "just" a [sqlite][6] 27 database and one binary. And this contains the VCS, a wiki, tech notes 28 and a forum ! 29 30 Its all well integrated of course. That's the VCS that the sqlite 31 project uses (they created it). For a small to medium project with the 32 needs of a "simple GitHub" interface all in one package, I do not think 33 there's any other software that can beat it really. 34 35 For my needs, well, I only really need the VCS so ... maybe on another 36 occasion. 37 38 And then there's mercurial. This is another one that impressed me. It 39 has a super clean UI, it's fast and easy to work with if you know any 40 other VCS (and I think is perfect for people that has never used one). 41 42 It has a built in http read only interface and, for the rest is pretty 43 similar to git from the user point of view. As drawbacks, maybe the 44 network performance is not that great (but usually that is not a 45 problem for me, as I do most of my work locally and then push or pull 46 occasionally to sync with my central repo), and also Python 2.7 ... 47 yeah, that. They are working on porting it to Python3, but well, it 48 seems it will take a while. 49 50 So I decided to give it a try on 2 repos I use regularly. The one that 51 keeps track of this phlog (+ gopherhole + website), and another one with 52 private dotfiles and scripts that I keep separated from my [public 53 dotfiles repo][7]. 54 55 Another good candidate is my [vimwiki][8] repo. We'll see. 56 57 I may make public the one that tracks this using it's built in http 58 interface if I ever figure it how to make it run on a chroot (my server 59 runs OpenBSD and I would like to follow their policy of chrooting 60 anything web). 61 62 As usual, if anyone reads this and has any comments, send them to 63 <comments@e1e0.net> 64 65 :wq 66 67 ------------------------------------------------------------------------ 68 69 [1]: https://en.wikipedia.org/wiki/Version_control 70 [2]: https://git-scm.com/ 71 [3]: https://fossil-scm.org/ 72 [4]: https://www.mercurial-scm.org/ 73 [5]: http://www.nongnu.org/cvs/ 74 [6]: https://sqlite.org/ 75 [7]: https://git.e1e0.net/dotfiles/ 76 [8]: http://vimwiki.github.io/