Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 5:29 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: [...] But please don't also miss out a first-hand experience of someone who implemented a well-visible program centered around Lua: [1], [2]. Personally, I find that minimality (of the runtime) is the only strong point of Lua. Then it quickly falls apart when you hit its idiocy with using tables for everything which is ripe with special weird cases. Lua's stack-based API debunked in [1] also sounds bad to me as I have decent experience with extending Tcl in C (and embedding it in C), and I find Tcl's C API to be brilliant as well as its concept of reference-counted objects. Unfortunately, I have no experience using Lua from C so I, personally, have no real say here. But still... 1. http://julien.danjou.info/blog/2011/why-not-lua 2. http://julien.danjou.info/blog/2008/rants-about-lua Well, everyone is entitled to her/his opinion. Hence, here is mine. I have been using Lua for the last 6 years over several projects from small to moderatly large (as in 30K Lua + 20K in C++) and it has very invigorating and positive experience. Somewhat repetative nature of stack based C-API can be substantially simplified by means of helper functions. Moreover, using LuaJIT with its own FFI facility has been a pure joy. Added bonus being that LuaJIT is the fastest JIT compiler for any scripting language out there (beats JS V8 handily). In any case give Lua or/and LuaJIT a try and form your own opinion. Just my two cents. --Leo-- ___ 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] Markdown engine integrated into fossil
On Wed, May 30, 2012 at 1:24 PM, Ron Wilson ronw.m...@gmail.com wrote: On Thu, May 24, 2012 at 1:51 AM, Natacha Porté nata...@instinctive.eu wrote: If you don't mind, I'd rather have it not named at all. Due to how it's (still) heavily loaded with negative emotions, I would like not having to interact with the original project or its repository. And a name change at this level does involve quite a lot of interaction. In the open source community, people frequently start forks of other projects and develop them independantly under new names. A recent example of a high profile project is LibreOffice, which is a fork of OpenOffice. Thank you for your good work. And sorry that you got caught up in this controversy. You are in good company. History has many people who created great works that had unfortunate names. (I decline to name any as that is potentially another debate.) I also would like to thank Natacha for her great contribution and hope that as time goes by she might revisit her relationship with the original project. Unfortunately, human reaction to certain things like project naming could be unpredictable and sometimes destructive. Hopefully all the involved can get over it. --Leo-- ___ 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] fossil bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 6:11 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:34 PM, Matt Welland estifo...@gmail.com wrote: On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. In which case, the two files have nothing in common and the whole thing is one big merge conflict. Is that really helpful? Actually, this situation is known as a two-way-merge http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge and it is helpful in many cases. --Leo-- ___ 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] SSH commands run as user nobody
On Wed, May 9, 2012 at 5:25 AM, Lluís Batlle i Rossell vi...@viric.name wrote: On Tue, May 08, 2012 at 06:57:02PM -0400, Leo Razoumov wrote: And I do not see the extra a because I have the following line in the beginning of my ~/.bashrc # If not running interactively, don't do anything [ -z $PS1 ] return I said the *top* of my .bashrc ;) Regards, Lluís. Lluis, the whole discussion is about how to suppress unwanted output stemming from ~/.bashrc exectution (I agree, sshd man page is wrong) when ssh host command is called. Checking for $PS1 is a very simple way to achieve this. --Leo-- ___ 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] recent change: alt-root and its purpose?
On Sat, Apr 28, 2012 at 09:34, Richard Hipp d...@sqlite.org wrote: On a server, I often have multiple CGI scripts all pointing to the same repository. A similar feature, added at the same time, keeps track of all of the possible URLs for accessing a repository. On the main Fossil webserver for example, I just now did fossil info fossil.fossil and I see this: access-url: http://fossil-scm.hwaci.com/fossil 2012-04-28 I think this means that every time one accesses a repository via cg-bin the repository updates the baseurl:... entry. This would make rsync based replication/backup scripts go nuts (they depend on timestamps and checksums). Would it be better to have a configuration settings track-access (on/off) and track-ckout (on/off) to allow a user to selectively enable/disable new behavior according to his/her needs? --Leo-- ___ 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] cannot checkout a read-only Fossil repository
On Mon, Apr 30, 2012 at 09:45, Kevin Quick qu...@sparq.org wrote: On Sun, 29 Apr 2012 18:46:49 -0700, Leo Razoumov slonik...@gmail.com wrote: And at least in UNIX you really do not want making your repository writable by several people. Huh? Bob works on stuff and commits it. After Bob commits it, Alice should be able to update to get that commit, and vice-versa. If Bob and Alice have each cloned local copies, a couple of syncs is required as well, but ultimately they both need access to a common repository they can write to. I think I'm not understanding what your point is here. I am Sorry if my writing was not sufficiently clear. I meant that at least in UNIX it is better to have a repo.fossil repository *file* writable only by its owner and not by the group or, God forbid, the others (chmod 0644 repo.fossil). In the case of CGI the owner is whatever your http server likes (www-data on Ubuntu). Alice and Bob clone their local repos, work with them, and then fossil push to the master repo over http. No need for any write access to the underlying repo.fossil file. --Leo-- ___ 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] cannot checkout a read-only Fossil repository
On Mon, Apr 30, 2012 at 13:43, Stephan Beal sgb...@googlemail.com wrote: On Mon, Apr 30, 2012 at 7:25 PM, Leo Razoumov slonik...@gmail.com wrote: others (chmod 0644 repo.fossil). In the case of CGI the owner is whatever your http server likes (www-data on Ubuntu). Tip: many CGI environments run user CGIs as that user. If you are lucky enough to have such a service provider, chmod 0600 is the way to go. Even more restrictive. I like it!! --Leo-- ___ 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] recent change: alt-root and its purpose?
On Sat, Apr 28, 2012 at 13:00, Matt Welland estifo...@gmail.com wrote: On Sat, Apr 28, 2012 at 6:34 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov slonik...@gmail.com wrote: Hi All, Fossil design clearly separates a project repository database from a checkout database. It is explicitly stated in the Fossil documentation: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki Notice that the checkout database contains a pointer to the repository database but that the repository database has no record of the checkout databases. That means that a working checkout directory tree can be freely renamed or copied or deleted without consequence. Unfortunately, this in not true anymore since trunk [e604d483ee55] (2012-04-27 15:43:51). Now every time you fossil open a repository, the checkout root gets recorded into config portion of the project repo. All the checkouts ever created are displayed as alt-root entries by fossil info. The alt-root list can get long if one has many checkouts. By the way, fossil close does *NOT* remove the entry from the alt-root list (a bug??). The list only grows and never shrinks. A convenient way of dispensing with checkouts by rm -rf path-to-checkout leaves behind dangling references to non-existing directories. To the best of my knowledge there has been no discussion of this feature on the fossil-users or fossil-dev mailing lists. Therefore, I would greatly appreciate if someone can explain to me (1) What is the purpose of the feature. (2) Its intended use. (3) Rational for violating long-standing Fossil design principle that project repo database does not know its checkouts. I added this to help me keep track of where my check-outs are located. I keep all of my repositories in a single directory so I know where they all are. But my check-outs are scattered about hither and yon, according to their use and function. Many times I'll be looking at my growing collection of repositories and wonder where did I check this one out most recently. Or I'll be be working in a check-out and want to do some unrelated change on another branch and then wonder if I have other checkouts of the same repo sitting around anywhere. Isn't this information also stored in ~/.fossil as ckout:/path/to/ckout|/path/to/repo.fossil entries? I think I'd prefer to see the data recorded just once and actually I think the ~/.fossil file is a better place. Those entries should meet all your requirements as it maps each repo db to a checkout. Even if the repo db was moved there is enough data available to find the mapping and update the pointers in the _FOSSIL_ files. Since I can't get fossil ssh to work we are using rsync to sync fossils cross-site and with this feature every time someone blows away a repo and re-gets it the rsync logs will show a transfer implying that a change was made. Not a big deal but confusing and an annoyance nonetheless. If the decision is to stick with the new method then please consider removing the code that adds the ckout: entries to ~/.fossil as people will write automation that relies on one or the other and that can get messy and chaotic when there is not one canonical source data location. Matt, very good point! IMHO, ~/.fossil is, indeed, the best place to keep track of the existing checkouts. One can also write a script that loops through the checkouts in ~/.fossil and removes the dangling references and/or lists checkouts with uncommitted changes. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] cannot checkout a read-only Fossil repository
Hi All,
the recent changes to the trunk make fossil open to modify the
fossil repository being opened.
If this repository is read-only or mounted on a read-only file system
than fossil open fails [2] and no _FOSSIL_ file is created.
I would prefer the solution proposed by Matt Welland [1] to keep all
checkout information confined to ~/.fossil.
A mere fact that someone called fossil open should not cause
modifications to the project repository.
~/.fossil is, on the other hand, a completely different story. Its
purpose is precisely to help a user to organize its work with all
his/her fossil repositories and their checkouts.
--Leo--
[1]
http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-April/009038.html
[2] $ ~/Devel/Fossil/upstream/BUILD/fossil open ../T.fossil
foo
/home/leor/Devel/Fossil/upstream/BUILD/fossil: SQLITE_READONLY:
statement aborts at 34: [REPLACE INTO
config(name,value,mtime)VALUES('ckout:/tmp/fossil-tests/T/',1,now())]
attempt to write a readonly database
/home/leor/Devel/Fossil/upstream/BUILD/fossil: attempt to write a
readonly database
REPLACE INTO
config(name,value,mtime)VALUES('ckout:/tmp/fossil-tests/T/',1,now())
If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.
___
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] cannot checkout a read-only Fossil repository
On Sun, Apr 29, 2012 at 12:08, Kevin Quick qu...@sparq.org wrote: This isn't quite as convincing an argument to me: I can see the utility of a pull/sync from a read-only repository, but a fossil open implies that one will be doing work with the opened contents and further implies that one will probably expect to commit the results. This does not preclude the scenario Leo describes, but: Often I just want to checkout a certain branch and compile it without making any modifications. Also, quite a few people use Fossil as a backup/synchronization tool. backups may end up on DVDs which are read-only. The counter-argument to adding the information to ~/.fossil is that the latter is user-centric. Taking D. Hipp's scenario of working directories and cgi-bin operations and other activities, the cgi-bin is likely to use a neutered account, and there may be multiple other users accessing the same fossil repository (to which those users have write permissions. :-). A user script like Matt Welland's fsl can still annotate ~/.fossil (or ~/.fsl) to track opens for that particular user. cgi-bin does not operate on checkouts. And at leat in UNIX you really do not want making your repository writable by several people. Besides it is easy to track checkouts without any modifications to Fossil core. A simple script can locate all checkouts by calling fossil all list or (on Linux) locate _FOSSIL_. Then one can loop through the checkouts and call fossil status to determine the attached fossil repository and whether there are any outstanding changes waiting to be checked in. --Leo-- ___ 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] recent change: alt-root and its purpose?
On Sat, Apr 28, 2012 at 07:25, Stephan Beal sgb...@googlemail.com wrote: On Sat, Apr 28, 2012 at 1:03 PM, Leo Razoumov slonik...@gmail.com wrote: (3) Rational for violating long-standing Fossil design principle that project repo database does not know its checkouts. This sounds like it might also (minorly?) complicate out-of-fossil synchronization of repos for some users (e.g. rsync-based), since a checkout now changes the repo file? Regarding the unlimited growth: i've been using fossil since 2007 and have never had any given repo checked out more than twice locally. Even with 50 entries, the storage required is minimal. (Nonetheless, i share your curiosity about why this new feature might be needed at all.) I do checkout a repo often and multiple times -- typically, one checkout-per-branch I am working with (for fossil-scm alone I have 5 checkouts). Please, keep in mind that fossil open adds a checkout entry while fossil close does *NOT* remove it. Basically, a project repo keeps accumulating checkout entries some of which refer to deleted checkouts that no longer exist! It also clutters output of fossil info command. And, of course, it breaks rsync. --Leo-- ___ 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] pre-written commit message
On Thu, Apr 5, 2012 at 07:18, Lluís Batlle i Rossell vi...@viric.name wrote: Before finishing edit the message, I realised I don't want to commit those changes that way, I prefer to do a little more change. I quit the edtior without saving changes, and fossil commits my changes with the old cherrypick log. If you had deleted all the text of the commit message in your editor and saved it empty, commit process will be aborted. I used this trick several times in the past when I changed my mind in the last moment and wanted to bail out from an imminent commit. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] (Q) How to add the row number column to an open tickets report?
Hi Everyone, I am sorry if I am asking something trivial but I am not a SQL expert. I have a ticket report that lists all open and active tickets. I would like its first column to simply show row numbers starting with 1 for the first row of the report, 2 for the second row and so on. Google suggest to use ROW_NUMBER() SQL command, but AFAIK SQLite does not support it yet. Any help or/and suggestions are greatly appreciated. Thanks, --Leo-- ___ 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] embedding doxygen into wiki
On Sat, Mar 24, 2012 at 16:33, ST smn...@gmail.com wrote: Thank you Bill, however I didn't understand what I need to do in order to be able to create a link like this: a href=file://$pathToProject/doc/html/index.htmlproject/a Do I have to reimplement something? I think there is a simple way to achieve what you want. If you run fossil as an CGI script under true web server (apache, nginx, etc) you can put your doxygen tree somewhere in the webserver html space and then in your fossil wiki page make a link a href=http://your-server/prj/doxygen/index.html;my beautiful code/a All your doxygen pages are now served outside and independent of fossil. If I understand correctly you do not want to checkin doxygen generated files anyway. --Leo-- ST On Thu, 2012-03-22 at 11:02 -0500, Bill Burdick wrote: OK, it looks like you're willing to use more than just HTML there. Here's a way to get the prefix of the fossil URL. Look at the assignment of url in the markup function, here: https://chiselapp.com/user/zot/repository/fossil-pagedown/artifact/4bcb90437a6e33bbbcc7edf3b6a21de00889c05c Bill On Thu, Mar 22, 2012 at 10:30 AM, ST smn...@gmail.com wrote: thank you for your reply. This would work only for index.html but not for the rest of the doxygen files which are linked to from index.html until I add them to checkin as well. But since all the doxygen files are autogenerated its not nice to put them into checkin. ___ 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] The fdiff page, 'patch' mode, has html
2012/3/24 Lluís Batlle i Rossell vi...@viric.name: On Sat, Mar 24, 2012 at 04:39:52PM -0400, Leo Razoumov wrote: That patch is since some weeks in a branch I maintain with the annoyances I consider worth fixing, and features worth having (as far as I can program). http://fossil-scm.org/index.html/info/675b49efa3 I have not checked how similar is your patch to mine, but the effect should be the same. Regards, Lluís. Lluís, the main difference is that in my patch I also made number_of_context_lines produced by fdiff consistent with what diff and vpatch use (5 lines). For some reason fdiff was setting diffFlags = 4; resulting in 4 context lines while the rest of fossil relies on diff_context_lines function which uses the default value of 5. Other than that the patches are very similar. --Leo-- ___ 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] New user wants to know what commands are command-line only? (So I can ignore all others)
On Sat, Mar 24, 2012 at 17:26, Stephan Beal sgb...@googlemail.com wrote: On Sat, Mar 24, 2012 at 8:06 PM, H.C. Chen hcchen5...@gmail.com wrote: Thanks, it's very very helpful and have saved me a lot of time. I'd like to add, changes addremove init FWIW: i've been using fossil since 2007 and have never used any of those. ;) -- - stephan beal Stephan, I understand one can use fossil without changes or addremove but how can you survive since 2007 without init ?? --Leo-- ___ 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] New user wants to know what commands are command-line only? (So I can ignore all others)
On Sat, Mar 24, 2012 at 17:42, Stephan Beal sgb...@googlemail.com wrote: On Sat, Mar 24, 2012 at 10:37 PM, Leo Razoumov slonik...@gmail.com wrote: I understand one can use fossil without changes or addremove but how can you survive since 2007 without init ?? fossil new foo.fsl mkdir foo cd foo fossil open ../foo.fsl new (the same thing as init) was never mentioned in this thread. I though you have a magic trick to create a repo without these two, but never mind:-) --Leo-- ___ 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] asciidoc-fossil-backend
On Thu, Mar 22, 2012 at 03:12, Gour g...@atmarama.net wrote: Hello! In our search for adequate markup to be used for our upcoming open-source project, we stumbled upon AsciiDoc (http://www.methods.co.nz/asciidoc/) and, so far, like it very much and decided to use it instead of reST/Sphinx, markdown etc. However, the best part is that there is asciidoc-fossil-backend (https://github.com/srackham/asciidoc-fossil-backend) which enables one to write his/her documentation in AsciiDoc and still display it nicely on the site using Fossil's wiki mechanism. Gour, could you, please, provide a demo so that one can see AsciiDoc + Fossil in action. --Leo-- ___ 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] asciidoc-fossil-backend
On Thu, Mar 22, 2012 at 11:16, Gour g...@atmarama.net wrote: On Thu, 22 Mar 2012 15:52:12 +0100 Ephrim Khong dr.khong+fos...@gmail.com wrote: It seems, though, that the AsciiDoc-Backend simply translates text from AsciiDoc-Markup to Fossil-Markup. Correct. I think it would be better to produce HTML from AsciiDoc and set fossil wiki to Use HTML as wiki markup language from Admin-Configuration. Full HTML is so much more powerful than what fossil wiki syntax allows. --Leo-- ___ 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] merge strategy ours
On Wed, Mar 21, 2012 at 12:23, Themba Fletcher
themba.fletc...@gmail.com wrote:
On Tue, 2012-03-20 at 15:04 -0400, Leo Razoumov wrote:
On Tue, Mar 20, 2012 at 09:57, Richard Hipp d...@sqlite.org wrote:
Why not just fossil revert my/file.txt?
For each one of dozens of files in the manifest??
Does this do what you want?
fossil merge foo
fossil changes | head -n -1 | awk '{print $2}' | xargs fossil revert
Themba,
thanks for a script. I hope that the files deleted by the merge would
not cause any problems.
--Leo--
I tried
$ fossil revert
and it reverts the contents of all files but at the same time it also removes
merge record (clears vmerge table).
All I want is to record a new merge parent without merging in file contents.
--Leo--
On Tue, Mar 20, 2012 at 14:14, Leo Razoumov slonik...@gmail.com wrote:
Hi there,
GIT has a useful merge strategy git merge -s ours that always
chooses our current version over the version being merged in. The
resulting merge has exactly the same files contents as its base
parent. The only difference being that the commit merged in is now
added to the list of merge parents.
How to achieve the same effect in fossil??
For those who wonder why do I need such a thing here is a use case. I
tend to commit very often. In order to prevent polluting public
branches I work mostly on private branches periodically merging the
changes (when they are in good shape) into public branches. When
merging private branch into a public one fossil does not record
private branch as a merge parent (and for a good reason!). Often I do
have a suitable merge parent candidate. How do I trick fossil into
just adding a commit into manifest's P card to make it a merge
parent??
--Leo--
___
___
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] How can I determine if a repository has actually changed?
On Wed, Mar 21, 2012 at 13:25, Stephan Beal sgb...@googlemail.com wrote: i don't know about Ubuntu1, but dropbox synchronizes only the bytes which changed, so the sync is really fast. There is, however, still a couple caveats with this approach (sorry for my brevity earlier - i was on my phone): True, but does not help if your file is encrypted. You change a single byte of your plain-text-file and your encrypted version changes entirely. --Leo-- ___ 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] How can I determine if a repository has actually changed?
On Wed, Mar 21, 2012 at 14:53, Ron Aaron r...@ronware.org wrote: On 03/21/2012 08:06 PM, Leo Razoumov wrote: True, but does not help if your file is encrypted. You change a single byte of your plain-text-file and your encrypted version changes entirely. Precisely so. And I don't want to encrypt and synch the file, unless it has changed in a meaningful way (e.g. not just some synch timestamp inside) Poor man's way of figuring it out is to capture the output from fossil pull (or fossil push) command, parse it and if all numbers of transfered artifacts and deltas are zero than nothing changed. --Leo-- ___ 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] How can I determine if a repository has actually changed?
On Wed, Mar 21, 2012 at 17:17, Stephan Beal sgb...@googlemail.com wrote: On Wed, Mar 21, 2012 at 8:40 PM, Ron Aaron r...@ronware.org wrote: So what I am looking for is a way to take a 'snapshot' of a repo, and determine if the new version of that repo is actually different, even though I may have done multiple pulls in between checks. Doesn't the timeline reveal if anything meaningful was changed? Could you not query the timeline (e.g. via scripting fossil json timeline...)? I think this is the winner. I cannot thing of any (non pathologically esoteric) cases when a repo changes but the last 20 commits stay the same. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] merge strategy ours
Hi there, GIT has a useful merge strategy git merge -s ours that always chooses our current version over the version being merged in. The resulting merge has exactly the same files contents as its base parent. The only difference being that the commit merged in is now added to the list of merge parents. How to achieve the same effect in fossil?? For those who wonder why do I need such a thing here is a use case. I tend to commit very often. In order to prevent polluting public branches I work mostly on private branches periodically merging the changes (when they are in good shape) into public branches. When merging private branch into a public one fossil does not record private branch as a merge parent (and for a good reason!). Often I do have a suitable merge parent candidate. How do I trick fossil into just adding a commit into manifest's P card to make it a merge parent?? --Leo-- ___ 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] merge strategy ours
On Tue, Mar 20, 2012 at 09:57, Richard Hipp d...@sqlite.org wrote: Why not just fossil revert my/file.txt? For each one of dozens of files in the manifest?? I tried $ fossil revert and it reverts the contents of all files but at the same time it also removes merge record (clears vmerge table). All I want is to record a new merge parent without merging in file contents. --Leo-- On Tue, Mar 20, 2012 at 14:14, Leo Razoumov slonik...@gmail.com wrote: Hi there, GIT has a useful merge strategy git merge -s ours that always chooses our current version over the version being merged in. The resulting merge has exactly the same files contents as its base parent. The only difference being that the commit merged in is now added to the list of merge parents. How to achieve the same effect in fossil?? For those who wonder why do I need such a thing here is a use case. I tend to commit very often. In order to prevent polluting public branches I work mostly on private branches periodically merging the changes (when they are in good shape) into public branches. When merging private branch into a public one fossil does not record private branch as a merge parent (and for a good reason!). Often I do have a suitable merge parent candidate. How do I trick fossil into just adding a commit into manifest's P card to make it a merge parent?? --Leo-- ___ 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] strange 'login failed' error on initial repository clone.
On Tue, Mar 20, 2012 at 10:11, Jeremy Anderson jere...@gmail.com wrote:
Thanks, Leo. You just solved my problem!
The password I was using began with a hash symbol ('#')... adding an
additional # (##[password]) got it to work.
Is it just me, or is putting special tokens like that in the password a bad
idea? :)
Jeremy,
I am glad that this little undocumented trick solved your problem. In
Fossil's login process leading # has a special meaning. If one runs
fossil as a CGI script and the web server requires its own basic
authorization (authentication) prepend an extra # to your password.
In general I would recommend to stay away from special chars like
*^#* in your password. If you are concerned with your password
security make your password longer. 64^8 is greater than 70^7.
--Leo--
On Tue, Mar 20, 2012 at 4:03 AM, Leo Razoumov slonik...@gmail.com wrote:
On Tue, Mar 20, 2012 at 02:12, Jeremy Anderson jere...@gmail.com wrote:
Hey everyone. Need a little help...
Problem:
Attempting to clone a recently-created repository gives this error:
D:\f\repofossil clone
http://user:p...@ec2-xxx.compute.amazonaws.com:6969/hekate
d:\f\repo\hekate.fossil
Could you, please try URL without password like this:
D:\f\repofossil clone
http://u...@ec2-xxx.compute.amazonaws.com:6969/hekate
d:\f\repo\hekate.fossil
Now when fossil prompts you for a password type # followed by your
password.
'#' prefix tells fossil to use the password (with # removed, of
course) both for your server Basic Authorization and for your fossil
repo.
Please, let the list know whether it helps.
--Leo--
___
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] problem with illegal characters
On Fri, Mar 9, 2012 at 04:18, Gour g...@atmarama.net wrote: What do you mean 'pre-existing'? Software is created by you. Can you show me some sotware project using names with such funky characters? Gour, one size fits all does not work in real life. For instance, brackets, spaces, etc. are used in file names generated by certain medical imagining machines. And when you deal with medical technicians, nurses, medical students and above all physicians telling them that your software cannot handle file names with spaces is a sure bet to loose their interest. I agree that if I am naming a file, I will produce a name that is shell friendly and avoid using random characters. But I should be able, in principle, to import someone else's file which is named using different conventions. That said, I personally have no problem maintaining a separate branch where I modify fossil code to suit my needs. We've already seen that someone who wants to store OOXML files in a 'diff'-able way, will have to jump through extra hoops to get the [Content-Types].xml file into fossil. OOXML files are 'binaries', not diff-able and therefore not suitable for 'software configuration management'. You can think of OOXML as compressed tar archives. They are text XML files underneath. You can diff and merge them the same way you diff and merge regular XML or HTML files. You just store and track OOXML files in expanded form. First of all educate people how to name files and/or then write simple script to batch rename those files before checking them into fossil. Tooling and retooling should not be too intrusive. Remember, tools are here to help people not to add extra hustle to their already complex work. If your tool is a nuisance people will shun using it. Not everyone is as passionate about SCM tools as people on this list. is such a problem for you to adopt a Fossil, then I might say that you do not have enough experience with (D)VCS in general to be able to appreciate everything which Fossil does so superbly. Otoh, you can try Git/Mercurial/Bazaar/Monotone if you believe that this feature is critical for you your team. Please, keep discussion devoid of emotions. It is a technical list and we are all friends here. --Leo-- ___ 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] problem with illegal characters
On Fri, Mar 9, 2012 at 07:11, Stephan Beal sgb...@googlemail.com wrote: Perhaps we could/should make the set of illegal characters a config option, defaulting to the current set? This may cause problem with globing. --Leo-- ___ 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] clearsign, so what
On Fri, Mar 9, 2012 at 13:02, Thomas Stover c...@thomasstover.com wrote: -Algorithmically verify that changes are signed by trusted users on push/pull operations. (this is also a question) Theoretically, it is sufficient to sign a leaf manifest so that entire part of the DAG that grows out of this leaf by following the parent links becomes fortified. A manifest contains SHA1 hashes of all the files in the commit and of all its parent manifests. Assuming that intruder cannot break the signature private key and cannot forge SHA1 hash collisions we trust the commit and its parents. Then recursively we trust grand-parents and so on until we traverse a subset of the DAG connected to the initial leaf. In practice I would advocate a policy that fossil already has -- auto sign every manifest. So from the ideal scm features point of view, what is suppose to happen? Just verify that diffs and/or complete project versions are signed by a user? As in a property of a user being a public key? Or as in some sort of hook script check this externally before allowing a sync? If a signing key is later found to be compromised, then changes made with that signature need to be flagged for inspection? If signing key itself is compromised (intruder knows private key) all bets are off. Manual labor is the only remedy:-) --Leo-- ___ 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] clearsign, so what
On Wed, Mar 7, 2012 at 22:03, Richard Hipp d...@sqlite.org wrote: On Wed, Mar 7, 2012 at 7:10 PM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 18:03, Brian Smith br...@linuxfood.net wrote: On Wed, Mar 7, 2012 at 2:40 PM, Leo Razoumov slonik...@gmail.com wrote: Looking through the fossil source code I found places where manifests are clearsign-ed. But where are signatures verified? They're not. It's designed for when you're auditing check-ins (after, say, a security breach..) That's precisely my question. How do I audit? I never got around to implementing that part. An audit has never come up. Do you have a suggested interface? Where do we collect the public keys for the authorized signers? You do not need to collect public keys of authorized signers inside a fossil repo. They are stored by gpg in the GPG ring of trust. I do not think that fossil should interfere with the GPG key distribution process. Let each project team handle their key distribution themselves via key-signing parties, trusted key servers, etc. Command interface for signature verification in fossil could be as follows: $ fossil verify ?-R repository? sends to the stdout output a list of entries, one line per each clearsign-ed artifact in the following format SHA1_hash status where status field is one of the three possibilities: (1) signed by key. Check Pass (2) signed by key. Check Fail (3) signed by key. Check Miss In case (3) signature verification process was unable to complete because, for instance, public key was missing, etc. A user can then grep for check fail and check miss to dwell further on suspected artifacts using their SHA1 hashes. The command exits with a status code of 0 if no check fail or check miss signatures were found, 1 if only check miss but no check fail, and 2 if check fail has been seen. --Leo-- ___ 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] clearsign, so what
On Wed, Mar 7, 2012 at 19:11, Brian Smith br...@linuxfood.net wrote: On Wed, Mar 7, 2012 at 4:10 PM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 18:03, Brian Smith br...@linuxfood.net wrote: On Wed, Mar 7, 2012 at 2:40 PM, Leo Razoumov slonik...@gmail.com wrote: Looking through the fossil source code I found places where manifests are clearsign-ed. But where are signatures verified? They're not. It's designed for when you're auditing check-ins (after, say, a security breach..) That's precisely my question. How do I audit? What command should I use to verify signed artifacts? Preferably, I would like to see something like fossil verify that outputs a list of all clearsign-ed artifacts in the repo annotated with checked OK, check Failed or cannot check (e.g. when key is missing). Recent github compromise gives us some food for thought about fossil's mechanism to ensure data integrity. --Leo-- I believe you're supposed to deconstruct the repository, and run each manifest through gpg. -B Good Lord! Deconstruct a repo, go through all the artifacts, then identify which ones are clearsign-ed, then verify them, then produce a report... Rule #1 in security design: if you make a security feature hard to use, nobody will use it. Why not have a fossil verify or fossil clearcheck command that makes those checks. Paranoid folks can even run it once a weak from a cron-job. --Leo-- ___ 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] clearsign, so what
On Wed, Mar 7, 2012 at 19:37, Themba Fletcher themba.fletc...@gmail.com wrote: If I understand correctly, what happened at github was that someone exploited a misconfiguration in the rails framework to insert his own public key as trusted with respect to several repositories. The fossil verify command you proposed above would have had little to no benefit in detecting or sorting out that particular mess. It seems to me cleaning up any specific intrusion is going to be a special case and is probably going to require a trip into the depths of SQLite. I don't really see any benefit to having built-in commands to try to detect a subset of potential intrusions -- that just introduces a larger code base. And every added line of code is a potential security hole in and of itself. Themba I think you are entirely missing my point! It is not about intrusion detection but about *code integrity*. Your box can be compromised via different attack vectors not even related to your SCM. But distributed SCMs have an advantage that when you try to sync a malicious code coming from a compromised remote server with your pristine local version you have a fighting chance to detect malicious code manipulations. For that very reason gpg --clearsign signatures have been already implemented in fossil specifically to verify the identity of the commiters. As it stands now, signing a commit in fossil is very easy but signature verification has not been implemented. As a result, a user is forced to implement signature verify out of tree. It is error-prone, inconvenient and time consuming. Most importantly, due to extra work required users simply will not use these signatures. --Leo-- ___ 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] ASCII filename issue
On Tue, Mar 6, 2012 at 06:21, Ștefan Fulea fulea.ste...@gmail.com wrote: Fossil doesn't seem to get along with square brackets: Z:\fossil add file[N].x Z:\fossil.exe: filename contains illegal characters: file[N].x Confirmed on Linux with fossil trunk [7367cec4c8]. Escaping brackets does not help either. I think it is a bug. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] detecting site compromise
In light of a recent Github compromise https://lwn.net/Articles/485162/ I am curious of how one can detect and repair a compromised fossil site?? --Leo-- ___ 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] detecting site compromise
On Mon, Mar 5, 2012 at 18:25, Richard Hipp d...@sqlite.org wrote: On Mon, Mar 5, 2012 at 6:14 PM, Leo Razoumov slonik...@gmail.com wrote: In light of a recent Github compromise https://lwn.net/Articles/485162/ I am curious of how one can detect and repair a compromised fossil site?? The code that is already checked in is cryptographically secure. Changing the code is as difficult as a pre-source attack on SHA1: currently considered to be impossible with existing or foreseeable technology. An attacker can add new artifacts, to do things like add new leaf check-ins, change existing check-in comments or check-in times, or move check-ins to different branches and whatnot. But those kinds of changes are readily apparent on the timeline. And they can be undone. What happens if an attacker can shun artifacts, rebuild database, edit commit messages, events, tickets, etc? Fossil sync might happily pull compromised items into a local repo. Carefully crafted commit edits might disguise malicious actions. Am I being paranoid:-)? --Leo-- ___ 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] detecting site compromise
On Mon, Mar 5, 2012 at 18:49, Richard Hipp d...@sqlite.org wrote: On Mon, Mar 5, 2012 at 6:34 PM, Leo Razoumov slonik...@gmail.com wrote: What happens if an attacker can shun artifacts, rebuild database, edit commit messages, events, tickets, etc? Fossil sync might happily pull compromised items into a local repo. Carefully crafted commit edits might disguise malicious actions. Am I being paranoid:-)? When you pull in the revised content, the shuns done on the server will not typically be pulled over. So when you run a timeline on your local repo (using fossil ui) you'll see two completely separate lines of development - the legacy clean line and the bogus line inserted by the attacker. Surely this will clue in that something is wrong. I guess the attacker could add artifacts that move the check-in times for the clean legacy checkins back in time to (say) 1970, where you are unlikely to notice them. But even then, when you go to do your next commit, the commit will still attach to your legacy line of development, assuming you haven't done a fossil update BRANCH to some BRANCH that the attacker has redefined. I typically do fossil update trunk. So, I guess, in this case I am hosed. But even if you don't discover the attach right away, the immutable audit trail is still there in the repository. So you can go back and see what happened. This is good feature of fossil. Full chain of custody and a forensic trail. Be careful not to let the attacker trick you into pulling over the shunning list though. If the attacker can shun, then they can do a lot of virtually undetectable damage. auto-shun is enabled by default in any newly created fossil repo. Is it a wise default choice? --Leo-- ___ 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] feature proposal: explicitly public branches
On Fri, Mar 2, 2012 at 03:50, Stephan Beal sgb...@googlemail.com wrote: FYI: the JSON API doesn't aim to handle functionality which works directly with a checkout, e.g. checkout, commit, pull, push, update. It's main aim is to provide more or less the same data needed for implementing alternative remote UIs (analog to the HTML interface). Correct me if I am wrong, but I think that JSON API can be used to construct a list of artifacts in some non-trivial way. Then these artifacts can be pushed/pulled using regular fossil limsync --pushrefs/--pullrefs functionality. --Leo-- ___ 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] feature proposal: explicitly public branches
On Fri, Mar 2, 2012 at 03:50, Stephan Beal sgb...@googlemail.com wrote: Correct - i don't think we'll be able to do that kind of feature in JSON, largely because JSON doesn't do binary. The closest thing to commit i think we'll be able to portably/sensibly pull off is handling embedded docs (but i haven't attempted that yet, and it might or might not be possible with the current internals, but i suspect it is possible). Actually you can make JSON handle arbitrary binary blobs by encoding binary data in e.g. base64. The other end can easily decode it back to binary. It will cost you about 33% in size overhead, though. --Leo-- ___ 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] feature proposal: explicitly public branches
Brian, for simplicity you might want to follow the selection rules that already exist in fossil web-interface. When I go to the web-interface=Branches and select a branch I am presented with a partial view of the DAG that fossil thinks is relevant to the branch I chose. For the sake of consistency I would prefer that limsync push/pull uses the same selection rules and transfers the same commits. To transfer individual commits it would be great if --pushtags and --pulltags accept SHA1 hashes in addition to actual tag names. As a next step, I hope, one can augment limsync with a json API so that power users can do more complex things. --Leo-- P.S. Sorry for top-posting. On Wed, Feb 29, 2012 at 21:32, Brian Smith br...@linuxfood.net wrote: Hello again, Ok, so, it's not quite afternoon, but, it's still the same day. Here are some of the basic items that need feedback: I've marked each question with an asterisk (*) so that you can find my questions easier. Scenario: You're pulling a specific branch (topic1) that other developers are also committing on. You have only ever pulled topic1 branch and nothing else. Someone commits to topic1 and then later moves that commit to the mistake branch. As presently implemented, limsync will pull in the control artifact that made that change, and that commit will then show up in your copy on the mistake branch, even though you've never pulled mistake. (*) What do people want to have happen here? I think this is reasonable behavior because, the movement of a commit off of the branch you're interactive with is a valid part of the history of that branch. I don't yet know what it would take to change that behavior. Scenario: Same as above. Someone merges into topic1 the branch topic2. As presently implemented, limsync will pull in the merge commit, and the last commit to topic2, but no other commits. It's necessary to at least pull in every immediate parent of a merge commit, but, it only needs to be the manifests. File data could be excluded. It's possible to have limsync pull in the complete history of topic2 on such an event. (*) What would people prefer to see with respect to merge commits? I suppose this could be configurable behavior, but, I'm hesitant to make it configurable on the first pass. That should be added later based on demand, probably. Scenario: Same as before. Someone creates a new branch topic3 off of some commit of topic1. limsync currently will pull in the first commit of that new branch. Mind you, only the _first_ commit will be pulled in. I don't yet know how it interacts with the command 'branch new'. I'll add that to my list of things to test regardless. (*) Does anyone have any preference here? I could probably make it ignore new branches off of the branches you're pulling, but, it seems to me that discovering new lines of history is valuable. That's it for the behavior questions. I have a couple user interface and functionality questions as well that could be helpful to get feedback on. Though, if nobody has any immediate preferences, I'll just go ahead and do whatever I want. :) Right now, the command line interface is modeled like so (ignoring existing flags): fossil push/pull [--tickets] [--wiki] [--branch NAME]* Plus two advanced flags: --pushtags, --pulltags which allow you to specify any arbitrary tag name. All of --tickets, --wiki, and --branch, are essentially implemented in terms of those two flags. --branch, --pushtags, and --pulltags can all be specified multiple times like so: fossil push --branch topic1 --branch topic2 (*) Would people prefer a comma separated list of branches/tags ? (*) Would it be useful to anyone to be able to specify something like: fossil pull --tag release=v1.0 So that you could theoretically create repositories that only track tags with specific values? That's it for now. As I put my head back into the code, I'm sure I'll come up with other questions. -B On Wednesday, February 29, 2012 at 12:22 PM, Brian Smith wrote: Hi, Sorry for my radio silence over the weekend. I have to say, I'm a tad caught off guard by the sudden enthusiasm for this feature! Anyway, what I need most is community feedback on some open questions. You can find most of my open questions in the fossil-dev archives. (Unfortunately, it looks like you need to sign up for that list to see them.) Right now, I need to do some other work, but, I'll try to carve out some time this afternoon to summarize the open questions and give an overview of what I'd like to push into a branch on the master repo once the feature has more testing. -B On Saturday, February 25, 2012 at 7:37 PM, Leo Razoumov wrote: On Sat, Feb 25, 2012 at 21:30, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 02/26/12 03:09, altufa...@mail.com wrote: Why not just productize limsync? Going by what Brian Smith has written, it's a question
Re: [fossil-users] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 09:16, Richard Hipp d...@sqlite.org wrote: On Thu, Mar 1, 2012 at 6:18 AM, Leo Razoumov slonik...@gmail.com wrote: Brian, for simplicity you might want to follow the selection rules that already exist in fossil web-interface. When I go to the web-interface=Branches and select a branch I am presented with a partial view of the DAG that fossil thinks is relevant to the branch I chose. For the sake of consistency I would prefer that limsync push/pull uses the same selection rules and transfers the same commits. Note that there are a several of ways to view check-ins related to a branch. For example: http://www.fossil-scm.org/fossil/timeline?r=experimental http://www.fossil-scm.org/fossil/timeline?r=experimentalmionly http://www.fossil-scm.org/fossil/timeline?t=experimental What does mionly flag do? I was not able to find any documentation for it. Look likes it has something to do with merges. --Leo-- ___ 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] Overwriting binary files on 'update'
2012/3/1 Lluís Batlle i Rossell vi...@viric.name: Hello, in fossil 1.21, I've a modified openoffice file. Then I run fossil update, and it tells me there is a merge conflict with a binary file, that it cannot merge. What I'm surprised about is that fossil overwrites my local changes with the incoming ones. And the file with local changes disappears, only available again on 'fossil undo'. Should't fossil better leave additional files in the directory, as with the -baseline, -original, and -merge? Please, correct me if I am wrong, but I noticed that fossil update also overrides unmanaged files (both binary and text). I am not sure that their contents are backed up. --Leo-- ___ 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] feature proposal: explicitly public branches
On Thu, Mar 1, 2012 at 18:04, Brian Smith br...@linuxfood.net wrote: On Thursday, March 1, 2012 at 3:18 AM, Leo Razoumov wrote: Brian, for simplicity you might want to follow the selection rules that already exist in fossil web-interface. When I go to the web-interface=Branches and select a branch I am presented with a partial view of the DAG that fossil thinks is relevant to the branch I chose. For the sake of consistency I would prefer that limsync push/pull uses the same selection rules and transfers the same commits. Ok, I think the behavior of the r=branch timeline view makes sense. I'll make sure I mirror it as closely as possible. To transfer individual commits it would be great if --pushtags and --pulltags accept SHA1 hashes in addition to actual tag names. Hm, so, you would be in favor of a more general notation closer to: --pushrefs --pullrefs, where a 'ref' is a full sha1, or a tag? Would unique prefixes of sha1 hashes be useful too? (Those are currently accepted elsewhere.) Note: I don't really know how feasible that is with the current code, but, I could possibly retarget.. Yes, unique SHA1 hash prefixes would be very useful. And as usual abcd1234 is a hash and tag:abcd1234 is a tag. As a next step, I hope, one can augment limsync with a json API so that power users can do more complex things. I'm not sure what this would imply. The JSON API is a separate interface, that IIRC doesn't have push/pull capabilities yet. Ostensibly, any addition of push/pull capabilities should mirror the existing functionality. What I meant was that --pushref/--pullref flags are supposed to push/pull individual artifacts. This is mostly useful to selectively resolve phantoms. In the future, if limsync pushref/pushref functionality is exported to the JSON API, one can do some advanced stuff on top of the default limsync functionality. But for now, it is better not to worry about it at all! --Leo-- ___ 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] Behavior of rm, mv, and changes/extra
On Tue, Feb 28, 2012 at 07:28, Richard Hipp d...@sqlite.org wrote: Assuming we go with Fossil 2.0, can somebody propose a list of interface changes that are needed. We don't want to repeat this exercise if it can be avoided, so let's fix everything all at once. Here's a start: (1) fossil rm removes the files from the disk (2) fossil mv renames the files on disk (n+1) Ability to reference commit parents ala GIT: trunk^ is a main (non-merge) parent of the trunk; trunk^^ is parent-of-parent-of-trunk and so on. I am tired of cutting/pasting SHA1 hashes from web-gui to command-line and back. --Leo-- ___ 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] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 13:00, Tomek Kott tkott.s...@gmail.com wrote: Leo, did you know you can type 'fossil time' from the cmd line to get the last 10 commits? then just use the first 3-6 characters to reference the correct parent, that way avoiding the command line. How can I do it in a script? Referencing a parent is a fundamental DAG operation and it is missing from fossil 1.x. I hope fossil 2.0 will have something to address it. --Leo-- ___ 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] Behavior of rm, mv, and changes/extra
On Wed, Feb 29, 2012 at 16:47, Stephan Beal sgb...@googlemail.com wrote: Indeed! How does this look: i got tired of waiting ;) and went ahead with: a) removed parentUuid b) defined the first element in the parents array to be the primary parent. Thanks for your effort! Time permitting I will have a look in json API and I can write my own script to traverse the DAG, awesome! However, this basic functionality should had been in core fossil to begin with. I think the whole idea behind fossil design is to provide a single executable that does the job. I am afraid that if we start writing out-of-tree helper scripts sooner or later we will recreate GIT. BTW, can a commit have more than two parents? --Leo-- ___ 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] Behavior of rm, mv, and changes/extra
On Tue, Feb 28, 2012 at 07:59, Ramon Ribó ram...@compassis.com wrote: (1) fossil rm removes the files from the disk (2) fossil mv renames the files on disk (3) fossil settings crnl-glob ** (4) fossil update == fossil update current (5) Unlimited undo (purgin old undos after a defined number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) [1] http://fossil-scm.org/index.html/timeline?r=exp-search --Leo-- ___ 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] Behavior of rm, mv, and changes/extra
On Tue, Feb 28, 2012 at 08:22, Leo Razoumov slonik...@gmail.com wrote: On Tue, Feb 28, 2012 at 07:59, Ramon Ribó ram...@compassis.com wrote: (1) fossil rm removes the files from the disk (2) fossil mv renames the files on disk (3) fossil settings crnl-glob ** (4) fossil update == fossil update current (5) Unlimited undo (purgin old undos after a defined number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) (n+1) ability to scrub individual private branches. Right now fossil scrub --private nukes all private branches at once which IMHO is an overkill. I would like to be selective of what to remove and what remains. --Leo-- ___ 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] how to maintain a set of patches?
On Sun, Feb 26, 2012 at 04:48, Stephan Beal sgb...@googlemail.com wrote: On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov slonik...@gmail.com wrote: I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? If i'm not sorely mistaken, fossil was indeed originally designed for exactly one purpose: managing the sqlite repo. GIT was originally designed as a BitKeeper replacement for linux kernel. Then the scope broadens... --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 02:26, Gour g...@atmarama.net wrote: On Fri, 24 Feb 2012 18:13:15 -0500 Leo Razoumov slonik...@gmail.com wrote: One thing that I miss in fossil above everything else is inability to push/pull individual branches or/and individual artifacts. This is really big item on my wish list. Current fossil model has only two choices: public branches that are accessible to all, and private branches that are for-your-eyes-only. Afaik, it's possible to push private branches as well, but, I agree, Fossil is mostly 'all or nothing'. Yes, you can push *all* private branches with fossil push --private. Again, it is all or nothing proposition. In my workflow I need to push few select branches to a remote repo. For the most part I use private branches as for-my-eyes-only throw away temporaries which are cleansed with fossil scrub. Recently Brian Smith announced on this list that he is working on limsync fossil extension that allows to push/pull individual branches. http://code.linuxfood.net/pub/repo/fossil-limsync The code is still experimental and has some issues but hopefully it will stabilize soon. --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 09:17, Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. I am fine with this philosophy of no-rewriting of published history. And I am *not* asking for a git rebase equivalent. But I have to follow a work-flow that consists of a cascade of repositories. (1) PRV.fossil -- is my private repo where all my dirty laundry is stored (2) TEAM.fossil -- this is a place shared by the development team. Mistakes can be annotated as mistake and backed out as you said. (3) PUBLIC.fossil -- is a clean and shiny final result that must be devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. So far I found no way to accomodate (1)-(2)-(3) cascading work-flow. Please, advice if I am missing something (I am a novice fossil user). Previous discussions on this list suggested a new feature [1] that would allow to push/pull individual leaves or branches. If implemented it would resolve my biggest grievance with fossil. [1] http://code.linuxfood.net/pub/repo/fossil-limsync --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] feature proposal: explicitly public branches
Hi List, I am trying to accomplish a cascading work-flow Personal.fossil - Team.fossil - Public.fossil without history rewriting. Right now fossil has concept of private branches that are tagged with private. Those branches are pushed/pulled only in presence of --private option. Everything else is unequivocally public. I would like to entertain an idea of adding explicit public tag which will propagate in a way similar to private tag behavior. Push/Pull behavior will be modified to accomplish the following * If artifact is tagged as public (directly or via inheritance) then fossil push/pull will always transfer the artifact. * If artifact is neither public nor private then fossil push/pull will transfer the artifact (the same way as it is now) but fossil push/pull --public-only will ignore it. This way one can limit transfers to only those branches that are explicitly public. * If artifact is private then only fossil push/pull --private will transfer it (the same behavior as now) * An artifact cannot be simultaneously public and private This way one can have personal private repos that feed all non-private branches into a team repo. Then from the team repo only explicitly public branches make it into a clean release repo. Something along these lines permits cascading work-flow without any need for history rewriting. --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 14:19, Eric e...@deptj.eu wrote: On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote: I am fine with this philosophy of no-rewriting of published history. And I am *not* asking for a git rebase equivalent. But I have to follow a work-flow that consists of a cascade of repositories. have to? Why? Is this a case of having to step back and look at the aim of the workflow rather than assuming that it is set in stone? Eric, I hope that you realize that one size fits all is not a good design principle for a general purpose tool. (1) PRV.fossil -- is my private repo where all my dirty laundry is stored Do you need a repository for this? A repository is not a backup tool. I never mentioned backup, did I? And yes, I do need my private space for private experimentation. For instance I keep some branches where code does not yet compile. But the branches that I push to TEAM.fossil should pass a red face test, they should at least compile OK. (2) TEAM.fossil -- this is a place shared by the development team. Mistakes can be annotated as mistake and backed out as you said. (3) PUBLIC.fossil -- is a clean and shiny final result that must be devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos. Why do you need (3)? Who are you hiding stuff from? I think a clean branch is all you need. First and for most, this project is company internal. But some versions are exported outside to our external collaborators. For variety of reasons that are beyond of my control MY.fossil, TEAM.fossil and PUBLIC.fossil have to be separate. As a new fossil user I posted a question to this list on how can I establish cascading work-flow using fossil. I would appreciate if someone could tell me whether it is possible or not. I am looking for a tool that helps me and my team to do the work in my environment. I sincerely hope that fossil was not designed with only one work-flow (SQLite and fossil) in mind. Am I mistaken? --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 18:17, Gour g...@atmarama.net wrote: Heh today after more detailed reading of the docs, I've 'found out' that fossil scrub --private might be good enough as replacing hg's MQ extension...Was absent the whole day and will try tomorrow. Be aware that fossil scrub --private will remove *ALL* your private branches including the ones you created for some other purposes. --Leo-- ___ 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] how to maintain a set of patches?
On Sat, Feb 25, 2012 at 09:17, Richard Hipp d...@sqlite.org wrote: A key philosophical design principle of Fossil is no erasures. This is how business financial accounting is (or used to be) done. You write in ink. If an error is found, you annotate the erroneous entry with a note of correction and/or create new entries to undo the mistake. You do not erase or alter existing entries. And in this way one maintains an audit trail. I agree that the concept of non-rewritable history in a given repository is a good thing. But it should not preclude ability to export a subset of history (a fully connected component of the original DAG) as a separate repository (might be even with a different project-ID). If I have a book History of the World I should be able to take a chapter on American History and publish it as a book History of the USA. --Leo-- ___ 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] feature proposal: explicitly public branches
On Sat, Feb 25, 2012 at 21:30, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 02/26/12 03:09, altufa...@mail.com wrote: Why not just productize limsync? Going by what Brian Smith has written, it's a question of having time do work on it and handling a few special cases. Brian, if you need any kind of assistance, please let us know. I really want this feature. I also offered my help to Brian in limsync testing. Right now limsync still has some bugs. For instance, attempts to pull trunk from main fossil repo into limsync repo stops well short of its leaf. On the other hand, when ready limsync should be very useful. --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 24, 2012 at 02:53, Gour g...@atmarama.net wrote: On Fri, 10 Feb 2012 15:46:15 -0500 Leo Razoumov slonik...@gmail.com wrote: I am sorry if my language was not clear. Here are the diagrams: I am sorry to jump in this thread...we might soon start working on our application which is meant for niche market and therefore potential contributors although experts in the field are probably not savvy with DVCS tools, so Fossil is definitely unprecedented wiht its features and simplicity to setup use. Otoh, we're familiar with DVCS tools (starting from darcs, bzr, mtn) and now being hg user would like to not to lose any functionality from e.g. hg. My question is connected with Mercurial's MQ feature... Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Let's assume I've the same situation like above, but consider that my patches are too granular to commit each one to the trunk and would like to eg. combine P1 P3 together and then apply them as: P2' -- P1_P3' to my trunk. Is it possible to do it in Fossil? In git --rebase it is known as patch squashing. Could you, try the following (untested) fossil update E fossil merge --cherrypick P1 fossil merge --cherrypick P2 fossil merge --cherrypick P3 fossil commit --tag P1-P3.squashed If the code above does not work you can try poor-man's approach with the patch (untested) fossil co E fossil diff --from P1-parent --to P3 | patch Please, be aware that patch method does not handle addition/removal of the files. --Leo-- P.S. Maintaining patch sets, squashing/folding are everyday tasks in many popular work-flows. It would be great if fossil supports them natively rather that via ugly hacks. ___ 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] how to maintain a set of patches?
On Fri, Feb 24, 2012 at 15:12, Gour g...@atmarama.net wrote: On Fri, 24 Feb 2012 08:55:09 -0500 Leo Razoumov slonik...@gmail.com wrote: If the code above does not work you can try poor-man's approach with the patch (untested) fossil co E fossil diff --from P1-parent --to P3 | patch  Please, be aware that patch method does not handle addition/removal of the files. Actually I stand corrected. $ fossil diff --new-file --from P1-parent --to P3 | patch -E should add/remove text files automatically. Binary files, on the other hand still pose a problem. P.S. Maintaining patch sets, squashing/folding are everyday tasks in many popular work-flows. It would be great if fossil supports them natively rather that via ugly hacks. I fully agree with it. ;) Btw, may I ask you do you miss something else in Fossil as (possibly) ex-hg user? I used Hg briefly few years ago. Now I abandoned Hg completely and am an active GIT user for my heavy lifting projects. I recently discovered fossil and find it very refreshing and intriguing. One thing that I miss in fossil above everything else is inability to push/pull individual branches or/and individual artifacts. This is really big item on my wish list. Current fossil model has only two choices: public branches that are accessible to all, and private branches that are for-your-eyes-only. But I need few branches that I share with my team members but do not leak outside of the company. Fossil provides no mechanism to support such a work-flow. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] cloning and inherited private tag
Hi List, I have a repo with three brunches: trunk, BR1.prv and BR2. trunk and BR2 were created public while BR1.prv was created private. After some commits in all the branches I tag branching point of public BR2 with a propagating private tag: $ fossil tag add --propagate --raw private checkinID After that all checkins in BR2 show up as private inherited from It made me think that I effectively changed public BR2 into a private branch. But fossil thinks differently:-) When I clone the repo BR2 checkins are transferred to the clone. Apparently, BR1.prv is a true private branch (it was created private from get go and is ignored by clone) while BR2 is a fake private branch. Does it mean that propagating private tag is ignored by clone operation? Is it possible to convert public branch into private (at least temporarily) for the sake of cloning?? --Leo-- ___ 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] cloning and inherited private tag
On Mon, Feb 20, 2012 at 08:05, Richard Hipp d...@sqlite.org wrote: Right. Be sure to use the latest version of Fossil (not the latest *released* version, but rather one that you build yourself from the tip of trunk). Then if you run fossil rebuild, I think it might begin to honor your manually-added private tag. Maybe. Try it and let us know. Richard, I retried with the latest fossil trunk [fe99188e60] and no luck. Even after fossil rebuild a propagating private tag is ignored by clone operation. Below I attached a test case as a self-contained shell script. --Leo-- pub2prv-t01.sh Description: Bourne shell script ___ 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] Derived code, not to be pushed public
On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, I cloned your repository and merge limsync into trunk [6c835ea8c7c615]. The merge went very smoothly with no conflicts. I would like to use limsync for my everyday work but am afraid that it may cause data loss or repository corruption. What do you think? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
--Leo--
___
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] memory leak using fossil_getenv and fossil_mbcs_to_utf8
2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. Not really. Fossil is often run as a web-server fossil ui or fossil server and can live for months at a time. And preventing memory leaks is a good software practice regardless. --Leo-- ___ 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] memory leak using fossil_getenv and fossil_mbcs_to_utf8
2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 07:09:22AM -0500, Leo Razoumov wrote: 2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. Not really. Fossil is often run as a web-server fossil ui or fossil server and can live for months at a time. And preventing memory leaks is a good software practice regardless. It forks for every request. True. In any case, in the end of the day it is Richard's call. --Leo-- ___ 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] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Thu, Feb 16, 2012 at 09:00, Richard Hipp d...@sqlite.org wrote: I was once open to this kind of thing. But since the security risks have been pointed out to me, I'm now very reluctant to do anything like this. TH1 is secure by virtual of being minimalist. It really doesn't do much beyond simple variable substitution and if-then-else. The point is, I want to keep it that way so that it does not evolve into a security threat. We want to keep the attack surface as small as possible. I appreciate the security above all attitude. But if at some point in the future scripting will be back on discussion table I would like to introduce embedded language Lua [1], [2]. It has some really unique features that are greatly appreciated in embedded scripting world. Here just few of them: (1) Implemented in ANSI C-89 with no external dependencies, highly portable. Small code base (15 KLOC) (2) Designed as embedded language from get go. Great configurable sand-boxing (3) Very easy to interface to existing C-code. Lua can call C-functions and can be called from C-functions. (4) Very fast (faster than TCL, python, ruby, perl). For real CPU addicts there is Just-In-Time compiler LuaJIT which delivers Java-6 like performance on average and sometimes comes close to C. (5) Simple syntax, powerful semantics. [1] http://www.lua.org [2] http://en.wikipedia.org/wiki/Lua_%28programming_language%29 --Leo-- ___ 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] Seeing SBS between any checkins
On Thu, Feb 16, 2012 at 13:43, Richard Hipp d...@sqlite.org wrote: Try pressing Reload several times to convince Chrome to load the newest CSS. In order to force CSS reload go to Admin-Skins, change to any skin and then change back to the default skin. --Leo-- ___ 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] Derived code, not to be pushed public
On Thu, Feb 16, 2012 at 14:15, Brian Smith br...@linuxfood.net wrote: For what it's worth, I was working on limited branch syncing awhile back. I never got around to merging it back into the master fossil repo, but, I think at least your use case is functional.. http://code.linuxfood.net/pub/repo/fossil-limsync I really ought to finish that up and push it into the master fossil repo. Brian, please, by all means, merge your changes upstream!! pull/push individual branches opens a whole new universe of finely controlled visibility. Cloning individual branches would be nice to have but I can live without it. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] wiki full text search?
Hi All, AFAIK, fossil does not provide full-text search of wiki pages. Is there a plugin or extension that does it? So far I was only able to find a shell script in the fossil Cookbook which is just a wrapper around grep. --Leo-- ___ 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 full text search?
My comments are interspersed in-between the lines of the original message. On Wed, Feb 15, 2012 at 11:03, Richard Hipp d...@sqlite.org wrote: No full-text search (FTS) mechanism is currently provided. Of course, every Fossil repository is an SQLite database and there is a very powerful FTS index mechanism built into SQLite. So it seems like this would be a relatively simple service to provide. However, the fact that Fossil retains all historical versions of the wiki pages complicates matters. Do we index all historical versions, or just the most recent? And what about embedded documentation? Does it get indexed too? The issue is more complex with embedded documentation because there is no longer a concept of most recent. Do we index all leaves of the DAG? And if so, how do we display search results when a keyword matches in one leaf but not another? Are source code files indexed too? One idea is to not index the files themselves but rather the diff of each change, so that we can do searches for words and see all changes that add or delete those words. But I've not actually run that experiment. For simplicity one can provide indexing for few selected branches like tip of the trunk and might be few more based on user's choice. Note further that a full-text index is normally big - about 30% of the size of the source text. So adding FTS will make the repository substantially larger. This is problem not a concern for most users, but some users might object. One can disable search by default and provide a configuration screen in Admin interface. Users who do not need it will not incur any costs. Those who explicitly enable it has been warned:-) There are lots of interesting questions here. I've been meaning to explore them for years, literally. But I'm usually busy with other things... Well, ability to slice and dice repository data any which way you want is a big selling point of having a proper DB behind an SCM. Good way of searching in a repository would set fossil apart from the crowd. --Leo-- ___ 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] Bug: non-ASCII user names are corrupted
2012/2/15 Роман Донченко dxdra...@yandex.ru: Hello, I'm using (well, trying to) Fossil on Windows. My username is Роман. This happens: F:\Sourcefossil init test.sqlite project-id: c162b4ff218ffca0d4f3fe26f20a34fd5c7cf892 server-id: 01814b880714e63786ef5af7b403f5bb4fbee016 admin-user: ? (initial password is 5c1309) Note the five question marks. I've examined the DB, and it seems that the actual value recorded is just five of U+FFFD REPLACEMENT CHARACTER. Regards, Roman. Does Windows use Unicode characters for your username? As a work around, please, try $ fossil init test.sqlite -A Roman --Leo-- ___ 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] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Tue, Feb 14, 2012 at 07:53, Richard Hipp d...@sqlite.org wrote: (4) Scripts are only exchanged between repositories on a fossil clone or fossil configuration pull/sync. For the latter, detailed warnings about changes to scripts and recommendations to redo audits might be in order. IMHO fossil clone should *NOT* transfer scripts. Cloning is such a common operation that I do it all the time on a whim without much thoughts. Can easily do things that I will regret later. On the other hand, somethings like fossil configuration pull scripts ... requires just enough extra typing to make it a conscious effort. Also, it would be great to have a -n or --nochange dry-run option to tell a user whether there are any scripts to pull or push. Just my 2c --Leo-- ___ 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] comments in Fossil wiki and embedded documentation?
On Sun, Feb 12, 2012 at 19:15, Bill Burdick bill.burd...@gmail.com wrote: May I recommend my markdown plugin? It's here: http://chiselapp.com/user/zot/repository/fossil-pagedown It will let you use markdown as your wiki language and it also supports XML comments. Bill, I cloned the pagedown repo and started web interface by means of fossil ui pagedown.fossil on a fast local machine (Ubuntu-10.04). Everything works and formatting looks great! But I noticed a two seconds delay when clicking Home button (http://localhost:8080/doc/pagedown/README.wiki). Clicking any other button like Timeline or Admin has no noticeable delay whatsoever. I tried in Firefox-10 and Chrome-16 and got about the same 2 secs delay. Is it because JS is slow? --Leo-- ___ 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] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 18:30, Gé Weijers g...@weijers.org wrote: On Mon, Feb 13, 2012 at 1:49 PM, Steve Bennett ste...@workware.net.au wrote: Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. This sounds a whole lot like mobile code. I was left wondering: would it be enough to do a 'fossil clone something' to download a malware script onto my system? How is this capability secured? Are TH1 and Tcl interpreters properly sand-boxed? Otherwise, downloading and running random scripts found in some random repos does not strike me as a sound security. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] comments in Fossil wiki and embedded documentation?
I would like to put some comments into embedded doc foo.wiki page which I am editing. Standard HTML comment tag !-- comments -- does not work. What should I do? --Leo-- ___ 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] comments in Fossil wiki and embedded documentation?
On Sun, Feb 12, 2012 at 08:35, Stephan Beal sgb...@googlemail.com wrote: Fossil doesn't support comments in the wiki. See: http://fossil-scm.org/index.html/wiki_rules That's really bad for the embedded documentation. Unlike wiki embedded docs can be edited in any editor and comments are very useful to document progress, ToDo items, temporarily hide portions of the text, you name it. I think it would make sense to add standard HTML comment tag to the HTML subset Fossil understands. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH: fossil wiki markup accepts HTML comments
Please,
find attached a patch that allows to use HTML comments of the form
!-- . -- in fossil wiki markup. This feature is especially handy
for embedded documentations written using a text editor of choice.
Comments allow to annotate wiki sources in meaningful way, comment out
portions of the text, keep TODO notes, etc.
I hope the patch does not break anything.
--Leo--
Fossil-SCM patch against trunk commit:
artifact: 937514b96854b8ba378850ebab10cd893fed5d75
size: 22483 bytes
tags: trunk
type: Check-in by drh on 2012-02-11 18:25:16
comment: Further diff enhancements: Allow up to two diff-marks per line on a
side-by-side diff.
Index: src/wikiformat.c
==
--- src/wikiformat.c~0 2012-02-12 12:18:07.0 -0500
+++ src/wikiformat.c 2012-02-12 11:06:45.0 -0500
@@ -404,10 +404,34 @@ static int wikiUsesHtml(void){
static int r = -1;
if( r0 ) r = db_get_boolean(wiki-use-html, 0);
return r;
}
+/** Deals with HTML comments !--...--
+ * z points to '' char. Returns number of chars in the HTML comment
+ * or -1 if markup is not a comment.
+ */
+static int markupLength_comment(const char *z){
+ if( strncmp(z, !--, 4) == 0 ){
+int n= 4; /* points one after !-- */
+char c;
+while( 1 ){
+ for( c=z[n]; c c!='-'; c=z[++n] ); /* find next '-' */
+ if( c=='-' ){
+if( strncmp(z[n], --, 3) ){
+ return n + 3;
+}else{
+ n++;
+}
+ }else{
+return -1;
+ }
+}
+ }
+ return -1;
+}
+
/*
** z points to a character. Check to see if this is the start of
** a valid markup. If it is, return the total number of characters in
** the markup including the initial and the terminating . If
** it is not well-formed markup, return 0.
@@ -596,10 +620,14 @@ static int linkLength(const char *z){
** characters in that token. Write the token type into *pTokenType.
*/
static int nextWikiToken(const char *z, Renderer *p, int *pTokenType){
int n;
if( z[0]=='' ){
+if( (n=markupLength_comment(z)) 0 ){
+ *pTokenType= TOKEN_RAW;
+ return n;
+}
n = markupLength(z);
if( n0 ){
*pTokenType = TOKEN_MARKUP;
return n;
}else{
#EoF
___
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] PATCH: fossil wiki markup accepts HTML comments
On Sun, Feb 12, 2012 at 12:43, Richard Hipp d...@sqlite.org wrote: Comments are not supported in wiki precisely because I don't want people, especially anonymous contributors, to be able hide things from view. The idea is that all changes should be plainly visible, without having to click on the Edit table of the wiki page. Is there any way to distinguish programmatically between embedded documentation page and a wiki page? I care really only about embedded documentation. And in embedded documentation one cannot hide anything (comments or otherwise) because it is part of a commit. --Leo-- ___ 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] comments in Fossil wiki and embedded documentation?
On Sun, Feb 12, 2012 at 19:15, Bill Burdick bill.burd...@gmail.com wrote: May I recommend my markdown plugin? It's here: http://chiselapp.com/user/zot/repository/fossil-pagedown It will let you use markdown as your wiki language and it also supports XML comments. Bill, thanks you! I will give it a try. BTW, is it possible to include plain HTML in markdown? Occasionally one needs full power of the HTML. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH-v2: HTML comments in fossil wiki markup
Following up the mailing list discussion I modified my original patch
to achieve the following behavior:
(1) By default HTML comments !--...-- are *NOT* recognized in wiki
markup, exactly the same way as it is now.
(2) An Admin can switch HTML comments ON in wiki markup by means of a
new check-box in the web interface Admin-Configuration section. The
text by the check-box strongly suggests denying an anonymous user
ability of editing wiki pages if HTML comments are enabled.
I hope that with these modifications security and privacy issues
related to HTML comments have been addressed.
--Leo--
Fossil-SCM patch against trunk commit:
artifact: 937514b96854b8ba378850ebab10cd893fed5d75
size: 22483 bytes
tags: trunk
type: Check-in by drh on 2012-02-11 18:25:16
comment: Further diff enhancements: Allow up to two diff-marks per line on a
side-by-side diff.
Index: src/setup.c
==
--- src/setup.c~0 2012-02-12 22:16:47.0 -0500
+++ src/setup.c 2012-02-12 21:03:44.0 -0500
@@ -1175,10 +1175,17 @@ void setup_config(void){
@ pNote: To avoid a redirect loop or other problems, this entry must
@ begin with / and it must specify a valid page. For example,
@ b/home/b will work but bhome/b will not, since it omits the
@ leading /./p
@ hr /
+ onoff_attribute(Honor HTML comments in wiki markup,
+wiki-html-comments, wiki-html-comments, 0);
+ @ pAllow HTML type comments lt;!--...--gt; in wiki markup (both wiki pages)
+ @ and embedded documentation. /p
+ @ pstrongCAUTION:/strong You are advised to deny anonymous user ability to
+ @ edit wiki pages to prevent hidden text in wiki sources. /p
+ @ hr /
onoff_attribute(Use HTML as wiki markup language,
wiki-use-html, wiki-use-html, 0);
@ pUse HTML as the wiki markup language. Wiki links will still be parsed
@ but all other wiki formatting will be ignored. This option is helpful
@ if you have chosen to use a rich HTML editor for wiki markup such as
Index: src/wikiformat.c
==
--- src/wikiformat.c~0 2012-02-12 22:16:47.0 -0500
+++ src/wikiformat.c 2012-02-12 21:06:50.0 -0500
@@ -404,10 +404,42 @@ static int wikiUsesHtml(void){
static int r = -1;
if( r0 ) r = db_get_boolean(wiki-use-html, 0);
return r;
}
+/** Returns true if HTML comments !--.-- are honored by the wiki markup
+ */
+static int wiki_allows_HTML_comments(void){
+static int r= -1;
+if( r0 ){ r = db_get_boolean(wiki-html-comments, 0); }
+return r;
+}
+
+/** Deals with HTML comments !--...--
+ * z points to '' char. Returns number of chars in the HTML comment
+ * or -1 if markup is not a comment.
+ */
+static int markupLength_comment(const char *z){
+ if( strncmp(z, !--, 4) == 0 ){
+int n= 4; /* points one after !-- */
+char c;
+while( 1 ){
+ for( c=z[n]; c c!='-'; c=z[++n] ); /* find next '-' */
+ if( c=='-' ){
+if( strncmp(z[n], --, 3) ){
+ return n + 3;
+}else{
+ n++;
+}
+ }else{
+return -1;
+ }
+}
+ }
+ return -1;
+}
+
/*
** z points to a character. Check to see if this is the start of
** a valid markup. If it is, return the total number of characters in
** the markup including the initial and the terminating . If
** it is not well-formed markup, return 0.
@@ -596,10 +628,15 @@ static int linkLength(const char *z){
** characters in that token. Write the token type into *pTokenType.
*/
static int nextWikiToken(const char *z, Renderer *p, int *pTokenType){
int n;
if( z[0]=='' ){
+if( wiki_allows_HTML_comments()
+(n=markupLength_comment(z)) 0 ){
+ *pTokenType= TOKEN_RAW;
+ return n;
+}
n = markupLength(z);
if( n0 ){
*pTokenType = TOKEN_MARKUP;
return n;
}else{
#EoF
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Valentine's Day wish
I recently discovered fossil and so far I like it very much. It does most of the things I need and does them very well. If I would be asked to name one feature that fossil still lacks I would name my favorite one: - Ability to push one branch at a time. Right now fossil push is all-or-nothing proposition -- all public branches are pushed, all private branches are ignored. Ability to push individual (public) branches would allow to easily facilitate many workflows that are now impossible or very cumbersome. I hope this feature can make it onto the TODO list and be eventually implemented. --Leo-- ___ 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] stdout flush on external diff command
2012/2/10 Lluís Batlle i Rossell vi...@viric.name: Hello, But if I run: $ fossil diff | less First go the outputs of all the diff commands, and at the end, all the Index:.. and === in a row. I think the diff_print_index() function that writes the Index: and the === needs a flush, to fix that. This problem was fixed in the trunk on 2012-02-04 14:58:29 commit [dc96d73dd06ef] --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to maintain a set of patches?
I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. Git has git rebase, Mercurial has hg mq. What solution does fossil offer? --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 15:28, Richard Hipp d...@sqlite.org wrote: On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov slonik...@gmail.com wrote: I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. If you apply a patch once, it is on that branch. To reapply a patch would be a no-op, since the changes are already present on the branch, unless for some reason you had backed the patch out since the prior application. Perhaps I don't understand what you are asking for? I am sorry if my language was not clear. Here are the diagrams: I start my-patches branch from trunk commit B and organize my changes as a set of patches each one addressing specific issue. AB-- = trunk \-P1--P2--P3 = my-patches Then after some time trunk moves forward ABCDE-- = trunk \-P1--P2--P3 = my-patches Now I want to reapply (I am avoiding word rebase) my patches P1 through P3 to the trunk commit E to achieve something like this /-P1'--P2'--P3' = my-patches ABCDE-- = trunk \-P1--P2--P3 = closed I am effectively rebasing my patches to the new trunk commit and I will close the leaf on the old branch. If I use merge then all three patches will be squashed into a single change-set. I would rather prefer to keep them as individual patches. --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 15:54, Richard Hipp d...@sqlite.org wrote: fossil update D fossil merge --cherrypick P1 fossil commit --branch P1p fossil merge --cherrypick P2 fossil commit --tag P2p fossil merge --cherrypick P3 fossil commit --tag P3p Richard, thanks for the suggestion. Will I have to manually provide commit messages for each commit? --Leo-- ___ 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] how to maintain a set of patches?
On Fri, Feb 10, 2012 at 18:38, Richard Hipp d...@sqlite.org wrote: On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov slonik...@gmail.com wrote: I hope that fossil could pre-populate the message with the text from the commit that is being cherry-picked. It would save lots of typing. A very reasonable suggestion. The latest trunk version of fossil does this. http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1 Wow! That was fast (under 2 hours for a feature)!! Thanks, --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil commit failure after merge
Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --Leo-- merge-conflict.sh Description: Bourne shell script ___ 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] fossil commit failure after merge
On Thu, Feb 9, 2012 at 23:27, altufa...@mail.com wrote: +1 I faced this a couple of days back and had to perform an incorrect commit. Thanks for confirming my observations. I think this is a serious issue. I try to follow a policy of never committing to a public branch code that does not compile. Now this policy cannot be followed in some cases. And secondly such inconsistent commits break bisect. --Leo-- - Original Message - From: Leo Razoumov Sent: 02/10/12 03:39 AM To: Fossil SCM user's discussion Subject: [fossil-users] fossil commit failure after merge Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --Leo-- ___ 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] _FOSSIL_ file grows large
On Tue, Feb 7, 2012 at 19:26, Richard Hipp d...@sqlite.org wrote: The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ Hmm, I just compliled/installed sqlite-3.7.10 from its fossil repo and it did build sqlite3 executable but no sqlite3_analyzer. Interestingly, target to build sqlite3_analyzer is present in sqlite-3.7.10's Makefile but it is not part of the install. I will modify Makefile and will try to build it that way. --Leo-- ___ 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] _FOSSIL_ file grows large
On Tue, Feb 7, 2012 at 19:26, Richard Hipp d...@sqlite.org wrote: On Tue, Feb 7, 2012 at 7:24 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I wonder why _FOSSIL_ file grows so fast. I did some little work with a clone of fossil source code repository (23MB) and over space of two days _FOSSIL_ reached 10MB. What gives? The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ show you? Which tables are using the most space. Maybe it just needs to be vacuumed? All right. I compiled sqlite3_analyzer. The output is attached below. BTW, how do I vacuum a sqlite database?? I heard a lot about sqlite but I never used it before (terrible oversight). --Leo-- sqlite3_analyzer.out.bz2 Description: BZip2 compressed data ___ 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] _FOSSIL_ file grows large
On Wed, Feb 8, 2012 at 11:05, Richard Hipp d...@sqlite.org wrote: Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. I generally don't stress over a 10MB file on my 1TB disk drive, though... Richard, thanks for the tip. After vacuuming _FOSSIL_ size reduced from 9.7MB to 160KB. Speaking of disk usage. Here at ATT Labs I am running multiple virtual machines each having a shoe-string budget of 10 to 20GB disk space per machine. On that scale 10MB times number of open fossil repos is noticeable. --Leo-- ___ 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] _FOSSIL_ file grows large
On Wed, Feb 8, 2012 at 11:05, Richard Hipp d...@sqlite.org wrote: Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. A cursory look into http://www.sqlite.org/pragma.html#pragma_auto_vacuum puzzles me: Auto-vacuuming is only possible if the database stores some additional information that allows each database page to be traced backwards to its referrer. Therefore, auto-vacuuming must be turned on before any tables are created. It is not possible to enable or disable auto-vacuum after a table has been created. Does VACUUM command also rebuild a database or it should be done separately? --Leo-- ___ 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] In-line versus side-by-side diffs
On Mon, Feb 6, 2012 at 23:26, Richard Hipp d...@sqlite.org wrote: A lot of people have been telling me that they prefer the unified or context style in-line diffs over side-by-side diffs. And I have to admit that sometimes an in-line diff is easier to read and understand. But side-by-side diffs, especially with the recent enhancements, sometime give a much clearer picture of what changed. I find both types of diffs complementary to each other and I am happy that fossil provides both. Traditional unified diffs are useful to generate and review patches while side-by-side diffs provide a great bird's eye view of the the battle field. Fossil is unique that it generates all these different views out of the box from the same executable while the competition would require installing/configuring 3-rd party stand-alone applications to achieve the same results. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH: fossil diff --brief outputs only whether files differ
Hi Richard,
please, find attached a patch that introduces --brief (short -q)
option to fossil diff that acts analogous to regular diff --brief
or diff -q. It suppresses diff contents and outputs just the file
names that differ. Output format is similar to fossil changes.
But unlike fossil changes fossil diff -q can take --from and --to
options and, thus, compare arbitrary commits.
Affects of -q/--brief are limited to the internal diff implementation
and is noop if external diff is used.
The patch is against the trunk [b1530c29ab].
Thanks,
--Leo--
Fossil-SCM patch against trunk commit:
artifact: b1530c29ab659a56f488e4386f242eb758858f22
tags: trunk
type: Check-in by drh on 2012-02-07 04:15:41
comment: Add chunk number fragment marks to HTML diff output.
Index: src/diffcmd.c
==
--- src/diffcmd.c~0 2012-02-07 07:49:53.0 -0500
+++ src/diffcmd.c 2012-02-07 07:32:34.0 -0500
@@ -19,15 +19,27 @@
*/
#include config.h
#include diffcmd.h
#include assert.h
+/* Flag to supress diff output if -q or --brief option is given
+ * to the internal diff command
+ */
+static int hasQFlag = 0;
+
/*
** Print the Index: message that patches wants to see at the top of a diff.
+** If -q/--brief then print CHANGED instead.
*/
void diff_print_index(const char *zFile, int diffFlags){
- if( (diffFlags DIFF_SIDEBYSIDE)==0 ){
+if( (diffFlags DIFF_SIDEBYSIDE) ){
+ return;
+} else if( hasQFlag ){
+ char *z = mprintf(CHANGED %s\n, zFile);
+ fossil_print(%s, z);
+ fossil_free(z);
+ } else {
char *z = mprintf(Index: %s\n%.66c\n, zFile, '=');
fossil_print(%s, z);
fossil_free(z);
}
}
@@ -35,10 +47,12 @@ void diff_print_index(const char *zFile,
/*
** Print the +++/--- filename lines for a diff operation.
*/
void diff_print_filenames(const char *zLeft, const char *zRight, int diffFlags){
char *z = 0;
+ if( hasQFlag ){ return; } /* don't print anything in -q/--brief mode */
+
if( diffFlags DIFF_SIDEBYSIDE ){
int w = diff_width(diffFlags);
int n1 = strlen(zLeft);
int x;
if( n1w*2 ) n1 = w*2;
@@ -89,11 +103,11 @@ void diff_file(
/* Compute and output the differences */
blob_zero(out);
text_diff(pFile1, file2, out, diffFlags);
if( blob_size(out) ){
diff_print_filenames(zName, zName2, diffFlags);
- fossil_print(%s\n, blob_str(out));
+ if( !hasQFlag ){ fossil_print(%s\n, blob_str(out)); }
}
/* Release memory resources */
blob_reset(file2);
blob_reset(out);
@@ -148,11 +162,11 @@ void diff_file_mem(
Blob out; /* Diff output text */
blob_zero(out);
text_diff(pFile1, pFile2, out, diffFlags);
diff_print_filenames(zName, zName, diffFlags);
-fossil_print(%s\n, blob_str(out));
+if( !hasQFlag ){ fossil_print(%s\n, blob_str(out)); }
/* Release memory resources */
blob_reset(out);
}else{
Blob cmd;
@@ -199,10 +213,11 @@ static void diff_one_against_disk(
historical_version_of_file(zFrom, blob_str(fname), content, isLink, 0, 0);
if( !isLink != !file_wd_islink(zFrom) ){
fossil_print(cannot compute difference between
symlink and regular file\n);
}else{
+diff_print_index(zFileTreeName, diffFlags);
diff_file(content, zFileTreeName, zFileTreeName, zDiffCmd, diffFlags);
}
blob_reset(content);
blob_reset(fname);
}
@@ -283,11 +298,11 @@ static void diff_all_against_disk(
}else if( isNew ){
fossil_print(ADDED%s\n, zPathname);
srcid = 0;
if( !asNewFile ){ showDiff = 0; }
}else if( isChnged==3 ){
- fossil_print(ADDED_BY_MERGE %s\n, zPathname);
+ fossil_print(ADDED_BY_MERGE %s\n, zPathname);
srcid = 0;
if( !asNewFile ){ showDiff = 0; }
}
if( showDiff ){
Blob content;
@@ -403,27 +418,27 @@ static void diff_all_two_versions(
cmp = -1;
}else{
cmp = fossil_strcmp(pFromFile-zName, pToFile-zName);
}
if( cmp0 ){
- fossil_print(DELETED %s\n, pFromFile-zName);
+ fossil_print(DELETED %s\n, pFromFile-zName);
if( asNewFlag ){
diff_manifest_entry(pFromFile, 0, zDiffCmd, diffFlags);
}
pFromFile = manifest_file_next(pFrom,0);
}else if( cmp0 ){
- fossil_print(ADDED %s\n, pToFile-zName);
+ fossil_print(ADDED%s\n, pToFile-zName);
if( asNewFlag ){
diff_manifest_entry(0, pToFile, zDiffCmd, diffFlags);
}
pToFile = manifest_file_next(pTo,0);
}else if( fossil_strcmp(pFromFile-zUuid, pToFile-zUuid)==0 ){
/* No changes */
pFromFile = manifest_file_next(pFrom,0);
pToFile = manifest_file_next(pTo,0);
}else{
- /* fossil_print(CHANGED %s\n, pFromFile-zName); */
+ /* fossil_print(CHANGED %s\n, pFromFile-zName); */
diff_manifest_entry(pFromFile, pToFile, zDiffCmd, diffFlags);
pFromFile =
[fossil-users] _FOSSIL_ file grows large
Hi List, I wonder why _FOSSIL_ file grows so fast. I did some little work with a clone of fossil source code repository (23MB) and over space of two days _FOSSIL_ reached 10MB. What gives? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Help needed: fossil clone user authentication does not seem to work over ssh
Hi List, I am trying to clone a repository over ssh complete with all the private branches by means of $ fossil clone --private ssh://username:pass@hostname/path-to-Repo my.fossil Prior to doing that I set Private flag for username on the remote repo using the web interface. The clone operation fails with the message: Error: not authorized to sync private content However, when I enable Private flag on user nobody everything works as expected. It makes me think that somehow my clone session is always conducted as a nobody on remote server. Is there anyway to trace/debug fossil user credentials on the remote end, some sort of verbose/debug output? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] BUG: clone/pull/push over SSH always use nobody privileges
Hi Richard, It seems that clone/push/pull over ssh ignore ssh://USER:PASSWORD settings and always connect to a remote fossil end as nobody. As a result * One cannot push anything to a remote repo (unless nobody is granted developer privileges) * clone/pull private branches does not work (unless nobody is granted Private privileges) These problems were recently reported to this mailing list by several people [1-4]. Is there a workaround or a bug fix? [1] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-January/007890.html [2] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008121.html [3] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008122.html [4] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008106.html Thanks, --Leo-- ___ 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] BUG: clone/pull/push over SSH always use nobody privileges
On Mon, Feb 6, 2012 at 09:24, Leo Razoumov slonik...@gmail.com wrote:
Hi Richard,
It seems that clone/push/pull over ssh ignore ssh://USER:PASSWORD
settings and always connect to a remote fossil end as nobody.
Richard,
Thank you very much for pushing a prompt fix to the trunk [a928c89cb18].
It solves SSH authentication problem very elegantly. If one has ssh
access to the repository then user privileges are mute anyway, for one
can simply copy the whole repository file from the remote to a local
host.
Along the same lines I should be able to clone private branches if my
source URL is a regular file. Unfortunately, as it stands now
clone_cmd function always calls delete_private_content() when the
source URL is a file.
Please, find below a simple patch which preserves private content if
clone is called with option --private.
%%%%
Index: src/clone.c
==
--- src/clone.c~0 2012-02-06 17:38:58.0 -0500
+++ src/clone.c 2012-02-06 17:19:49.0 -0500
@@ -119,11 +119,13 @@ void clone_cmd(void){
VALUES('server-code', lower(hex(randomblob(20))),now());
REPLACE INTO config(name,value,mtime)
VALUES('last-sync-url', '%q',now());,
g.urlCanonical
);
-delete_private_content();
+if( !bPrivate ){
+ delete_private_content();
+}
shun_artifacts();
db_create_default_users(1, zDefaultUser);
if( zDefaultUser ){
g.zLogin = zDefaultUser;
}else{
%%%%
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to clone private branches over ssh?
Hi List, I am trying to clone my repository over SSH complete with all my private branches. So far I have had no luck. I compiled fossil on Ubuntu-10.04 from its current trunk version and that's what I am getting: $ fossil clone --private ssh://leor@pionL2://home/leor/Devel/Fossil/LR.fossil LR.fossil password for leor: ssh -e none -T -p leor@pionl2 Bytes Cards Artifacts Deltas Sent: 73 1 0 0 Received: 5001001 15798 2003 5914 Sent: 91 2 0 0 Error: not authorized to sync private content Received: 6225987 1 0 0 Total network traffic: 575 bytes sent, 11227422 bytes received fossil: server returned an error - clone aborted What options should I enable in fossil-Admin to permit sync of private branches? I randomly tried several seemingly relevant options under User, Acess but to no avail. BTW, cloning without --private works fine. --Leo-- ___ 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] how to clone private branches over ssh?
On Sun, Feb 5, 2012 at 12:16, Richard Hipp d...@sqlite.org wrote: On Sun, Feb 5, 2012 at 12:03 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I am trying to clone my repository over SSH complete with all my private branches. So far I have had no luck. What options should I enable in fossil-Admin to permit sync of private branches? I randomly tried several seemingly relevant options under User, Acess but to no avail. You need to enable the Private privilege on the user that you are logging in as. Still no luck even after I enabled Private privilege and am providing correct fossil login password when clone asks me. The only way I get private branch clone working is to configure ssh to set REMOTE_USER environment variable on the remote end. But such a ssh trickery is a poor solution for it requires root access to sshd configuration file. --Leo-- ___ 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] Derived code, not to be pushed public
2012/2/5 Lluís Batlle i Rossell vi...@viric.name: Hello, I wonder how people keep code based on a public fossil repository, but without making the derivaiton public. Of course, with the ability to keep all in sync easily, as if all was in a single VCS. There are the private branches... but I wonder if there are other approaches used by people in this list. I think maybe the private branches feature is not very tested in fossil. IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. --Leo-- ___ 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] Retro side-by-side diffs
On Sat, Feb 4, 2012 at 10:36, Richard Hipp d...@sqlite.org wrote: On Sat, Feb 4, 2012 at 10:24 AM, Leo Razoumov slonik...@gmail.com wrote: Retro diff (2) looks really bad in Google Chrome-16 and in Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04). Huh. On Ubuntu 11.10 running the latest Firefox sources (compiled just this morning) it looks fine: http://www.fossil-scm.org/ss1.gif Can anybody explain the difference? Is there something wrong with the CSS? I played a bit with Firefox-10 on Linux. I seem to get a good layout when set font-sizes in Preferences to 12pt. When, on the other hand, I increase font sizes to 16 or 18pt then the layout got messed up. I am using hi-res monitor and 12pt is really small. I know very little about CSS. Is it possible to make a layout that does not break when a user changes default font size?? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
