Hi, I too, am a very grateful Fossil user. However, I am both teased and puzzled by... "New information is added but old information is never destroyed. (Ignore the whole "shun" mechanism for now...)"
I tend to agree with the philosophy of retaining working doodles and tinkerings of code. But, an obvious and egregious error of adding multiple files or spam and committing them and then not finding them for several commits later should have an approved method to erase entirely. Case in point: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg03234.html Imagine without scripts or reverting to an earlier backup of the repo, how a user must shun 100's of binary files via locating their SHA1 hashes? And then execute a fossil rebuild --vacuum. So I am teased with the potential of a temporary workspace that could effect a permanency of commit removal with 1 or 2 commands. My recent hassle... developer 2: fossil add c:\repo\subfolder\*.* fossil commit ;<-- I want to be able to permanently remove this commit. fossil pull remoterepo fossil update fossil push remoterepo remoterepo now contains 100's of megs of binary content by mistake. developer 1: fossil commit fossil pull remoterepo fossil update Now both developers have overgrown local repos. Thanks for Fossil. On Sat, Oct 13, 2012 at 9:27 AM, Richard Hipp <d...@sqlite.org> wrote: > On Sat, Oct 13, 2012 at 4:06 AM, Gour <g...@atmarama.net> wrote: >> >> >> Now, I'm curious about some of the items from the TODO list >> (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List) >> and their status: >> >> * Uncommit >> >> All what I need is simple mechanism to quickly 'fix' some wrong commits >> without tinkering deep into the commit history. >> >> ... > > >> >> The idea is when one creates short-lived feature branch, experiment >> with it a bit, and when it's ready simply commits to the 'main' branch >> not wanting to keep it any longer. > > > Deleting content from a repository is scary. A bug in the delete logic > could easily cause loss of information. > > The underlying storage of a Fossil repository is an unordered bag of > artifacts. Each artifact is identified by its SHA1 hash. Some artifacts > have special meaning (check-in manifests, wiki pages, ticket changes, etc.) > while others are content (files that have been checked in, or attachments to > tickets or wiki pages). The same artifact can be used more than once. For > example, if you change a file from X to Y on check-in A then later on > check-in B you change the file back to X, there is only a single X artifact > - it just happens to be used by both the pre-A check-ins and by B. > > So, if you do an "uncommit" or B or if you delete a branch containing B, the > code that goes through and deletes the surplus artifacts needs to be very > careful not to delete artifact X. Otherwise, the pre-A check-ins would go > corrupt. > > We put a lot of trust in Fossil at the moment because it is an append-only > database. New information is added but old information is never destroyed. > (Ignore the whole "shun" mechanism for now...) And steps are taken to > ensure that the compression and encoding is reversible. (See > http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for addition > information.) If we add the ability to delete a branch, suddenly the design > of Fossil becomes much more brittle, and any tiny bug that gets introduced > has the potential to trash a repository containing years of irreplaceable > work. > > Hence, I am reluctant implement uncommit on a repository. > > Note that if you just want to change a check-in comment, that can be done by > adding a correction using the web interface. Adding a corrected check-in > comment does not delete content. The original check-in comment is preserved > and a new correction is added the user interface is smart enough to use the > correction rather than the original. So editing a check-in comment does not > involve deleting from the repository and is thus considered "safe". > > Brainstorm: A potential work-around > > Fossil actually uses multiple databases. Of interest to us are (1) the > repository database and (2) the ".fslckout" database which is specific to an > individual checkout of that repository. The repository is persistent and > long-lasting and needs to be "safe". The check-out database lasts only for > the lifetime of a local tree. > > Artifacts are stored in the repository. The repository is what needs to be > protected by being append only. But suppose we also allowed artifacts to be > stored in the check-out database. Check-ins or branches that are considered > "experimental" or "local" could be stored in the check-out database. When > you get ready to "persist" these check-ins, they can be moved into the > repository. But as long as they have not been persisted, artifacts in the > check-out database can be freely deleted. > > This approach would mean that the repository database is still append-only > and thus "safe". But by providing a non-shared staging area in the > check-out database, you get the ability to back out or modify recent > changes. > > The downside is that your check-ins do not get backed up to the cloud until > you persist them. If your local disk crashes, you lose work. > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
