Re: [fossil-users] Uploads to 'files' page?
On Fri, Sep 13, 2013 at 2:34 PM, Ron Aaron r...@ronware.org wrote: Is there any way to enable allowing a user to upload a file via the 'files' page? It would be very useful for some of my users who are command-line challenged to be able to contribute changes this way. If they have access to ticketing you could let them upload attachments. You could put a direct link into a wiki page or embedded doc, to skip them directly to a preset ticket. I'm presuming they're not using a local clone, but it ought to work either way. --kevin kinnell kkinnell*at*megagate.com ___ 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] database disk image is malformed?
On 08/30/2013 08:43 AM, Richard Hippd...@sqlite.org wrote: On Fri, Aug 30, 2013 at 9:31 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 30, 2013 at 3:16 PM, Richard Hippd...@sqlite.org wrote: All logins on the canonical Fossil repository should restored now. out of curiosity: do you have a preferred/best-practice for partial db restorations, or did you restore the whole db? How should a normal mortal, without your inborn sqlite3 know-how, go about analyzing and recovering from such a situation? This could be turned into a learning opportunity for many sqlite users:). I don't know about sqlite users, but this thread is a great example for new fossil users. If you have a clone, and you periodically run fossil pull fossil config pull all From the clone, and you have admin rights on the original, then if the original gets trashed, you can always just scp the clone back to replace the corrupt original. -- D. Richard Hipp d...@sqlite.org I have a standard speech I give new devs: SCM is not a magical back up program, it's SCM. 1) good commit comments are critical. They get this right away. 2) accurate history is critical. They get this pretty quickly, but grumble about it when they want to clean up (xlate: hide their mistakes) a repo. 3) good backups of your repos are critical. Good backups of a *repo*??? is the general response. The sysadmins do backups every night. They do. And it never fails! And it catches your private, non-pushed branches on your workstation! To be fair, the ones who have been using SCM for a while have a lot less trouble with this. Except for the accurate history. heh. -- kevin kinnell Domain: .net.kejoki ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] test-grep
I like this. I've been testing it in [31dd2c0e3e] :
It looks pretty good, except a backwhack doesn't remove all of the
special properties for a metacharacter.
fossil test-grep '^\*\* the version' src/*
doesn't find anything. Also doesn't work without the anchor, or if it's
double backwhacked.
On the other hand
fossil test-grep '^.. the version' src/*;# and
fossil test-grep '^[*][*] the version' src/*
find the same three lines in the fossil sources, so it looks like
anchors and character classes are working.
The backwhack problem isn't limited to quantifiers, the same scenario
shows up for the . character.
'^*' and '*' both give a nice error message about a quantifier without
an operand, and so do +, ?, and {} (nice).
The \S, \s, etc. shortcuts seem to be working as well.
If I was guessing, I'd guess the following: backwhacking a metacharacter
works, and makes it a 'plain old' character. But then, the code that
handles shortcut character classes gets it, and elides it, or something
with the same effect.
I'd go searching, but I have to be at work in the morning. sigh /
--kkinnell
-m Don't edit makemake.tcl in a mode that changes tabs to spaces.
___
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 encountered while attempting to reflect project file system reorganization in Fossil repo.
On 12/16/2012 K k...@lightpowered.org wrote: I'm new to Fossil SCM, have not used any other SCMs, and am trying to do something relatively complex for me. It involves moving from a model where files are directly added to my repo, rather than being organized in the repo within directories. I had my project organized as: project/ * non versioned project files * foo.fossil - versioned file repo. * foo.xcodeproj - project configuration in Apple Xcode's format. * sourcecode/ - source code files and check out directory. I want to reorganize, and so I have: * moved (on my file system) foo.xcodeproj into the sourcecode/ dir. * renamed (on my file system) sourcecode/ to source/. * moved (on my file system) source code files from source/ into source/code/. I also want to change from my check out being in source, to /containing/ source. So in my above file system layout, I want to promote my foo.fossil from project/code, to project/, so when it's checked out it produces a single directory named source. (As I expand use of Fossil SCM, I'll add other project/dirs) I ran into some problems and would appreciate help. Last login: Thu Dec 13 23:41:48 on console notebook:~ ktk$ cd source/ notebook:source ktk$ ls -l total 0 drwxr-xr-x 25 ktk staff 850 Dec 15 22:37 code drwxr-xr-x 5 ktk staff 170 Dec 15 22:39 foo.xcodeproj notebook:source ktk$ ls -la total 40 drwxr-xr-x 6 ktk staff204 Dec 15 22:37 . drwxr-xr-x 6 ktk staff204 Dec 15 22:37 .. -rw-r--r--@ 1 ktk staff 6148 Dec 15 22:37 .DS_Store -rw-r--r-- 1 ktk staff 10240 Nov 30 22:31 .fslckout drwxr-xr-x 25 ktk staff850 Dec 15 22:37 code drwxr-xr-x 5 ktk staff170 Dec 15 22:39 foo.xcodeproj notebook:source ktk$ fossil changes MISSINGfoo.c MISSINGfoo.h notebook:source ktk$ fossil help mv Usage: fossil mv|rename OLDNAME NEWNAME or: fossil mv|rename OLDNAME... DIR Move or rename one or more files or directories within the repository tree. You can either rename a file or directory or move it to another subdirectory. This command does NOT rename or move the files on disk. This command merely records the fact that filenames have changed so that appropriate notations can be made at the next commit/checkin. See also: changes, status You were on the right track, here. 'mv' will tell fossil that you have changed the path of an existing file. notebook:source ktk$ fossil help (At this point I was looking to see if I needed to fossil mkdir code to fossil mv foo.h code/) Usage: fossil help COMMAND Common COMMANDs: (use fossil help --all for a complete list) add clean gdiff mv rm timeline addremove clone helpopensettingsui all commit import pullsqlite3 undo annotatediffinfopushstash update bisect export initrebuild status version branch extras ls remote-url sync changes finfo merge revert tag This is fossil version 1.24 [8d758d3715] 2012-10-22 12:48:04 UTC notebook:source ktk$ fossil help add Usage: fossil add ?OPTIONS? FILE1 ?FILE2 ...? Make arrangements to add one or more files or directories to the current checkout at the next commit. When adding files or directories recursively, filenames that begin with . are excluded by default. To include such files, add the --dotfiles option to the command-line. The --ignore option is a comma-separate list of glob patterns for files to be excluded. Example: '*.o,*.obj,*.exe' If the --ignore option does not appear on the command line then the ignore-glob setting is used. The --case-sensitive option determines whether or not filenames should be treated case sensitive or not. If the option is not given, the default depends on the global setting, or the operating system default, if not set. Options: --case-sensitive BOOL override case-sensitive setting --dotfiles include files beginning with a dot (.) --ignore CSG ignore files matching patterns from the comma separated list of glob patterns. See also: addremove, rm notebook:source ktk$ fossil add code ADDED code/foo.c ADDED code/foo.h notebook:source ktk$ fossil changes (Thinking at this point maybe Fossil can 'see' the missing files now, and they will be 'FOUND'?) Nope. What 'add' does is add a file to source control. As far as fossil is concerned, you added brand new files to the checkout. MISSINGfoo.c MISSINGfoo.h ADDED code/foo.c ADDED code/foo.h notebook:source ktk$ fossil mv foo.c code/ RENAME foo.c code/foo.c fossil: SQLITE_CONSTRAINT: abort at 38 in [UPDATE vfile SET pathname='code/foo.c' WHERE pathname='foo.c' AND vid=55]: columns pathname, vid are not unique fossil: columns pathname, vid are not unique UPDATE
Re: [fossil-users] Problem encountered while attempting to reflect project, file system reorganization in Fossil repo.
On 12/16/2012 03:08 PM, K k...@lightpowered.org wrote: kk, Thank you. Your timing is funny as I had *just* given up on waiting for help and tried again with success this time. What I did was deleted my whole source/ dir, leaving only my foo.fossil. (Luckily I had just done a commit before any of this reorganization stuff) I did fossil open foo.fossil in my project/ dir, and it spewed all of my files into the dir, as expected. Then I did mkdir source; mkdir source/code, then added both of those dirs to Fossil. Then I did fossil mv file.h source/code/file.h for all of my files. THEN I moved the actual files into that dir. Now everything is happy apparently. Thanks again for taking the time to write kk. ^K Not at all. Although, it appears I wrote about twice as much as I intended... Glad you were able to get things arranged as you wanted them. --kkinnell ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Kudos to Richard and the Fossil developers
The latest debate over whether the 'rm' and 'mv' commands--in the fossil shell--should behave exactly line the 'rm' and 'mv' commands--in the various OS command shells--proves one thing unequivocally: Fossil is an piece of software that can spark vehement opinions from its users. Fossil matters. Holy wars are tedious, but they do prove that the (primary) subject of the battles is *something that matters*, and that should make the Fossil developers proud. Aside from that, here's an enhancement suggestion for when there's time: A little self-knowledge can be A Good Thing. Maybe Fossil could keep a list of behavior and db format changes in each repository? I'm thinking it could be an event artifact. The overhead ought to be small. It could keep a list of messages, and Fossil's behavior would be extended to trigger displaying the message when a changed command is attempted, instead of executing the command. Scripts running Fossil would log the error (or so one would hope!) Once the user acknowledged the changed command (fossil set ok foo) the command would run, and the warning would stop appearing. Finally, if there are command changes in a new version, a Some commands have changed, see help message could fire when fossil is invoked, until they've all been acknowledged. The user could downgrade until they fix scripts, etc. It would catch users that haven't grabbed a zip or pulled in a long time. I don't see how anybody could get surprised, or lose data from a changed command. Ok, maybe a _little_ surprised, but not in an horribly unpleasant way. Lots of work, but it would be a sort of meta-solution to all of this. --kkinnell (using host megagate under the commercial root-domain) ___ 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] Checkin [432306beca] causes minor annoyance with emacs vc.
Holy cow, Richard -- you're fast on those stupid user tricks responses! Oh, and uh ... oops. I mv'd it instead. Let's hope the other 2.5 emacs+fossil users don't make the same mistake. --kkinnell On Mon, 03 Sep 2012 12:22:01 -0700 Richard Hipp wrote: On Mon, Sep 3, 2012 at 3:12 PM, kkinn...@megagate.com wrote: I haven't been making many new repos lately, so I got a shock when I set one up and tried to do a checkin via Emacs. It turns out that the vc-fossil.el file assumes that the local housekeeping will be in ./_FOSSIL, so the change that defaults to .fslckout in version [432306beca] leaves Emacs unable to figure out that it's in an open checkout. This is trivial to fix on the user side. The quickest fix is probably 'ln -s .fslckout _FOSSIL_', Please, No! That can lead to repository corruption! Never symbolically link an SQLite database! The quickest fix is this: mv .fslckout _FOSSIL_ after which everything works fine. The best fix (no holy warrior commentary) is probably to def-custom the file name in the vc module. Apologies if this has been covered, but I didn't find anything in the archives, so I thought I'd mention it for the sake of the other 2 1/2 emacs fossil users out there... --kkinnell ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
