Re: [fossil-users] Changing Fossil's Style (Skins) - A tutorial
On Sun, May 22, 2011 at 6:17 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > I personally would be interested in any advancements you make with > javascript, or any other improvements from the basic fossil ui. > Me as well. If you extend the GoCo theme to include diff highlighting (a list member posted an easy-to-use JS script for this), i will immediately import it into my sites :). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Changing Fossil's Style (Skins) - A tutorial
Thanks for the writeup Tomek. I personally would be interested in any advancements you make with javascript, or any other improvements from the basic fossil ui. Thanks, Ambrose On Mon, May 23, 2011 at 12:06 AM, Tomek Kott wrote: > Hi folks, > > Being new to Fossil, I decided to write up a blog post on how to change the > style of Fossil to something approximating Google code - with most of the > hard styling work done by Dmitry @ CodingRobots. You can find the post here: > http://kott.fm/tomek/2011/05/22/setting-fossil-up-with-style/. > > I just wanted to start giving back to the Fossil community with a tutorial > or two (I'm planning one on javascript enabled code highlighting / diff > highlighting next. If this kind of message to the list is in bad taste, > please let me know and I will not post anything similar in the future! I > haven't been around long enough to know the culture of the list. > > Thanks! > > Tomek > > ___ > 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
[fossil-users] Changing Fossil's Style (Skins) - A tutorial
Hi folks, Being new to Fossil, I decided to write up a blog post on how to change the style of Fossil to something approximating Google code - with most of the hard styling work done by Dmitry @ CodingRobots. You can find the post here: http://kott.fm/tomek/2011/05/22/setting-fossil-up-with-style/. I just wanted to start giving back to the Fossil community with a tutorial or two (I'm planning one on javascript enabled code highlighting / diff highlighting next. If this kind of message to the list is in bad taste, please let me know and I will not post anything similar in the future! I haven't been around long enough to know the culture of the list. Thanks! Tomek ___ 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] WHY IS FOSSIL REMOVING ALL MY CODE!
Richard Hipp schrieb: (...) > >>> Does anybody have any other suggestions on how to prevent the lose > >>> of uncommitted work? > >> > >> Maybe not suggestion to prevent losing of uncommitted work, but I'm > >> thinking about using 'stash' in such situation. > > Perhaps Fossil could do this automatically. Whenever an 'update' would > change any locally modified file, Fossil could stash the changes away > first and inform the user. > > That's sort of what "fossil undo" does. Except it only stores the most > recent change. You are suggesting an "auto-stash" that keeps backups at > each change, and stores them in a visible place such as the stash. An > interesting idea... But only if an update would modify local uncommitted changes, I think. So if I commit every time before I update, no auto-stash would be necessary. > Would we purge the auto-stash on a commit? Or just let it grow until > the user manually purged it? No, I feel it should not purge the auto-stash on commit. It would be safer, if it has to be deleted manually. Then I have explicitely to choose that I do not those changes anymore. Fossil cannot know my intentions. And tracking all of my actions to be sure that the auto-stashed changes were really re-introduced into my working copy would be a ehrm tricky task to implement. What Fossil could do is to warn on every commit I do until those auto-stashes are dropped again (perhaps with asking for permission to proceed with current checkin in face of auto-stashes). Ciao, chi :-) ___ 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] WHY IS FOSSIL REMOVING ALL MY CODE!
On May 22, 2011, at 04:20 , Ron Wilson wrote: > Doing a fossil update should never delete uncommitted changed files. > Zed's post implies this happened. No, his post states that he killed his uncommitted work with fossil revert. And due to earlier errors fossil undo didn't help. Kind regards, Remigiusz Modrzejewski ___ 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] WHY IS FOSSIL REMOVING ALL MY CODE!
On Sun, May 22, 2011 at 12:04 AM, chi wrote: > > > Ron Wilson schrieb: > > On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa > wrote: > > > >> On Sat, 21 May 2011 14:32:34 -0400 > >> Richard Hipp wrote: > >> > >>> Does anybody have any other suggestions on how to prevent the lose > >>> of uncommitted work? > >> > >> Maybe not suggestion to prevent losing of uncommitted work, but I'm > >> thinking about using 'stash' in such situation. > > Perhaps Fossil could do this automatically. Whenever an 'update' would > change any locally modified file, Fossil could stash the changes away > first and inform the user. > That's sort of what "fossil undo" does. Except it only stores the most recent change. You are suggesting an "auto-stash" that keeps backups at each change, and stores them in a visible place such as the stash. An interesting idea... Would we purge the auto-stash on a commit? Or just let it grow until the user manually purged it? -- 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] WHY IS FOSSIL REMOVING ALL MY CODE!
On Sat, May 21, 2011 at 10:20 PM, Ron Wilson wrote: > On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa > wrote: > > On Sat, 21 May 2011 14:32:34 -0400 > > Richard Hipp wrote: > >> Does anybody have any other suggestions on how to prevent the lose > >> of uncommitted work? > > > > Maybe not suggestion to prevent losing of uncommitted work, but I'm > > thinking about using 'stash' in such situation. > > Doing a fossil update should never delete uncommitted changed files. > Zed's post implies this happened. > Using Zed's repo, I think I have reconstructed exactly what happened. When he entered "fossil update" because of bug in the logic that figures out what check-in to update to, it tried to update to which contains no files. So it dutifully went through and removed all the current check-in files. But: any files that had been edited locally would not have been removed. They would have been flagged as "conflicts" and left unchanged. So after the malfunctioning update, Zed would have had all his files removed, except for those he had edited. So, even though Fossil malfunctioned, safety mechanisms in Fossil prevented work from being lost. So far... What happened next is less clear. But some additional commands were entered, including "fossil update trunk" and "fossil revert". The exact sequence of commands is unknown to me and probably forgotten by Zed at this point too. But whatever they were, they managed to delete his edits. Note in particular that the "revert" command is a request for Fossil to delete your edits, so it was doing exactly what it was asked to do. Note further "fossil revert" can be reversed using "fossil undo", in case you happen to revert accidentally. But, unfortunately, there is only one level of "fossil undo" so if you do something else after the "fossil revert", your changes are lost permanently. To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing. > > That said. I routinely backup my projects so I am far less likely to > loose more than a day's work. This is not a matter of not trusting a > given VCS, whether Fossil, git, some expensive commercial VCS or any > other, it is simply a matter of prudence. Better to have multiple > backup systems as this helps mitigate the effects of failures in any > one system. > > I've never lost uncommitted work due to Fossil, in four years of heavy use. But I have certainly lost work due to an ill-conceived "rm" or "cp". More than once I have done an "rm" with some wildcard in the argument, only to realize, milliseconds after pressing "Enter", that I had just trashed everything I had done so far that day. It's a bad feeling. -- 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] Versionable settings, empty dirs (and symlinks?)
On 21 May 2011, at 18:29, Ben Summers wrote: > > As a first step, I've made an experimental patch to see what the reaction is, > and whether the approach is worth tidying up: > ... > * "Versionable" settings > ... > * empty-dirs setting I've created a branch which very roughly implements these changes: http://fossil-scm.org/index.html/timeline?r=versionable-settings I wouldn't use it for real work, consider it a proof-of-concept for now. If there's an indication it's worth doing and some feedback on whether the approach is correct, I'll write a list of everything that's needed to make it production ready and get on with it. Regarding the symlinks, after reading the mailing list thread about them, I'm less enthusiastic. I will take a look at the code and see what needs to be done before merging. Ben -- http://bens.me.uk/ ___ 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] An "ease of use" issue
Hello, > addition of an "auto-remove" or similar option, which would tell fossil to > automatically perform a "fossil rm" on any file missing in this manner. > This is a bit dangerous, so it should be an option which is normally 'false' > I would say this is not only a bit dangerous, but very dangerous. It is easy to run a command that will inadvertently delete files, not notice it, and do a “fossil commit”. OK, old versions are still in the repository but this is annoying. replace "no such file" with something like "It looks like the file > 'somefile' has been removed. Do you want fossil to remove it from the > repository?" (unless 'auto-remove' is selected, when it would just do that) > I would rather prefer having one message for multiple missing files, instead of N messages for N files. For example, list the missing files, and then say: “those files seem to be missing. Do you want to remove them in the current branch? don't show SQLITE messages unless the user wants to see them, since they are > more frightening than helpful for most users. It would still be useful in some user runs into an obscure bug, and normally they should not show up. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
