[fossil-users] status of TODO list (was Re: comparison with Git)
On Fri, 14 Sep 2012 07:54:27 -0400 Richard Hipp d...@sqlite.org wrote: The goal of Fossil is to require fewer brain-cycles. Fossil isn't perfect. I'm sure there are things that can be done so that it requires less effort. But I believe it is better than monotone, bzr, or hg, and way better than git. Recently I was considering to switch from Archlinux to Frugalware and in order to be able to help the project I decided to learn Git. Went thorugh Pro Git book and started to use it daily, although very basic feature set and I must say that some concepts look nice in comparison with e.g. hg (gave up on monotone bzr earlier). However, now I ended up with Free(PC)BSD, using ZFS instead of (anticipated) btrfs and the key word(s) is simplicity (stability), which brings me again to Fossil. :-) 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. When we might expect to get it? * full text search Any work on this one? * Partial commit of a modified file This one would be very nice... Besides the above three items, I wonder what do you think (this item was already mentioned before in few occasions) about ability to select which branches to push and/or ability to shun selected private branches? 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. What is suggested workflow for it in Fossil? (in Git it's very natural to create and dispose such branches with a short life-span.) Sincerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. 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
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
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
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
Richard Hipp escribió: On Sat, Oct 13, 2012 at 4:06 AM, Gour g...@atmarama.net mailto: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. I'm mostly an outsider (and very, very happy user of Fossil in its current state), so take my coment with a pinch of salt, but: Doesn't strike you as odd this sudden influx of requests of make Fossil more like Git!? It's almost as if disgruntled users of Git want to have a Git-like program, even importing their defects (or, let's be generous, differences in design philosophy), but with a more friendly interface. No matter if this bothers or causes some worry or complication to current Fossil users or even to its implementors: we want our Git-lite program so we can have all the things we like and not have the Git manual tattooed to our inner eyelids! That's the generous hypothesis. The paranoid one is that Git promoters really want to nullify all differences between Git and Fossil and then say: See? Fossil does the same that Git does! And we have Github! And the community! And etcetera!. I like Richard's attitude of Fossil is there to scratch my own itches and it's doing fine like it is now. I wouldn't like to have its CLI turned into a unmanageable monstrosity (at the very least) or to compromise the integrity of the Fossil file format because of people in love Fossil's simplicity but who don't want to get rid of their old Git thinking habits. -- o-= Marcelo =-o ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
On Sat, 13 Oct 2012 09:27:38 -0400 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. Deleting content from a repository is scary. A bug in the delete logic could easily cause loss of information. [excellent explanation elided] Hence, I am reluctant implement uncommit on a repository. [...] Brainstorm: A potential work-around How about a second one? Uncommit limited to the last commit, for the 'oops' commits where your fingers got ahead of your brains, or you realized seconds after making it that one of the globs included files you didn't commit, and so on. This is about the only kind of uncommit I ever want. The repo would keep track of the last commit, and allow it to be removed. Any non-commit commands that made removing it dangerous would NULL that out, so you could no longer remove it. Syncing remote repositories makes removes interesting. I believe that the git tutorials recommend not removing any commit that's been pushed, because - well, it just screws things up. I think this limited version might be made safe: - uncommit after a push is ok - syncing a removal only works if the commit is removable on the receiving repo. - failing to sync a removal is a warning, but doesn't stop the rest of the sync. In this case, the removed commit eventually comes back everywhere. On the other hand, you could make push clear the removable commit, and have uncommit simply not available if autosync is on. I suspect you want that for most forms of uncommit in any case. Your proposed workaround has similar issues. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
[Default] On Sat, 13 Oct 2012 11:45:29 -0300, Richie Adler richiead...@gmail.com wrote: I like Richard's attitude of Fossil is there to scratch my own itches and it's doing fine like it is now. +1 I wouldn't like to have its CLI turned into a unmanageable monstrosity (at the very least) or to compromise the integrity of the Fossil file format because of people in love Fossil's simplicity but who don't want to get rid of their old Git thinking habits. Fossil is almost getting too complicated for me already ;) Perhaps Gour can use fossil stash to get the functionality he needs? -- Groet, Cordialement, Pozdrawiam, Regards, Kees Nuyt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
On 13 October 2012 16:45, Richie Adler richiead...@gmail.com wrote: Richard Hipp escribió: On Sat, Oct 13, 2012 at 4:06 AM, Gour g...@atmarama.net mailto: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. I'm mostly an outsider (and very, very happy user of Fossil in its current state), so take my coment with a pinch of salt, but: Doesn't strike you as odd this sudden influx of requests of make Fossil more like Git!? It's almost as if disgruntled users of Git want to have a Git-like program, even importing their defects (or, let's be generous, differences in design philosophy), but with a more friendly interface. No matter if this bothers or causes some worry or complication to current Fossil users or even to its implementors: we want our Git-lite program so we can have all the things we like and not have the Git manual tattooed to our inner eyelids! No, it's not odd. Both fossil and git have their strengths and shortcomings. Of course, some are inherent in the design but others are just lack of a script to perform a function similar to the function of the other system (eg. rebase). Some would perhaps require some modification to fossil or burying fossil in a pile of script wrappers (eg. commit hooks). While writing that script is obviously possible locally that functionality stays local and non-portable. Some feature requests might come from the lack of understanding of existing features but others are calling for features that are sorely missing in fossil however you look at it. Of course, you might not need them for your project (yet) but that does not mean they are useless. Thanks Michal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
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
Re: [fossil-users] status of TODO list (was Re: comparison with Git)
On Sat, 13 Oct 2012 10:05:00 -0500 Mike Meyer m...@mired.org wrote: Uncommit limited to the last commit, for the 'oops' commits where your fingers got ahead of your brains, or you realized seconds after making it that one of the globs included files you didn't commit, and so on. This is about the only kind of uncommit I ever want. +1 I'm not the one suggesting to have rebase in Fossil. ;) Syncing remote repositories makes removes interesting. I believe that the git tutorials recommend not removing any commit that's been pushed, because - well, it just screws things up. I think this limited version might be made safe: RIght. Rebase can be safely used only locally...as soon as patches/changes escapes into wild world, forget it...that is/was truth since very beginning of darcs and DVCS. Sincerely, Gour -- Everyone is forced to act helplessly according to the qualities he has acquired from the modes of material nature; therefore no one can refrain from doing something, not even for a moment. 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
