On Jul 13, 2018, at 9:39 AM, Andy Goth <andrew.m.g...@gmail.com> wrote: > > On 07/11/18 16:10, Warren Young wrote: >> On Jul 10, 2018, at 8:58 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: >>> I thought it interesting that he spoke of merging as if it were a >>> distinct task in the workflow for adding a file. >> Did he check the file in on a branch and then merge it down to trunk? > > No he did not, but after reading my email to this list, he told me he said > merge because his git habit is to always work on a branch. I took that as an > opening to discuss the difference between git and Fossil branches.
In my public Fossil projects, the policy is that any checkin that is potentially destabilizing should be done on a branch, as should any coherent line of work that will require multiple checkins to complete. Trunk is ideally stable at all times, so as long as a checkin is self-contained and trunk remains as stable as before, direct checkins to trunk are fine. The rule requiring multiple-checkin lines of work to be on a branch doesn’t apply if each step along the way is self-contained and doesn’t destabilize trunk. So for example, work on a new script that requires multiple checkins can be done directly on the trunk as long as that script isn’t called by something other developers run frequently, such as the build system. This is an ideal not always achieved, but since there are consequences to not achieving it, over time developers on the project learn to be thoughtful about checking in directly to trunk. As a result of this policy, a new developer’s first checkin might well be on a branch, either because they’re going off on a new development tangent that will take them multiple checkins to finish, or because they’re still feeling tentative about their work, so they want one of the old hands to okay it before merging it to trunk. >> once publicized, a URL should never die > > our project is private In that case, I think it’s perfectly fine to delete these docs unceremoniously, as needed. > Only the front page and the wiki are public, and I've been migrating most of > our wiki stuff to the private areas because in my opinion it gives away too > much secret sauce. Probably not worth shunning wiki history though. Until one of the publicly-hosted “private” repository services is designed to and audited at the same level we use for VPNs, I’m unwilling to trust any of them. If your codeveloper is remote from you, I recommend that you relieve Fossil of the burden of providing the capital-S security for your project, laying that off on SSH or some VPN technology you trust instead. I’m not a black hat, so I haven’t tried to break Fossil’s permission system, but I only depend on it about as much as a door lock: it’s a thing to prevent civilized users from doing things we’d rather they not do. If I decide that a Fossil repository’s contents shouldn’t be visible to the public, I don’t put it on a publicly-accessible server, period. If you want to treat Fossil as a CMS for your public web site, I’d run it as a separate instance, with only those things you’re willing to publicize going out to it. For off-site backups of private repositories, I use the attached script. Technically it violates my rule not to put private data on publicly-accessible servers, but I trust AES, gpg, and my key to turn that repository data into a blob of useless noise to anyone without the key. There are several things you need to adjust in the script to use it: 1. The “pass” value on line 3. I use a generated random blob, but it could be a passphrase or similar. If it’s short enough to be called a password, run it through an entropy calculator: if your password gives less than 256 bits of entropy, you’re artificially weakening the encryption. 2. The repository list used in the “for” loop. 3. The “bdir” output directory. It could be something like ~/Dropbox/Fossils, or it could be a directory sync’d elsewhere by a command that you append to the script. I’ve come to this position not out of specific distrust over Fossil’s security design, but out of deep respect for what the ‘hats can do once they’re feeling motivated to attack something. SSH, VPNs, GPG, and AES have all been pounded on by the ‘hats sufficiently long and hard that I trust those technologies implicitly, as long as the best practices are followed. Since Fossil hasn’t attracted that sort of attention yet, I feel that my idea of “best practice” for Fossil security is just my opinion and worth only as much as that realization implies. While I’m pontificating on paranoia, I’ll say that a VPN is only a VPN if it is truly private. Technologies which fail to provide the “P” are not VPNs. Hence, PPTP is not a VPN, in my view: https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security > I'll have to leave it to him to make his own macOS binary Here’s the current trunk, built a couple of hours ago on a macOS 10.13.6 system: https://drive.google.com/open?id=1Pl3XQAVtJOv-LXTlZmPyP_tkNML9YJDa It appears to be linked to the Homebrew version of OpenSSL, so he’ll need to have that installed to run it. I won’t be upset if you decide not to download and run that, having endured my lecture on paranoia. I tell you it’s a safe binary, but who am I to certify that? >> By giving him a different command to back out, he may now be afraid to >> use “fossil sync” entirely. > > I already told him he should never need to use "fossil sync" manually. There are two fairly common cases where he may need to sync manually: 1. Fossil UI -> edit wiki. 2. Ditto, but with tickets. On saving the ticket/wiki changes, the local Fossil instance won’t autosync to the remote instance, even if it’s available and autosync is enabled. I also do manual syncs when taking a laptop that had autosync disabled back into the warm wifi bath after re-enabling autosync. >> We shall wee. > > Nice typo. ;^) We did, and we thank you for your concern over our urological health. :)
backup-fossils
Description: Binary data
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
