Only with a fair amount of pain (basically, `fossil merge --cherrypick`, then `fossil purge` for the original branch).
That's because mutable history is not part of the normal workflow that's being encouraged by fossil. You will see that "wrong" branches are simply tagged as "mistake" in the Fossil or SQLite repositories [1]. Branches are merged rather than rebased and the web UI is built around the assumption of having branches as distinct, named entities, rather than having them coalesced into the mainline. Fossil also uses autosync by default, where commits are automatically pushed to the master repository, which further discourages changing history.
If you simply want a local checkpointing mechanism (where you snapshot revisions at intervals with the intent to later combine them into a single meaningful commit), that's what private branches or `fossil stash snapshot` are for. Commit metadata, such as commit messages, can be changed later, but the edits leave an audit trail.
A major reason here is specifically that changes are supposed to always have an audit trail.
Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that.
You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at.
It is nice that additional things besides source can be tracked, bug requests for instance.
> Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that.
This is probably in reference to this old message by Richard D. Hipp [1]:
"Fossil, in contrast, is designed to remember everything. Fossil was
specifically designed to support the DO-178B inspired development
process used by SQLite, with few developers and a complete and
immutable audit trail for all inputs."
DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems.
svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
It also comes from how git is used. With git small commits are possible. It's nice to be able to manage those and build larger, coherent ones. Also, because of the distributed nature, sometimes rewriting is useful to fix mistakes.
However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.
Ex: "But the real reason for doing it is that it was a small amount of work that moved Objective-C forward, which allowed the compiler and language team to focus on Swift because Swift was a very large amount of work. " http://atp.fm/205-chris-lattner-interview-transcript/
If you're compiling a package with lots of functions in it, Go can now have multiple cores working concurrently on (much of the work of) compiling different functions.
Go would already work on more than one _package_ at once, using multiple processes, which helped big builds covering many packages (think building Juju, Kubernetes, or Docker from scratch). The benefit here is in the common situation where you make a change in one package and recompile: more of your cores can be put to use getting that package rebuilt.
This is a changelist for review, after preliminary work to move state out of globals, etc. If you click "Show more" it will show much more, including discussion of the internals and wall- and CPU-time benchmark results.
The Go compiler is already much faster than your typical C and C++ compiler.
Now the compilation step, which is done on those projects via make -j4, can be done natively in the go compiler within modules by itself, compiling functions in one module in parallel.
Modules itself would be already parallelizable by make -j4, but since go build is its own tool independent of make,
they re-invented it by themselves. It's significantly faster than make already, but comes with maintenance costs. go build is much stricter than traditional dependency systems.
It's not really significant at all. Compile-times of bigger modules will get a bit faster, such as e.g. with zapcc, which got C++ compile times 50% faster by caching.
This app looks fantastic! I'm impressed by the various photos posted on Primitive's twitter account: https://twitter.com/PrimitivePic
On a separate note @fogleman, would be able to talk a little about how you architected the app? I'm curious about how you've set up Objective-C communication with Go using NSTask and NSPipe.
