[fossil-users] wiki pages
Hi, This is a quick question: Is it possible to rename a wiki page. Let's say I've change my mind after naming it. Is it possible to rename or delete a page? Thanks Erlis ___ 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] wiki pages
Clear enough, Thank you very much for answering... that fast!! Wonderful product by the way!! On Fri, Dec 2, 2011 at 1:38 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Dec 2, 2011 at 1:33 PM, Erlis Vidal er...@erlisvidal.com wrote: Hi, This is a quick question: Is it possible to rename a wiki page. Let's say I've change my mind after naming it. Is it possible to rename or delete a page? Fossil does not let you rewrite history. So if you historically had a wiki page named xyz then that page will exist forever. You can create a new, replacement page with a different name. And you can remove all content from the latest version of xyz to indicate that it is no longer an active page. But you cannot remove historical contents of wiki pages (except via the shun mechanism, which is a different topic). Fossil follows accounting rules: You never erase. If a mistake is found, instead of erasing, you enter a correction. Always preserve the audit trail. Thanks Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] GUI client for Windows?
On Thu, Oct 6, 2011 at 9:04 AM, Stephan Beal sgb...@googlemail.com wrote: There are some (a small few) features which we can't provide over JSON without some major workarounds and/or caveats. Namely binary data (which JSON cannot natively support), which means committing binary files this way will not be implemented, at least initially, and will have some significant limitations if it is ever implemented (e.g. the RAM cost of committing base64-encoded binary content in JSON form would be roughly 2-3x the original content size, so it would likely fail miserably for those people who think that having files 500MB in their repo is somehow a good idea). Hi Stephan, Do you know about protocol buffers. I'm asking because I didn't know about them since recently. http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html Could this help in order to allow binaries and improve the serialization performance? --Erlis ___ 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] GUI client for Windows?
Take a look to protocol buffers. The implementation is not restricted only to java, c++, python. Other people are adding more languages... this gives you kind of portability -Erlis On Thu, Oct 6, 2011 at 11:19 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal er...@erlisvidal.com wrote: Do you know about protocol buffers. I'm asking because I didn't know about them since recently. http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html Never heard of them. Thanks for the link :). Could this help in order to allow binaries and improve the serialization performance? No idea just yet :). But i will take a look at that. One thing to remember is that JSON != JavaScript, meaning that if we include ANY algorithms for binary data, ALL clients which want to use fossil/json HAVE to implement those algorithms. e.g. if we decide on base64, ALL client languages have to support it if they want to use those features of the API. Because of this, i would like to stick non-formatted data where possible, falling back to non-JSON-specified algos only when absolutely necessary. My current thinking on binary is that it probably should be encoded the same way one encodes binary in sqlite: X'aabbccdd', i.e. a simple list of hex value pairs. The down-side is that it literally doubles the size, which means that those fossil users which version-control 500MB files (which is insane, IMO, but people do it) will have a memory cost of approximately 3x that file's size when turning the artifact into JSON (1x for the original copy and 2x for the X'...' encoding, and possibly even more for the underlying sqlite statement to/from that data). Try to commit a 2GB file and you can't - your machine (or the remote fossil server) will die with an OOM error. The up-side is that en/decoding it is absolutely trivial - even an absolute beginner could figure out how to encode/decode it and it can be done in any language which supports binary data (e.g. NOT in shell code, but in JS/Python/Perl/PHP/Java, etc). -- - 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 ___ 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] git vs fossil again (was: why you should not shun)
I get the two points of view and I'm not saying one is right or wrong. Modifying the history versus keeping everything as indeed happens (the history after all) Yesterday I was confused because I though the shun was done in the big file, but indeed the shun was done in the commit also... will that modify the history? I got the feeling that shunning a commit will change the history... not sure about it, you tell me. If I'm working under the premisses that the history cannot be changed, is shunning a commit (in case it change the history) a valid operation? Maybe fossil shouldn't allow to shun a commit, just individual files, if you really want to shun all files in that commit, then fossil could allow that, (shun --all) but that shouldn't touch ever the commit artifact.. Regards, Erlis On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 5 Oct 2011 11:12:31 -0700 Mike Meyer m...@mired.org wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Correct. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. I'm not entirely convinced. Look at the workflow used by the Git team: they maintain the set of well known branches, of which the only one, named pu (proposed updates), is allowed to be rebased and that's actually what happens with it each time the new release is made--it's cut from the master afresh. I mean, while every committer has `git rebase` at their disposal and knows how it works this does not mean they go off and break the repository with rebases. So your point is only really valid when the project is run by a bunch of idiots or complete newbies. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Git handles it from the opposite direction by having the reflog. But I find this point to be valid, yes, safety nets are a must when it comes to handling precious data. BTW I'm a fan of `fossil undo` for that matter. Bottom line: while more features may imply more powerful, it doesn't imply better. Moot point. I really miss Git's index and `git add --patch` here. Is Fossil better than Git in this respect by not having those more features? Surely it completely is in the eye of the beholder. ___ 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
Re: [fossil-users] Why you should not shun
Before I ask I would like to see the *shun* documentation, I'm not able to find it here http://www.sqlite.org/debug1/help* *nor the command *fossil help shun* helps. Thanks Erlis On Tue, Oct 4, 2011 at 2:50 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 4, 2011 at 8:39 PM, v...@lavabit.com wrote: Fossil makes a great mini CMS for hosting a small site. Built in wiki makes it sweet. I think it is also possible to have something like a forum, with wiki pages used as categories and tickets + comments to them used as topics. Side note: the JSON API makes it possible to use wikis (and soon tickets) from within your own custom HTML interface, meaning that it can be used as a wiki back-end independently of the version control features (but automatically inheriting those features, should you need to back-rev a wiki page or whatever). Additionally, it allows clients to use their own wiki formats if they like (because it can serve the content in raw or fossil-parsed forms) provided that the client have a client-side renderer for the content. Creating a demo of such an app is on my todo list. i have a wiki management app (implemented in HTML+JS) which uses a different (but conceptually similar) back-end and it should not be difficult to port to a fossil back-end. The JSON API has all the features needed for this but i would first like to make more progress on the artifact fetching APIs so that it will be possible (client-side) to look through historical versions of pages. A _very_ rough prototype of this idea can be seen here: http://fossil.wanderinghorse.net/repos/fossil-sgb/json/wiki-editor.html but you cannot save from that demo page unless you crack my password ;). -- - 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 ___ 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 you should not shun
I have fossil documentations bookmarked everywhere, I'll be fixing those bookmarks, thanks. Maybe I have to blame google :) On Tue, Oct 4, 2011 at 2:55 PM, Stephan Beal sgb...@googlemail.com wrote: n Tue, Oct 4, 2011 at 8:53 PM, Erlis Vidal er...@erlisvidal.com wrote: I would like to see the *shun* documentation, I'm not able to find it here http://www.sqlite.org/debug1/help Why would it be on the sqlite site? It's here: http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki -- - 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 ___ 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 you should not shun
Hi Richard, I would like to understand how you lost your changes, but probably because I'm ignorant of the internals I'm not able to understand what just happened here. I've read the Shun documentation and the Update documentation, and I cannot see how what you said here could occur. On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp d...@sqlite.org wrote: No problem, I thought. I'll just shun it. Which I did. Then I did fossil update previous so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed. It looks like the udpate command was the one that actually create the problem, but following your entire story, it seems that the situation was created by the Shun you did. Please (if is not much to ask) can you explain what creates the issue? Sincerely, Erlis ___ 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 you should not shun
And that's what I don't understand, how could the Update overwrote your changes. This is from the update help command *Change the version of the current checkout to VERSION. Any uncommitted changes are retained and applied to the new checkout. * If you do the same steps, without the shun, just modify some files, update previous. Would that remove my change in the current checkout? Thanks, Erlis On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal er...@erlisvidal.com wrote: Hi Richard, I would like to understand how you lost your changes, but probably because I'm ignorant of the internals I'm not able to understand what just happened here. I've read the Shun documentation and the Update documentation, and I cannot see how what you said here could occur. On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp d...@sqlite.org wrote: No problem, I thought. I'll just shun it. Which I did. Then I did fossil update previous so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed. It looks like the udpate command was the one that actually create the problem, but following your entire story, it seems that the situation was created by the Shun you did. Right. I shunned my most recent check-in, removing the content from the repository. Then I did an update to the previous check-in so that I could check in the changes again, but this time with the new smaller JPEG instead of the massive GIF. But the update overwrote *all* of the changes I had made over the course of the morning. So the shun removed the content from the repository. And the update removed the content from the disk. Fortunately, there was still one other copy in the undo stack Please (if is not much to ask) can you explain what creates the issue? Sincerely, Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] Why you should not shun
Ok I got it, following your story it was not clear that you shun the commit, thinking that you just shun the big file was what lead me to the big confusion... Regards, Erlis On Tue, Oct 4, 2011 at 4:53 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 4, 2011 at 4:50 PM, Erlis Vidal er...@erlisvidal.com wrote: You shun a commit or a file in a commit? Is in fossil the shun generating a different commit? I shunned both the commit artifact and the file that was changed, the openoffice *.odp file. you can delete with git files that has history with git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch file_name' HEAD and that will generate a new commit without the file you just deleted (yes I know, that git command is really cryptic that's why I'm liking fossil so much :) but I don't see how this will affect modified files. If the files are commited before, then you will never will lose those changes... unless you have shun those files, but I don't think that's the case, the file that was shun was a big image file, or I'm wrong? Both the commit and the file were shunned. I don't understand, but I feel that maybe I have to learn more fossil before continue, because I have the feeling this was more a bug than a misuse of a feature. The problem was operator error, not a bug in fossil. Why the shun confused the update? That's the question I'll try to answer... Thanks everyone... Erlis On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick bill.burd...@gmail.comwrote: You could handle that case -- if you shun the current commit, then check the disk against the current repo contents and mark files that are different as uncommitted. Bill On Tue, Oct 4, 2011 at 3:15 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal er...@erlisvidal.comwrote: And that's what I don't understand, how could the Update overwrote your changes. This is from the update help command *Change the version of the current checkout to VERSION. Any uncommitted changes are retained and applied to the new checkout. * Because of the shun, Fossil was confused. It thought that the changes had been committed, since they had been committed immediately prior to the shun. So the files on disk were marked as clean. Hence, Fossil overwrote them. ** If you do the same steps, without the shun, just modify some files, update previous. Would that remove my change in the current checkout? Thanks, Erlis On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal er...@erlisvidal.comwrote: Hi Richard, I would like to understand how you lost your changes, but probably because I'm ignorant of the internals I'm not able to understand what just happened here. I've read the Shun documentation and the Update documentation, and I cannot see how what you said here could occur. On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp d...@sqlite.org wrote: No problem, I thought. I'll just shun it. Which I did. Then I did fossil update previous so that I could commit the new version. But (oops) that deleted all of my changes. Everything was lost. Despair and gnashing of teeth followed. It looks like the udpate command was the one that actually create the problem, but following your entire story, it seems that the situation was created by the Shun you did. Right. I shunned my most recent check-in, removing the content from the repository. Then I did an update to the previous check-in so that I could check in the changes again, but this time with the new smaller JPEG instead of the massive GIF. But the update overwrote *all* of the changes I had made over the course of the morning. So the shun removed the content from the repository. And the update removed the content from the disk. Fortunately, there was still one other copy in the undo stack Please (if is not much to ask) can you explain what creates the issue? Sincerely, Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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 -- 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
[fossil-users] delete a branch
I'm sorry for this so n00b question but I'm not able to find this anywhere. Is it possible to delete a branch? I've created a branch by mistake, in this case I don't want to merge the branch, I'm looking for the git equivalent -f (force delete) Thanks, Erlis ___ 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] delete a branch
Hi all, thanks for the answers, maybe I'm approaching fossil from the git side. Maybe I have a misconception. In Git a branch is just a pointer to a given commit, removing the branch won't remove any content, unless the branch is not merged so I need to do the force thing but that's not the case. My mistake was that I create a branch but forgot to check it out, and did a couple of commits. Then I realized that the branch was there, but empty... it was my bad. I just noticed in the timeline that with fossil, creating a branch creates also a commit... hmmm now I see something different... Is there something I can read that could explain me better the fossil internals a wiki? Thanks for this job, Erlis On Fri, Sep 30, 2011 at 4:32 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Sep 30, 2011 at 10:01 PM, Erlis Vidal er...@erlisvidal.comwrote: Is it possible to delete a branch? I've created a branch by mistake, in this case I don't want to merge the branch, I'm looking for the git equivalent -f (force delete) http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki -- - 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 ___ 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] delete a branch
thanks! On Fri, Sep 30, 2011 at 4:44 PM, Brian Smith br...@linuxfood.net wrote: http://fossil-scm.org/index.html/doc/trunk/www/branching.wiki On Fri, Sep 30, 2011 at 1:38 PM, Erlis Vidal er...@erlisvidal.com wrote: Hi all, thanks for the answers, maybe I'm approaching fossil from the git side. Maybe I have a misconception. In Git a branch is just a pointer to a given commit, removing the branch won't remove any content, unless the branch is not merged so I need to do the force thing but that's not the case. My mistake was that I create a branch but forgot to check it out, and did a couple of commits. Then I realized that the branch was there, but empty... it was my bad. I just noticed in the timeline that with fossil, creating a branch creates also a commit... hmmm now I see something different... Is there something I can read that could explain me better the fossil internals a wiki? Thanks for this job, Erlis On Fri, Sep 30, 2011 at 4:32 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Sep 30, 2011 at 10:01 PM, Erlis Vidal er...@erlisvidal.com wrote: Is it possible to delete a branch? I've created a branch by mistake, in this case I don't want to merge the branch, I'm looking for the git equivalent -f (force delete) http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki -- - 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 ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] delete a branch
I've been following fossil community just a couple of weeks ago and you guys rocks! I really appreciate all your answers and the welcome I've received... Thanks once more for this amazing project Erlis On Fri, Sep 30, 2011 at 8:04 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Sep 30, 2011 at 10:38 PM, Erlis Vidal er...@erlisvidal.comwrote: My mistake was that I create a branch but forgot to check it out, and did a couple of commits. Then I realized that the branch was there, but empty... it was my bad. In such a case you can use: fossil commit -m '...' --branch branchname ...file list... to commit the changes to a specific branch. i _think_ that will work with existing branches, but it might require a _new_ branch name. I just noticed in the timeline that with fossil, creating a branch creates also a commit... hmmm now I see something different... LOL. There was a long debate about that behaviour a couple months back. Some prefer it that way, some prefer to commit to a specific branch to start the branch. Is there something I can read that could explain me better the fossil internals a wiki? All of those docs are over on the fossil web site. Try: http://fossil-scm.org/index.html/doc/trunk/www/permutedindex.wiki -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ignoring files
Hi guys, I'm start using fossil and at this moment I'm just playing with it. One thing I'm doing is migrating some .git repositories and see how it goes. With git I tend to put all files I want to keep out of the repo in the .gitIgnore file. I see in the documentation that fossil uses a command argument in the add command for this (--ignore) The problem with this is that the list on some of my git projects are really big and I don't want to type all those files. Do fossil has a syntax to exclude all files in certain folder? Example: exclude all files in the folder bin/ This option has the scenario when I want any bin/ folder to be excluded, or a specific folder /dev/project/files-to-be-excluded-from-repo/ is there something for this? I'm pretty sure there is by my fossil-ignorance at this point prevent me to find the answer Thanks for you patient Erlis ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
