On Oct 30, 2015, at 2:37 PM, Scott Doctor <sc...@scottdoctor.com> wrote: > > Embarcadero RAD Studio incorporates Git, Mercurial, and Subversion into the > IDE.
Yes, it would be nicer if more IDEs had Fossil plugins. That said, I always have a terminal window up, cd’d into the project, so even when using something like Visual Studio, a quick Alt-Tab and “f ci” is no trouble. > What I meant was I end up spending much time trying to get the tools to do > what I want it to do versus how it wants to do it. Examples, please. > I fully see the utility of a VCS on collaborative projects. My project is for > my own research work and is not used by any clients. I am also the only one > who plays with my code. So some of the utility needed for collaborative > efforts becomes cumbersome for a solo project. I’ve used Fossil for solo work, and it’s still greatly preferable to the alternatives. In addition to drh’s points: 1. Multi-machine sync. I view laptop computers as a compromise, something to use when you can’t use a desktop computer. Since I can’t always restrict my coding activities to a single location, that means I occasionally have to sync my work to a laptop, or between two different desktops. Fossil does that, and does so in a much easier fashion than other DVCSes. (f all sync!) Dropbox and such are poor alternatives, since I don’t want my object files and executables sync’d to the cloud, and I don’t want to see a throbby little icon in the corner of my vision every time I save a file. I want to batch my syncs up, do them on my schedule, and send only source files, no object files. 2. Deduplication. Your versioning scheme requires needless copies of unchanged files. Fossil only stores what is needful, which means I can download the entire history of a project without even thinking about it. I suspect if you checked all the past versions of your system into a single Fossil repo, it would be about the size of 3 or 4 of your existing “whole project” archives. So, you’ve got a choice: in the same bandwidth/disk space as a handful of archives, you can have all the history, or just the most recent history. 3. Comments. I used to keep a paper log book of the things I was working on, so I could go back later and figure out what I did and why. Searching the comment stream of a Fossil timeline is far better. 4. Wiki and technotes. When I have too much to say to fit into a comment box, I can write an article about it, which gets sync’d to my various development machines. 5. Tickets. I used to keep a Wishlist or TODO file in each project, containing the things I wanted to do next. Tickets do that better, since you can prioritize them, search them, reference them from checkin comments and wiki articles, etc. You can have my Fossil after I *become* a fossil. :) > Before I start writing a new function, process, or other modification, I > create a sub-folder of my backup folder which are numbered in sequence. The > file system applies a date to the creation time of the folder which > identifies when the backup was made. I then simply copy my entire project > folder into the backup folder. This is easier than “fossil ci --tag v1.2.3” or “fossil ci --branch expermental-feature”? For solo projects, branch merging is nearly trivial, since the chances of colliding changes is near-zero. And if you do find yourself changing the same area of code on two different branches, it’s easy to say something like “f merge trunk” from the branch to sync changes made in the trunk into the experimental branch, so you can overwrite some of the recent trunk changes without confusing Fossil. > If I break the code, or decide to revert the changes, I restore the project > from the desired backup folder. That’s easier than “f up trunk” to toss a bad branch, or “f revert” to toss uncommitted changes, or “f up v1.2.3” to roll back to a prior stable version? > I am finding them just as cumbersome of a process with an added layer of > things to go wrong. I rarely find Fossil failing in ways I can’t understand. And every time it has happened, someone on the list has explained it. (For instance, my recent thread about how to clip off a a branch via the command line when the UI can’t do it because it was created empty, something Fossil can’t do, but which apparently CVS or SVN can, so it got into my Fossil tree when I converted.) This as compared to the sentiment in the XKCD comment, where if Git screws up, it’s often simpler to just toss the checkout and start over than try to recover. Another example is the “double tip” stuff we’ve seen on the list. Fossil now diagnoses that problem, allowing you to correct it before it becomes a serious problem. For the most part, Fossil obeys the principle of least astonishment. Maybe that’s because I’ve been conditioned by ~15 years of CVS and SVN, so I know how VCSses are supposed to work. If so, this is where we need your concrete examples. How is Fossil astonishing you, in a bad way? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
