On 30 October 2015 at 23:19, Warren Young <[email protected]> wrote: > On Oct 30, 2015, at 2:37 PM, Scott Doctor <[email protected]> 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.
rsync .. > > 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. But to understand how it failed you have to be familiar with the concepts of VCS in general and fossil in particular. Sure VCS commands are no more difficult than filesystem manipulation commands. The thing is that your project is already in files so you have to understand the filesystem concept and its manipulation anyway whereas with a VCS you have to understand new set of concepts, features, limitations, and commands that give you access to those. Subtly different for each VCS, no less. > > (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. Seriously, how do you screw up like this with git? Unless you delete .git your checkout is always in well defined state. The only time I had a problem was when the Linux repo was moved to a different hosting and rolled back to some earlier point in time due to some problem or another. I was missing some artifacts and could not update branches that relied on the now gone repo. This should not actually be a problem in theory, right? Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
