Re: [fossil-users] fossil export to git "fatal: mark :60713 not declared"
I reported the exact same bug around 2 month ago without tracking any interest :( regards, Bapt 2014-10-31 23:08 GMT+01:00 E. Timothy Uy : > I was able to import see.fossil and cerod.fossil from Cygwin with no issues. > However for SQLite, > > $ fossil export --git ../../../sqlite.fossil | git fast-import > > fatal: mark :60713 not declared > > fast-import: dumping crash report to > ./.git/modules/src/sqlite/fast_import_crash_1168 > > > > From the crash report: > > fast-import crash report: > > fast-import process: 1168 > > parent process : 1 > > at Fri Oct 31 22:59:48 2014 > > fatal: mark :60713 not declared > > > > commit refs/heads/trunk > > mark :60705 > > committer drh 1257341402 + > > data 83 > > from :60691 > > M 100644 :60706 src/main.c > > M 100644 :60698 src/sqliteInt.h > > commit refs/heads/shunning_error > > mark :60721 > > committer drh 1257360677 + > > data 24 > > * from :60713 > > > > ___ > 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 wiki question
On Mon, Nov 3, 2014 at 6:42 AM, Andy Bradford wrote: > Thus said jungle Boogie on Sun, 02 Nov 2014 18:03:39 -0800: > > > Should you expect to see the wiki changes on the cloned copy or will > > they always/only be on the project that did fossil init? > > Fossil Wiki content synchronizes just like other Fossilized content. ...except that wiki (and ticket) changes do not get autosynced: one has to manually sync/push/pull in order to get everything transferred. > rate, if you are just making source commits, then autosync should take > care of automatically pushing the content to the server. If not, you can > always manually cause a sync with fossil sync or fossil push. > Note that an autosync triggered for a commit/update will include wiki/ticket bits, but editing the wiki is not enough to get it to sync - a manual push/sync is required unless one is also doing other work with will force an autosync (e.g. "commit" would normally do this). > Local wiki changes have to be manually synchronized after you have made > changes: e.g. fossil sync. > That'd be the easiest way to do it, i think - simply run sync after saving wiki changes. -- - 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 wiki question
Thus said jungle Boogie on Sun, 02 Nov 2014 18:03:39 -0800: > Should you expect to see the wiki changes on the cloned copy or will > they always/only be on the project that did fossil init? Fossil Wiki content synchronizes just like other Fossilized content. If you have permission to commit Wiki changes, then you can create new pages, alter existing pages, etc. and then sync them to the location from whence you cloned. > On the machine that cloned the project, how do I commit and push > changes back to the machine that did the init? It sounds like you might have cloned using an anonymous clone (the default behavior if you don't give a username in the clone URL). At any rate, if you are just making source commits, then autosync should take care of automatically pushing the content to the server. If not, you can always manually cause a sync with fossil sync or fossil push. > Do I create a user account on the webpage the machine that did the > init? Yes. Create a user account with appropriate privileges and then perform the clone using that user (or update your existing clone with ``fossil remote-url'' or even a ``fossil push'' with new URL including the username. Then whenever you commit in your clone, you can sync the content to the source of the clone. Fossil does this by default using autosync, so unless you have disabled autosync, when you commit code changes it will automatically try to push them to the server from whence you cloned. Local wiki changes have to be manually synchronized after you have made changes: e.g. fossil sync. Let us know if you have additional questions. Andy -- TAI64 timestamp: 4000545715df ___ 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 wiki question
Hello All, If you: fossil init thanks4fossil.fossil fossil open thanks4fossil.fossil fossil server Edit the wiki in the browser then on a separate machine: fossil clone http://path.to.fossil/ fossil open thanks4fossil.fossil fossil server edit wiki Should you expect to see the wiki changes on the cloned copy or will they always/only be on the project that did fossil init? My couple tests led me to believe that only shows changes at one place but that may have been my mistakes in trying fossil out. Second question... On the machine that cloned the project, how do I commit and push changes back to the machine that did the init? Do I create a user account on the webpage the machine that did the init? In git (which I don't know much about), ssh keys are used to push changes back to the init'd project. It's absolutely amazing how fast and effortlessly a project can be up and running with fossil--with a full wiki so you don't have to host it on different sites. What's the etymology of fossil pertaining to source control? Lastly, does the project except monetary donations? Best, jungle --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 cogent explanation of GIT rebasing
I'm personally very happy with fossil's philosophical perspective, but this explains pretty clearly what/how rebasing is. I can see why the Linux maintainers would want it for a project like that. https://gist.github.com/herby/12c8c3ef88d0c9ad5428 ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users