On Sat, 13 Oct 2012 09:27:38 -0400 Richard Hipp <d...@sqlite.org> wrote:
> Deleting content from a repository is scary. A bug in the delete > logic could easily cause loss of information. Indeed. > 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. I fully agree with your decision here. > 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". I know about that one. > 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. Very interesting idea. > 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. It sound cool...I believe that hg also got some new features called 'phases' or so. > 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. It would be wonderful. Thank you very much for it. > 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. /me uses raid-1 :-) Sincerely, Gour -- >From wherever the mind wanders due to its flickering and unsteady nature, one must certainly withdraw it and bring it back under the control of the self. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
