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
