Re: [fossil-users] fossil CLI tricks: interrupting a commit message
On Tue, Jun 17, 2014 at 6:49 AM, B Harder brad.har...@gmail.com wrote: Remember that the buffer is only one level deep, though. A subsequent ^W, ^K , etc will clobber the previous contents. Almost: try 2x (NON-consecutively) ctrl-k (or ctrl-w, or whatever), then 1x ctrl-y, then Esc-y. Esc-y acts upon the previous Ctrl-Y, and subsequent Esc-y's pull back one proceeding entry further from the yank buffer. Nonetheless, it is easy to lose text this way, so i recommend the comment method over the yank buffer. ($ is shell prompt). : is a command that consumes it's arguments and returns true. Another nice one. At times i've seen in-script docs done that way: : EOF docs go here... EOF Not sure why one would do it that way, though. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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 CLI tricks: interrupting a commit message
On Tue, 17 Jun 2014, Nico Williams wrote: On Mon, Jun 16, 2014 at 11:49 PM, B Harder wrote: Remember that the buffer is only one level deep, though. A subsequent ^W, ^K , etc will clobber the previous contents. Along lines of Stephan Beals method, I use : preceding the fossil command. So: $ : fossil ci -m 'some msg' ($ is shell prompt). While we're on stupid shell tricks... If you setup your $PS1 and PS2 just so you can make your commands safe to cut-n-pase. Set $PS1 to something that starts with : and ends with ;, and set $PS2 to just whitespace. I do something similar with the sqlite3 shell... And if you setup $EDITOR or $VISUAL :-) make a habit, 'f ci'Enter. For example, interrupt in VIM is just ':cq'. I'm sure the same exit(1) is possible in other editors. If you wanted your text will be saved in ci-comment-.txt. Advantages: 1) No noise in shell history. Really, f ci -m ... fills the history by a painful noise, ^R (reverse-i-search) for illegal check-in and hit Enter causes ... Edit check-in comment. 2) $EDITOR is a place to think a bit more about check-in text and check-in itself. 3) Good $EDITOR lets to automate some things, e.g. spelling, formatting, etc. No Editor War here. I just believe that at least $EDITOR is CLI. Excuse my 2-3 cents. Happy Fossiling! Sergei ___ 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 CLI tricks: interrupting a commit message
This thread is hilarious. I thought I was pretty old-school -- I use vi, xterm, fvwm2, and other tools written by my forebears around the time when I was born. I get made fun of by people twice my age for my dev toolkit. But even *I* will have two terminals up concurrently -- so that I can write my check-in comment in terminal 1 while looking at my diff in terminal 2. I must be one of those millennials with their newfangled contraptions and their damn music. -- Eric A. Rubin-Smith ___ 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 CLI tricks: interrupting a commit message
On Jun 17, 2014 8:42 AM, Eric Rubin-Smith eas@gmail.com wrote: This thread is hilarious. I thought I was pretty old-school -- I use vi, xterm, fvwm2, and other tools written by my forebears around the time when I was born. I get made fun of by people twice my age for my dev toolkit. But even *I* will have two terminals up concurrently -- so that I can write my check-in comment in terminal 1 while looking at my diff in terminal 2. I must be one of those millennials with their newfangled contraptions and their damn music. Excellent point, though sometimes (occasionally) multiple terminal windows are less practical than stashing the command line. :) ___ 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] Working with large repository
On Mon, 16 Jun 2014 23:08:22 +0200 Baptiste Daroussin baptiste.darous...@gmail.com wrote: Hi, I just want to share some feedback, for fun I tried to convert some of the FreeBSD repositories to fossil to see how it performs I first tried the FreeBSD Documentation repository, to go the easy way I took the FreeBSD git mirror (https://github.com/freebsd/freebsd-doc and run git fast-export --full-tree --all | fossil import --git ../doc.fossil The worked pretty well, and I manage to convert in a few hour the repo, the result it very usable (that wasn't the case a few years ago, some operations where slow) Result is available here: https://fossil.etoilebsd.net/doc if some want to play. At the same time I decided to try with ports and base repository which I would have expected to be a bit more complicated I cloned: https://github.com/freebsd/freebsd and https://github.com/freebsd/freebsd-ports I run the same command for the conversion git fast-export --full-tree --all | fossil import --git ../ports.fossil both are now running for more than 70H and still not finished!!! consuming 100% CPU This is running on pretty descent hardware. hw.model: Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz I guess I would have to run a svndump imported manually if I want a slightly faster conversion to happen, and given how the incremental import works with fossil import --git I cannot imagine running a fossil mirror using that tool. If anyone has ideas on how I can maintain a mirror more easily, tips welcome I tried the same in 2012 an early 2013 without --full-tree, the worse problem I had wasn't the time expended but the size of fossil file while importing. I tweaked fossil import to use 512MB-2GB of sqlite3 cache making it faster. I didn't import from git directly, I splitted it in 2 phases: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil This way I'm less IO and CPU bounded, Check my email on this list 1st of July 2013. Bapt --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Working with large repository
On Tue, Jun 17, 2014 at 5:30 PM, Eduardo Morras emorr...@yahoo.es wrote: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil That is a _very_ interesting trick. Question to you both: do you know if fossil has generated any delta manifests in the import? By default fossil does not generate delta manifests, but they can potentially save space for large repos. Once fossil has generated _one_ delta, it will allow itself to generate more, but by default it will never generate any. A delta can be forced at commit time with --delta, but i don't know if the git import feature (never needed it) supports something like that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Working with large repository
I'll be able to tell you if ever this conversion finishes :) right now 88H and still running @eduardo at the time iirc the git export did not contain the full history but a small part of it, right now for sure it contains the full history 2014-06-17 17:39 GMT+02:00 Stephan Beal sgb...@googlemail.com: On Tue, Jun 17, 2014 at 5:30 PM, Eduardo Morras emorr...@yahoo.es wrote: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil That is a _very_ interesting trick. Question to you both: do you know if fossil has generated any delta manifests in the import? By default fossil does not generate delta manifests, but they can potentially save space for large repos. Once fossil has generated _one_ delta, it will allow itself to generate more, but by default it will never generate any. A delta can be forced at commit time with --delta, but i don't know if the git import feature (never needed it) supports something like that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil CLI tricks: interrupting a commit message
On 6/17/14, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 17, 2014 at 6:49 AM, B Harder brad.har...@gmail.com wrote: Remember that the buffer is only one level deep, though. A subsequent ^W, ^K , etc will clobber the previous contents. Almost: try 2x (NON-consecutively) ctrl-k (or ctrl-w, or whatever), then 1x ctrl-y, then Esc-y. Esc-y acts upon the previous Ctrl-Y, and subsequent Esc-y's pull back one proceeding entry further from the yank buffer. Nice! As a BSD user though, I feel compelled to point out this looks like a readline[1] feature, and not an editline[2] feature. So it works with bash (and likely other readline linked progs), it doesn't work w/ (e.g.) NetBSDs /bin/sh. Good tip though. [1] http://en.wikipedia.org/wiki/GNU_Readline [2] http://thrysoee.dk/editline/ Nonetheless, it is easy to lose text this way, so i recommend the comment method over the yank buffer. ($ is shell prompt). : is a command that consumes it's arguments and returns true. Another nice one. At times i've seen in-script docs done that way: : EOF docs go here... EOF Not sure why one would do it that way, though. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Working with large repository
On Tue, 17 Jun 2014 17:39:45 +0200 Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 17, 2014 at 5:30 PM, Eduardo Morras emorr...@yahoo.es wrote: git fast-export xz -vv --lzma2=preset3,dict=256MiB git.xz xzcat -vv git.xz fossil import git.fossil That is a _very_ interesting trick. You can pause it, view % of work done, etc... Question to you both: do you know if fossil has generated any delta manifests in the import? By default fossil does not generate delta manifests, but they can potentially save space for large repos. Once fossil has generated _one_ delta, it will allow itself to generate more, but by default it will never generate any. A delta can be forced at commit time with --delta, but i don't know if the git import feature (never needed it) supports something like that. Fossil rebuilds repository after the import and file size shrinks a lot, don't know if it's because delta encoding or something else. The openbsd import to fossil file has +300GB, and shrinks to 1.5GB after rebuild. Didn't have more time to dive in it. A final note, the import is one big transaction. -- - stephan beal --- --- Eduardo Morras emorr...@yahoo.es ___ 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 CLI tricks: interrupting a commit message
On Tue, Jun 17, 2014 at 7:24 PM, B Harder brad.har...@gmail.com wrote: Nice! As a BSD user though, I feel compelled to point out this looks like a readline[1] feature, and not an editline[2] feature. So it works with bash (and likely other readline linked progs), it doesn't work w/ (e.g.) NetBSDs /bin/sh. i've always assumed it came from emacs (where i learned it), but it's very possibly a readline feature emacs adopted. Then again, what _hasn't_ emacs adopted somewhere in some add-on? Caveat: when you Esc-y you lose the top-most item in the yank buffer (the one Ctrl-y yanked). i don't know of any way to restore them once you Esc-y past them. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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 CLI tricks: interrupting a commit message
On Jun 17, 2014 10:47 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 17, 2014 at 7:24 PM, B Harder brad.har...@gmail.com wrote: Nice! As a BSD user though, I feel compelled to point out this looks like a readline[1] feature, and not an editline[2] feature. So it works with bash (and likely other readline linked progs), it doesn't work w/ (e.g.) NetBSDs /bin/sh. i've always assumed it came from emacs (where i learned it), but it's very possibly a readline feature emacs adopted. Then again, what _hasn't_ emacs adopted somewhere in some add-on? Well, it's readlines (editlines) emacs editor emulation. You can also set it up to be vi-like: In ~/.inputrc: set editing-mode vi --- ...so, you're not incorrect to think of it as an emacs feature (it is), but this is readlines emacs-inspired implementation. Caveat: when you Esc-y you lose the top-most item in the yank buffer (the one Ctrl-y yanked). i don't know of any way to restore them once you Esc-y past them. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Alternative approach to disambiguation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Right now, ambiguous artifact IDs are handled by showing a page listing all (*) the artifacts with the prefix. I suggest jumping straight to the oldest artifact with the prefix, but showing the alternatives on the page. Perhaps it would be easier to simply show a warning that there is ambiguity, and link to a disambiguation page like Fossil currently has. At the time an abbreviated artifact ID is generated (e.g. when making timeline HTML, from which the user may copy into a checkin comment), it's unambiguous. I should hope. Later checkins and other activity may collide with those old abbreviations, but we can safely disambiguate by assuming the oldest is what was intended, since again it was unambiguous at the time it was generated. As for the other possible cause of ambiguity (the user shortening the artifact ID without checking for ambiguity), that's (maybe?) a rarer case but is still handled via the alternatives list. What does oldest mean? To be accurate, it would have to ignore date overrides and instead look at when the artifact was actually entered into the database, rather than where it shows up on the timeline. I'm making the assumption that every time an abbreviated artifact ID is displayed in any form, the code first checks if it's ambiguous or not, then picks a longer form if needed, adding a certain number of digits each time it's not unique. (*) Is this really true of all types? I seem to remember there being some artificial partitioning and differences in handling various artifact types. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToLEKAAoJELtYwrrr47Y42NsIANJEoFhHtqpH4RwiEyCidmKn G2v7IeD/OzwamA0PhExy1NtyvPJ0hoNrRgm73UAJKKPLkNj3EXb0jD0jkPiBLa0I SRyOA+kVuysloSfvUXCN9emhxjmEPinPiOD1+9KcAKXzkRTsSBp0OGI9Hx4Inb0i 4ElDiG5hqRWu1jtuvaESeHL/E4RtpsWgj+iCrSX/KjfeaRmjvGgVCzJlASmRthe9 AQ9G83rHZh4uiCQpD0vbDt4FSDSGZs+zK40pqet7UAWw3VCOSs1gZ6KPAW7tMoQi akMKdDb0Z1YxeBV1lLGEPbvj6cMLADGLgX3w0DujQP2x6ZKiB8OEIx9sphSfSDo= =cyuB -END PGP SIGNATURE- ___ 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] Number of digits in checkin abbreviation
On Tue, Jun 17, 2014 at 4:54 PM, Andy Goth andrew.m.g...@gmail.com wrote: At this moment, http://www.sqlite.org/cgi/src/timeline?y=ci shows these two checkins (others too, of course): [b500f2a097] Leaf: Fix a missing space in a wheretrace comment. No changes to production code. (user: drh, tags: trunk) [38965484199153e] Add the likely() function for symmetry with unlikely(). The likely(X) function means the same thing as likelihood(X,0.9375). (user: drh, tags: trunk) I think the rule is to show a minimum of ten digits, but more if necessary until the hash code contains at least on digit between 'a' and 'f'. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil CLI tricks: interrupting a commit message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/16/2014 3:24 PM, Stephan Beal wrote: 1) Move your cursor to the beginning of the line. In Bash-like shells that's normally Ctrl-A, but many terminals support the Home key as well. 2) Type the '#' character (shift-3 on a US keyboard). That's the shell's comment-to-end-of-line marker. 3) Tap ENTER I do this a lot in bash. This almost works in csh (which I am regrettably forced to use). Yes, the command is not executed but is still stuffed in the history buffer, so the requirement is met. But it also generates an annoying error message about # not being found. csh doesn't understand comments when typed interactively. yukonbob's trick with : does work in csh without complaint. Thanks! I will definitely keep it in mind. Or, in the Bash shell, simply: 1) Tap Escape, then type the # character. That does all 3 of the above at once. Neat, I didn't know about this. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToPLTAAoJELtYwrrr47Y43Y0H/jJLBWMy+XATUgUDa+K585sp DcYC3QooXTuDwtX+45AmT3BbaNARDs0rBYK+85+7GgoUA1yAeAsV55tAyxK/JHZR /psym9LX0S4q7ggvbymOqSCZ+QuzWpMSYEmSaIXGinvn8/o7eHj6YNAvF4A9wsNx lopqK5AlrhQebc8DxDk6paVHYIzxwShAp1kMmRpkCjegT2PnkfxbqfqhxMYZLz0o 2gqXUrRunofwmyNOi2kPjPoi9DMAmGQuwSGUp0+FDrrVs/qhAKIZpH8JKdgWNe0z cll7jDjLhU0Z2MR9rECVqvCj+AOzKBoptnttepgbHTEHblJNELUoTgkoJUp+k4g= =+8vk -END PGP SIGNATURE- ___ 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 CLI tricks: interrupting a commit message
On 2014-06-17 22:00, Andy Goth wrote: This almost works in csh (which I am regrettably forced to use). Yes, the command is not executed but is still stuffed in the history buffer, Maybe I'm OCD or something, but if I have to do it more than twice, it gets embodied as a script. :) -- Thanks, DougF (KG4LMZ) ___ 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 CLI tricks: interrupting a commit message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/17/2014 9:40 PM, Doug Franklin wrote: On 2014-06-17 22:00, Andy Goth wrote: This almost works in csh (which I am regrettably forced to use). Yes, the command is not executed but is still stuffed in the history buffer, Maybe I'm OCD or something, but if I have to do it more than twice, it gets embodied as a script. :) The purpose of the exercise was to interrupt a command being typed, stash it somewhere handy (the history buffer works well), then be able to come back to it a short time later when the information needed to finish typing the command is in hand. I don't see any role for scripts in this operation, not unless someone wants to make a script to collect half-typed commands, thereby duplicating the (perhaps unintentional) shell feature discussed in this thread. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToR+MAAoJELtYwrrr47Y4YgsH/3Hp9+4FgNtBpS56QHfSOD7h yA3XbD2MP1tTiiUlbkWlFsEWkGeljShcewIhWxG5h4zzpw5bvb5axH3gni26Z1dJ 6lgW9+iOynyGbsdouFyYTJHtT8YKRJhq10vhiMMpII26n+MrgDhEJBFBDXkab1K5 85oxvgNM70xVHGccja2gfcBvSutcD7W8k2rvfQOaAM8+odhdXLL+Xs9X2GVAf5gs RMtpGT4g2qKgpNtT8RDS9+H6tHNcyT1Bj/NIjlNNcnWfjIRJsXXG2OWj/LhbVvNZ NWiDXC/qdxaGFOmKYrJoLzYJBJ+F40MiXxTHAl1QLjxYckvLl7gTl/EIJpXV47E= =IcYY -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
