Re: [fossil-users] 'fossil clone' from localhost is extremely slow
Hello, On Thu, Jan 10, 2013 at 1:03 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Jan 09, 2013 at 05:02:14PM +, Michai Ramakers wrote: apart from the question whether cloning from localhost makes sense or not (I use this from a script to make work from localhost or remote transparent), I experienced very slow network traffic - but no hang - while cloning like thus: Can you run echo 'analyze;' | fossil sqlite ori.fossil first and see if that helps? I didn't know the 'analyze' sqlite command, thank you. When trying (I am assuming you meant with '-R' option to point to repo), I got slightly more than I bargained for: --- michai@lime:/tmp$ uname -a NetBSD lime 6.0.1 NetBSD 6.0.1 (GENERIC) amd64 michai@lime:/tmp$ /tmp/fossil ver This is fossil version 1.25 [baa1ebb7d9] 2013-01-07 18:58:30 UTC michai@lime:/tmp$ echo 'analyze;' | /tmp/fossil sqlite -R 100MB.fossil michai@lime:/tmp$ echo 'analyze;' | /tmp/fossil sqlite -R 100MB.fossil Segmentation fault (core dumped) michai@lime:/tmp$ mkdir try michai@lime:/tmp$ cd try/ michai@lime:/tmp/try$ /tmp/fossil open ../100MB.fossil Segmentation fault (core dumped) michai@lime:/tmp/try$ gdb /tmp/fossil GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64--netbsd. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/fossil...done. (gdb) run open ../100MB.fossil Starting program: /tmp/fossil open ../100MB.fossil Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x004b8fa2 in sqlite3VdbeExec (p=optimized out) at ./src/sqlite3.c:65390 #2 0x004a91e7 in sqlite3Step (p=0x7f7ff7e3b048) at ./src/sqlite3.c:62231 #3 sqlite3_step (pStmt=0x7f7ff7e3b048) at ./src/sqlite3.c:62305 #4 0x004aa17f in loadStat3 (zDb=0x6974df main, db=0x7f7ff7e03408) at ./src/sqlite3.c:79808 #5 sqlite3AnalysisLoad (db=0x7f7ff7e03408, iDb=optimized out) at ./src/sqlite3.c:14435 #6 0x004aa7c7 in sqlite3InitOne (db=0x7f7ff7e03408, iDb=0, pzErrMsg=0x7f7ff7e03c10) at ./src/sqlite3.c:93962 #7 0x004aa977 in sqlite3Init (db=0x7f7ff7e03408, pzErrMsg=0x7f7ff7e03c10) at ./src/sqlite3.c:94019 #8 0x004aa9ee in sqlite3ReadSchema (pParse=0x7f7ff7e03c08) at ./src/sqlite3.c:94056 #9 0x004ab23d in sqlite3LocateTable (pParse=0x7f7ff7e03c08, isView=0, zName=0x7f7ff7e2ed88 config, zDbase=0x0) at ./src/sqlite3.c:81103 #10 0x004ab3d5 in selectExpander (pWalker=0x7f7fd350, p=0x7f7ff7e2eb88) at ./src/sqlite3.c:97832 #11 0x004681f9 in sqlite3WalkSelect (pWalker=0x7f7fd350, p=0x7f7ff7e2eb88) at ./src/sqlite3.c:72494 #12 0x004684ce in sqlite3SelectExpand (pSelect=0x7f7ff7e2eb88, pParse=0x7f7ff7e03c08) at ./src/sqlite3.c:98063 #13 sqlite3SelectPrep (pParse=0x7f7ff7e03c08, p=0x7f7ff7e2eb88, pOuterNC=optimized out) at ./src/sqlite3.c:32611 #14 0x0048d8ac in sqlite3Select (pParse=0x7f7ff7e03c08, p=0x7f7ff7e2eb88, pDest=0x7f7fd6c0) at ./src/sqlite3.c:98412 #15 0x004a455a in yy_reduce (yyruleno=112, yypParser=0x7f7ff7e30008) at ./src/sqlite3.c:110655 #16 sqlite3Parser (yyp=optimized out, yymajor=1, yyminor=..., pParse=optimized out) at ./src/sqlite3.c:46121#17 0x004a6d6c in sqlite3RunParser (pParse=0x7f7ff7e03c08, zSql=optimized out, pzErrMsg=0x7f7fd7b0) at ./src/sqlite3.c:112494 #18 0x004a8a58 in sqlite3Prepare (db=0x7f7ff7e03408, zSql=0x7f7ff7e0b300 SELECT value FROM config WHERE name='allow-symlinks', nBytes=-1, saveSqlFlag=1, pReprepare=0x0, ppStmt=0x7f7fd8d0, pzTail=0x0) at ./src/sqlite3.c:94233 #19 0x004a8d2c in sqlite3LockAndPrepare (db=0x7f7ff7e03408, zSql=0x7f7ff7e0b300 SELECT value FROM config WHERE name='allow-symlinks', nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0x7f7fd8d0, pzTail=0x0) at ./src/sqlite3.c:94325 #20 0x004a8ec8 in sqlite3_prepare_v2 (db=optimized out, zSql=optimized out, nBytes=optimized out, ppStmt=optimized out, pzTail=optimized out) at ./src/sqlite3.c:94401 #21 0x004113a5 in db_vprepare (pStmt=0x7f7fd8b0, errOk=0, zFormat=optimized out, ap=0x7f7fd8f0) at ./src/db.c:256 #22 0x00411492 in db_text (zDefault=0x0, zSql=optimized out) at ./src/db.c:620 #23 0x004123ac in db_get (zName=0x60553d allow-symlinks, zDefault=0x6bb4bf off) at ./src/db.c:1769 #24 0x00412ab9 in db_get_boolean (zName=optimized out, dflt=0) at ./src/db.c:1860 #25 0x00412b95 in db_open_repository (zDbName=0x7f7ff7e01060 /tmp/100MB.fossil) at ./src/db.c:1006 #26 0x004132d5 in cmd_open () at ./src/db.c:1963 #27 0x0042e90b in main (argc=optimized out,
Re: [fossil-users] 'fossil clone' from localhost is extremely slow
I didn't know the 'analyze' sqlite command, thank you. When trying (I am assuming you meant with '-R' option to point to repo), I got slightly more than I bargained for: [...] Segmentation fault (core dumped) Retried with newer fossil-version [c7133bd79d] from yesterday, and segfault is gone :-) (Perhaps either checkin [6b3e97a328] or [1a52914b38] (both sqlite-related) could have fixed it, I don't know.) The original 'slow clone from localhost' issue remains. Assuming this is not a fossil bug, sorry for the noise and thank you for thinking along. Michai ___ 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 clone' from localhost is extremely slow
On Thu, Jan 10, 2013 at 10:19:31AM +, Michai Ramakers wrote: Hello, On Thu, Jan 10, 2013 at 1:03 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Jan 09, 2013 at 05:02:14PM +, Michai Ramakers wrote: apart from the question whether cloning from localhost makes sense or not (I use this from a script to make work from localhost or remote transparent), I experienced very slow network traffic - but no hang - while cloning like thus: Can you run echo 'analyze;' | fossil sqlite ori.fossil first and see if that helps? I didn't know the 'analyze' sqlite command, thank you. When trying (I am assuming you meant with '-R' option to point to repo), I got slightly more than I bargained for: [snip] Heh, that's for drh. You said sqlite analyze works? Does it help or not? Joerg ___ 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 clone' from localhost is extremely slow
On Thu, Jan 10, 2013 at 11:22 AM, Joerg Sonnenberger I didn't know
the 'analyze' sqlite command, thank you. When trying (I
am assuming you meant with '-R' option to point to repo), I got
slightly more than I bargained for:
[snip]
Heh, that's for drh. You said sqlite analyze works? Does it help or not?
ah yes... forgot that :) It does not help. Note that taking 1 cpu core
offline ('cpuctl offline 1' here) makes it fly.
Michai
___
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 clone' from localhost is extremely slow
On Thu, Jan 10, 2013 at 11:22 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: Heh, that's for drh. You said sqlite analyze works? Does it help or not? Also... see http://www.fossil-scm.org/xfer/info/85233c40c9bb05a87574cdc25402ec0d34b0b7ee : queries seem to be optimised to run without 'analyze' db info, but of course worth a try. Michai ___ 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 info' feature request (a.k.a. wish)
hi, I would find it useful if `fossil info' (or `stat', `timeline', or a new command) would provide a means/option to show the total number of revisions (by default or optional), more precisely, the number of file commits (as it is called in `fossil help timeline) in the repo. the information should be there in the database (or could be added?) and an additional line of output in `fossil info' would then do the trick. (sure one could also write a script analyszing `fossil timeline -ci ...' output to derive this information but this is not desirable for large repos in my view.) I would appreciate consideration of this proposal. greetings, j. ps: while I'm at it: adding the relative revision numbers to the output of `fossil timeline -ci' _and_ making them acceptable as keys instead of the SHA1 hashes in the relevant commands (notably `diff') would be very nice, too, but probably require more substantial changes. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 clone' from localhost is extremely slow
On Thu, Jan 10, 2013 at 12:32 PM, Michai Ramakers m.ramak...@gmail.comwrote:
ah yes... forgot that :) It does not help. Note that taking 1 cpu core
offline ('cpuctl offline 1' here) makes it fly
This is just pure speculation, but ... perhaps there is a problem in BSD
multi-core cases, such that the various requests made by fossil for cloning
do not get closed/killed immediately, and each request is locking the db
for longer than it should because its process it not being killed in a
timely manner? It would be interesting to see if, when you see the
hang-ups, if the child process forked for handling a request is still alive
(on the other CPU) for a while after the subsequent request has already
started.
i.e... clone request 1 comes in and completes, but its process (or flock)
is not closed/released in a timely manner. Then comes clone request #2,
which is waiting on an flock which is still held by request 1. Ad nauseum
for requests #3 to #N. The output of lsof the_repo_file might be useful
here.
(Again, purely speculation...)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 info' feature request (a.k.a. wish)
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff veedeeh...@googlemail.com wrote: I would find it useful if `fossil info' (or `stat', `timeline', or a new command) would provide a means/option to show the total number of revisions (by default or optional), more precisely, the number of file commits (as it is called in `fossil help timeline) in the repo. the information should be there in the database (or could be added?) and an additional line of output in `fossil info' would then do the trick. (sure one could also write a script analyszing `fossil timeline -ci ...' output to derive this information but this is not desirable for large repos in my view.) i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). ps: while I'm at it: adding the relative revision numbers to the output of `fossil timeline -ci' _and_ making them acceptable as keys instead of the SHA1 hashes in the relevant commands (notably `diff') would be very nice, too, but probably require more substantial changes. The DVCS model means that _relative_ (sequential) revision numbers are rendered absolutely meaningless because multiple users can work offline in parallel (and their system clocks might not be properly synced, breaking time-based ordering). The sequential numbering problem is, in effect, impossible to solve in a DVCS. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] main fossil repo is now 2000 days old
Hi, all, i just coincidentally saw this on the /stat page of the main fossil repo: Duration Of Project:2000 days or approximately 5.48 years. Happy 2000th day, Fossil! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 info' feature request (a.k.a. wish)
On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 clone' from localhost is extremely slow
On Thu, 10 Jan 2013 13:21:50 +0100
Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jan 10, 2013 at 12:32 PM, Michai Ramakers m.ramak...@gmail.comwrote:
ah yes... forgot that :) It does not help. Note that taking 1 cpu core
offline ('cpuctl offline 1' here) makes it fly
This is just pure speculation, but ... perhaps there is a problem in BSD
multi-core cases, such that the various requests made by fossil for cloning
do not get closed/killed immediately, and each request is locking the db
for longer than it should because its process it not being killed in a
timely manner? It would be interesting to see if, when you see the
hang-ups, if the child process forked for handling a request is still alive
(on the other CPU) for a while after the subsequent request has already
started.
i.e... clone request 1 comes in and completes, but its process (or flock)
is not closed/released in a timely manner. Then comes clone request #2,
which is waiting on an flock which is still held by request 1. Ad nauseum
for requests #3 to #N. The output of lsof the_repo_file might be useful
here.
(Again, purely speculation...)
If he tries in shell 1
fossil open repository
fossil server
and in shell 2
fossil clone http://localhost:8080/ copy.fossil
should workaround it, the repository is opened only once
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
--- ---
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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:35:06 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff
veedeeh...@googlemail.com
wrote:
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the total number of
revisions
(by default or optional), more precisely, the number of file commits
(as
it is called in `fossil help timeline) in the repo. the information
should
be there in the database (or could be added?) and an additional line of
output in `fossil info' would then do the trick. (sure one could also
write
a script analyszing `fossil timeline -ci ...' output to derive this
information but this is not desirable for large repos in my view.)
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in the
/stat
page already (and in fossil json stat -full).
ps: while I'm at it: adding the relative revision numbers to the output
of
`fossil timeline -ci' _and_ making them acceptable as keys instead of
the
SHA1 hashes in the relevant commands (notably `diff') would be very
nice,
too, but probably require more substantial changes.
The DVCS model means that _relative_ (sequential) revision numbers are
rendered absolutely meaningless because multiple users can work offline
in
parallel (and their system clocks might not be properly synced, breaking
time-based ordering). The sequential numbering problem is, in effect,
impossible to solve in a DVCS.
I'm aware of this and that's why I wrote relative in the first place.
still, the numbers do make sense _locally_ as a very handy means of
denoting/selecting a revision. confusion _could_ arise if different people
talk about revision 11 without being aware that this is no good and they
need to use the sha1 hash (but practically, this should not be an issue).
by the way, the idea is not mine anyway but stolen from mercurial which
does just that, namely reporting the time line with identifiers formatted
as {rel_rev_number}:SHA1 and both (the rel. rev. and the hash) are
accepted in `diff' and friends.
works like a charm and saves lots of typing (locally chronological rev.
nums are much easier to memorize (and to type...) than sha1 hashes).
so I still think this would be useful.
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 clone' from localhost is extremely slow
On Thu, Jan 10, 2013 at 1:53 PM, Eduardo Morras emorr...@yahoo.es wrote: If he tries in shell 1 fossil open repository fossil server and in shell 2 fossil clone http://localhost:8080/ copy.fossil should workaround it, the repository is opened only once In theory, yes, but the web server forks a child process for each request and (as i learned via a recent thread in the sqlite list) the db must be opened by the child processes in order for locking to work properly. If BSD is not killing the child processes immediately after each request is finished then the db could be held open during the multiple requests sent by a clone operation. In theory/speculation. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 info' feature request (a.k.a. wish)
On Thu, Jan 10, 2013 at 1:57 PM, j. van den hoff veedeeh...@googlemail.comwrote: ...works like a charm and saves lots of typing (locally chronological rev. nums are much easier to memorize (and to type...) than sha1 hashes). so I still think this would be useful. Explained that way it does sound useful but i would personally be very wary of using any numbering/IDs which aren't guaranteed to be stable between CLI invocations, since a pull/update could invalidate/change the meaning of the ordering. (But that's just a sign of my own pedanticness.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 14:12:18 +0100 Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:57 PM, j. van den hoff veedeeh...@googlemail.comwrote: ...works like a charm and saves lots of typing (locally chronological rev. nums are much easier to memorize (and to type...) than sha1 hashes). so I still think this would be useful. Explained that way it does sound useful but i would personally be very wary of using any numbering/IDs which aren't guaranteed to be stable between CLI invocations, since a pull/update could invalidate/change the meaning of the ordering. (But that's just a sign of my own pedanticness.) You always can commit to (in my case) stable branch with a tag, f.ex. fossil commit -m Release version 5.2 --branch stable --tag 5.2 Perhaps i'm using it the wrong way, don't know, -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- 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 1.25
On Wed, Jan 2, 2013 at 4:12 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 2, 2013 at 3:58 PM, Ruediger Haertel r_haer...@gmx.de wrote: Hello, happy new year to all of you. Will there be precompiled versions of v1.25? I remember there was a discussion about this, but don't know what the result was. I really like to have a precompiled binary for windows. Not that I couldn't build one myself but it was really handy just to download. I was trying to push out a new version back in early December. But I got a lot of push-back from users who thought I should let the code bake a little longer. Of course, since then there have been lots more changes. I'm not sure letting Fossil bake is really an option. The code is progressing rapidly, and trying to force a quiet period prior to a release will probably not accomplish anything other than slow down development. Besides, very few people are going to test it until the official release anyhow... So probably someday soon I'll wake up one morning and decide today is a good day to release Fossil version 1.25 and it will be so. No beta. No baking time. No quiet period. It will just happen. Could the official binaries, starting with 1.25, include OpenSSL functionality? I did manage to build my own Windows exe, but it's a major pain to do this for every release and then to make sure that others on your team don't use the version from fossil-scm.org. - Max ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Initial patch towards rebase
https://chiselapp.com/user/nico/repository/nico Two branches: rebase, and test-rebase. This adds a --nocommit option to the fossil merge command that does... what it sounds like it does: it applies the patch from a --cherrypick commit and leaves that uncommitted. I applied all the commits from my rebase branch onto my test-rebase branch, each time using --cherrypick and --nocommit, then did a single commit at the end, and the result is that src/merge.c in both branches has the same contents. (www/index.wiki doesn't, and I suspect this is due to fossil automerging silently, which I wish it wouldn't do). An actual, interactive rebase facility like git's can be constructed on top of this, though some things, like interactive patch chunk selection/editing, will require more work here. Cheers, Nico -- ___ 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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 thank you! -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Initial patch towards rebase
I don't understand: fossil merge has never done a commit. The --nocommit option seems like a noop to me. What am I misunderstanding? D. Richard Hipp - d...@sqlite.org Sent from phone - pardon brevity On Jan 10, 2013 10:19 AM, Nico Williams n...@cryptonector.com wrote: https://chiselapp.com/user/nico/repository/nico Two branches: rebase, and test-rebase. This adds a --nocommit option to the fossil merge command that does... what it sounds like it does: it applies the patch from a --cherrypick commit and leaves that uncommitted. I applied all the commits from my rebase branch onto my test-rebase branch, each time using --cherrypick and --nocommit, then did a single commit at the end, and the result is that src/merge.c in both branches has the same contents. (www/index.wiki doesn't, and I suspect this is due to fossil automerging silently, which I wish it wouldn't do). An actual, interactive rebase facility like git's can be constructed on top of this, though some things, like interactive patch chunk selection/editing, will require more work here. Cheers, Nico -- ___ 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] Tags and branches ui
Hello, it would be nice if the Tags and Branches ui pages had something more than the names listed. For example, next to each, could be the date of the head or the last commit referred to. What do you think? Regards, Lluís. ___ 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 info' feature request (a.k.a. wish)
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 did not yet recompile and test, therefore short question: this is the total number of checkins (including wiki edits etc)? contrary to my last mail this would be actually the relevant info needed for creating the rel. checkin numbers I was talking about. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 info' feature request (a.k.a. wish)
This number is the same one reported from the /stat page for number of commits. i am not sure off-hand whether wiki edits and whatnot are included. (sent from phone from dentist office...) - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jan 10, 2013 5:24 PM, j. van den hoff veedeeh...@googlemail.com wrote: On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote: i'll sign up for adding that - i would be able to do this on Sunday. i would add it to the status command because we have that info in the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.**html/info/acea7010b8http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/**fossil]$ f info project-name: Fossil ... checkin-count: 4840 did not yet recompile and test, therefore short question: this is the total number of checkins (including wiki edits etc)? contrary to my last mail this would be actually the relevant info needed for creating the rel. checkin numbers I was talking about. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] Cross-compiling under FreeBSD for Windows
For anyone else interested, here are the steps for building fossil.exe with OpenSSL support on a FreeBSD host (9.0-RELEASE-p5 amd64): 1. Install devel/mingw32-gcc, devel/mingw32-zlib, and devel/mingw32-openssl ports. As of this writing, mingw32-zlib (1.2.5) fails to build due to a problem with zlib.def. The solution is either to install the package (pkg_add -r mingw32-zlib) or change the port's Makefile to use zlib 1.2.7, which builds without any issues. 2. Download the current fossil source tarball (or clone fossil-scm.org via devel/fossil). 3. Run gmake -f win/Makefile.mingw PREFIX=mingw32- FOSSIL_ENABLE_SSL=1. That's it :) - Max ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Suggested way to sync to multiple servers?
Hello. It seems as though it's only really possible to sync to one remote server at a time. Is there a way to specify that a repository should push to multiple remote servers? My use case here is that I've got repositories hosted on http://fossil.io7m.com but I've also got an exact mirror of that site on my internal network here that's used for testing quickly on multiple machines/VMs (and will now be polled very frequently for CI testing, which would be slow and would start to get expensive in terms of data usage with the number of repositores over the WAN). I'd quite like to either be able to push to multiple remotes, or possibly to be able to push to a remote and then have that remote push to a further remote. Right now, it seems the only way I can do this is to maintain a list of remotes with each repository, and manually push to each URL in the list with push --once. That obviously doesn't play nicely with fossil all sync! M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] a few newbie questions re. wiki and embedded documentation
Hi Folks, Just starting to experiment with Fossil for use on a project, and I'd like to use it for documentation as well as code. As I've been playing with the wiki and embedded documentation features, I've noticed a few things that lead to a few questions. Advice would be most welcomed: 1. As the documentation indicates, there's no support for working with branching and merging of stand-alone wiki pages, which suggests that .wiki pages within a code tree are more manageable. But. they don't seem to be editable through the web interface - i.e., they are not really wiki-like. Or am I missing something? Is there a way to do real wiki-like things in Fossil (editing, versioning, etc.)? 2. The documentation talks about event pages, stating There is a hyperlink under the /Wiki menu that can be used to create new events. And there is a submenu hyperlink on event displays for editing existing events. I don't see these. Again, am I missing something? Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
