Nevermind, I guess specifying the port is not optional. The other critical piece was specifying the remote fossil to use:
../fossil clone 'ssh://localhost:22//nfs/ch/disks/ch_home_disk002/mrwellan/fossils/megatest.fossil?fossil=/tmp/mrwellan/fossilssh/fossil' mt.fossil All working now!! Many thanks... Matt -=- On Mon, Nov 12, 2012 at 8:46 AM, Matt Welland <[email protected]> wrote: > This works for me also but I had to comment out the adding of -p as the > port was coming though as "0" (this is using fsecure ssh, tcsh, SLES9.) > > #ifdef __MINGW32__ > blob_appendf(&zCmd, " -P %d", g.urlPort); > #else > /* blob_appendf(&zCmd, " -p %d", g.urlPort); */ > > I also haven't made sense of the URL syntax. In rsync I would specify > rsync -avz mrwellan@localhost:~/fossils/fossil.fossil but that doesn't > seem to work. The full path with two leading slashes seems to work. > ================================== > > fsl set | grep ssh > ssh-command (global) ssh -t > chlr11723> rm mt.fossil* ; ( cd .. ; make ) && ../fossil clone > ssh://localhost://nfs/ch/disks/ch_home_disk002/mrwellan/fossils/megatest.fossil > mt.fossil > > make: Nothing to be done for `all'. > ssh -t -p 0 localhost > Error: in option 'port': invalid option value > Broken pipe > > > > > On Mon, Nov 12, 2012 at 8:40 AM, j. van den hoff < > [email protected]> wrote: > >> On Mon, 12 Nov 2012 15:51:04 +0100, Richard Hipp <[email protected]> wrote: >> >> On Mon, Nov 12, 2012 at 8:36 AM, j. van den hoff >>> <[email protected]>**wrote: >>> >>> I've tested this here (with Fossil-4473a27f3b6e049e) but can only report >>>> partial success: >>>> >>>> * it works using bash/ksh as login shell on the remote machine _if_ >>>> there >>>> is not too much text (the allocated buffer size (50000) is still rather >>>> modest but usually sure sufficient) coming in from `.profile' over the >>>> ssh >>>> connection. so that's a clear step forward. however: >>>> >>>> * it does _not_ work if the default verbose (multi-line/blank line >>>> separated multi-paragraph, but much shorter than 50000 bytes) ubuntu >>>> motd >>>> stuff comes in. the (visible) offending text looks something like this: >>>> >>>> >>> Please try again using http://www.fossil-scm.org/** >>> fossil/info/00cf858afe<http://www.fossil-scm.org/fossil/info/00cf858afe>and >>> let me know if the situation improves. If it still is not working, >>> >> >> indeed it does: congratulation! >> >> * it now works without problems both with bash and ksh and does no longer >> choke on ubuntu's motd stuff (nor on 'my' escape sequences). >> putting excessively much text in the way still leads to a failure but >> that's probably rather a feature... >> >> * with tcsh, I most of the time get >> 8<--------------------------- >> >> tput: No value for $TERM and no -T specified >> TERM: Undefined variable. >> Bytes Cards Artifacts Deltas >> Sent: 53 1 0 0 >> waiting for server... >> 8<--------------------------- >> where it hangs infinitely (this is an extrapolation from the actually >> waited ~ 30 sec...) >> >> sporadically, however, it does not issue 'waiting for server' (or it's >> overwritten to quickly) and actually completes successfully. >> this might very well be a real tcsh issue (in which case one might >> contact the maintainers) but if this could reliably be handled as well I >> presume the problem is solved completely. >> here, several colleagues (not me any more) still stick with tcsh for >> interactive work and it quite probably still is the default shell >> on most BSD descendants (not on macosX, though). >> >> thanks a lot. >> >> >> please >>> run with the --sshtrace command-line option and send me the diagnostic >>> output. Thanks. >>> >> >> I see the command in the source but it seems not to be recognized. how is >> it supposed to be called? >> >> >>> >>> >>> >>>> 8<----------------------------****----------------------------** >>>> --**---- >>>> >>>> Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64) >>>> >>>> * Documentation: https://help.ubuntu.com/ >>>> >>>> System information as of Mon Nov 12 13:20:41 CET 2012 >>>> >>>> System load: 0.04 Processes: 114 >>>> Usage of /: 72.3% of 9.96GB Users logged in: 2 >>>> Memory usage: 22% IP address for eth0: 123.456.78.90 >>>> Swap usage: 0% >>>> >>>> Graph this data and manage this system at >>>> https://landscape.canonical.** >>>> com/ <https://landscape.canonical.**com/<https://landscape.canonical.com/> >>>> > >>>> >>>> >>>> >>>> 0 packages can be updated. >>>> 0 updates are security updates. >>>> 8<----------------------------****----------------------------** >>>> --**---- >>>> >>>> >>>> - what's strange is: if I copy this text into an `echo' command within >>>> `.profile' and then deactivate the MOTD (so seeminly getting the same >>>> stuff >>>> send over the >>>> ssh connection during login), it works flawlessly!?. my guess would >>>> be >>>> that there are some unprintable characters/escapes sent as well which I >>>> do >>>> not see >>>> so that copying the MOTD to `.profile' is not really the same thing >>>> as >>>> what is happening when ubuntu sends the stuff. >>>> >>>> * it also does _not_ work (with bash that is: ksh keeps working) if I >>>> myself send some escape sequences from my login scripts (as mentioned >>>> in a >>>> previous mail intended to dynamically adjust my xterm-titlebars). >>>> what's >>>> happening here is completely unclear to me, since it seems bash >>>> specific. >>>> what's worse: >>>> issuing the respective `echo' directly in the script instead of >>>> within a >>>> shell-function (as is usually done in my setup) does not lead to a >>>> failure. >>>> my setup might be somewhat esoteric here, so maybe it's not too >>>> important, but it indicates of course that there still is something >>>> fundamentally not OK. >>>> >>>> * and it does not at all work with tcsh as login shell on the remote >>>> machine (even if login is completely silent). in this case I get the >>>> error >>>> message >>>> tput: No value for $TERM and no -T specified >>>> TERM: Undefined variable. >>>> Fossil-4473a27f3b6e049e/****fossil: ssh connection failed: [test1 >>>> >>>> probe-4f5d9ab4] >>>> so, seemingly `tcsh' users are out of luck anyway. >>>> >>>> questions: >>>> >>>> * maybe the (echo/flush) process has to be iterated one further time to >>>> make fossil happy with ubuntu's motd (after all it's not the least >>>> frequent >>>> linux distro)? >>>> >>>> * could fossil (or a debug version) not provide a (additional) hexdump >>>> (a >>>> la `hexdump -C' on linux) of the content of `zIn' instead of using >>>> `fossil_fatal("ssh connection failed: [%s]", zIn);'? in this way one >>>> might be able to at least to recognize what exactly is coming in which >>>> might help in tracking >>>> down the source of the trouble: it need not be printable characters >>>> coming over the ssh connection after all. >>>> >>>> >>>> j. >>>> >>>> >>>> >>>> On Sun, 11 Nov 2012 23:44:31 +0100, Richard Hipp <[email protected]> >>>> wrote: >>>> >>>> On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland <[email protected]> >>>> >>>>> wrote: >>>>> >>>>> I'll top-post an answer to this one as this thread has wandered and >>>>> >>>>>> gotten >>>>>> very long, so who knows who is still following :) >>>>>> >>>>>> I made a simple tweak to the ssh code that gets ssh working for me on >>>>>> Ubuntu and may solve some of the login shell related problems that >>>>>> have >>>>>> been reported with respect to ssh: >>>>>> >>>>>> >>>>>> http://www.kiatoa.com/cgi-bin/****fossils/fossil/fdiff?v1=**<http://www.kiatoa.com/cgi-bin/**fossils/fossil/fdiff?v1=**> >>>>>> 935bc0a983135b26&v2=****61f9ddf1e2c8bbb0<http://www.** >>>>>> kiatoa.com/cgi-bin/fossils/**fossil/fdiff?v1=**935bc0a983135b26&v2=** >>>>>> 61f9ddf1e2c8bbb0<http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26&v2=61f9ddf1e2c8bbb0> >>>>>> > >>>>>> >>>>>> >>>>>> Not exactly the same patch, but something quite similar has been >>>>> checked >>>>> in >>>>> at >>>>> http://www.fossil-scm.org/****fossil/info/4473a27f3b<http://www.fossil-scm.org/**fossil/info/4473a27f3b> >>>>> <http://**www.fossil-scm.org/fossil/**info/4473a27f3b<http://www.fossil-scm.org/fossil/info/4473a27f3b>>- >>>>> please try it out and >>>>> >>>>> let me know if it clears any outstanding problems, or if I missed some >>>>> obvious benefit of Matt's patch in my refactoring. >>>>> >>>>> >>>>> >>>>> >>>>> Joerg iasked if this will make it into a future release. Can Richard >>>>>> or >>>>>> one of the developers take a look at the change and comment? >>>>>> >>>>>> Note that unfortunately this does not fix the issues I'm having with >>>>>> fsecure ssh but I hope it gets us one step closer. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> -=- >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff < >>>>>> [email protected]>****wrote: >>>>>> >>>>>> On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland < >>>>>> [email protected]> >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff >>>>>>> >>>>>>> <[email protected]>******wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland < >>>>>>>> [email protected] >>>>>>>> > >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> sshfs is cool but in a corporate environment it can't always be >>>>>>>>> used. >>>>>>>>> For >>>>>>>>> >>>>>>>>> example fuse is not installed for end users on the servers I have >>>>>>>>> >>>>>>>>>> access >>>>>>>>>> to. >>>>>>>>>> >>>>>>>>>> I would also be very wary of sshfs and multi-user access. Sqlite3 >>>>>>>>>> locking >>>>>>>>>> on NFS doesn't always work well, I imagine that locking issues on >>>>>>>>>> sshfs >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> it doesn't? in which way? and are the mentioned problems >>>>>>>>>> restricted >>>>>>>>>> >>>>>>>>> to >>>>>>>>> NFS >>>>>>>>> or other file systems (zfs, qfs, ...) as well? >>>>>>>>> do you mean that a 'central' repository could be harmed if two >>>>>>>>> users >>>>>>>>> try >>>>>>>>> to push at the same time (and would corruption propagate to the >>>>>>>>> users' >>>>>>>>> "local" repositories later on)? I do hope not so... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I should have qualified that with the detail that historically NFS >>>>>>>> locking >>>>>>>> has been reported as an issue by others but I myself have not seen >>>>>>>> it. >>>>>>>> What >>>>>>>> I have seen in using sqlite3 and fossil very heavily on NFS is users >>>>>>>> using >>>>>>>> kill -9 right off the bat rather than first trying with just kill. >>>>>>>> The >>>>>>>> lock >>>>>>>> gets stuck "set" and only dumping the sqlite db to text and >>>>>>>> recreating >>>>>>>> it >>>>>>>> seems to clear the lock (not sure but maybe sometimes copying to a >>>>>>>> new >>>>>>>> file >>>>>>>> and moving back will clear the lock). >>>>>>>> >>>>>>>> I've seen a corrupted db once or maybe twice but never been clear >>>>>>>> that >>>>>>>> it >>>>>>>> was caused by concurrent access on NFS or not. Thankfully it is >>>>>>>> fossil >>>>>>>> and >>>>>>>> recovery is a "cp" away. >>>>>>>> >>>>>>>> Quite some time ago I did limited testing of concurrent access to an >>>>>>>> sqlite3 db on AFS and GFS and it seemed to work fine. The AFS test >>>>>>>> was >>>>>>>> very >>>>>>>> slow but that could well be due to my being clueless on how to >>>>>>>> correctly >>>>>>>> tune AFS itself. >>>>>>>> >>>>>>>> When you say zfs do you mean using the NFS export functionality of >>>>>>>> zfs? >>>>>>>> >>>>>>>> yes >>>>>>>> >>>>>>> >>>>>>> I've never tested that and it would be very interesting to know how >>>>>>> well >>>>>>> >>>>>>> it >>>>>>>> works. >>>>>>>> >>>>>>>> >>>>>>>> not yet possible here, but we'll probably migrate to zfs in the >>>>>>> not too >>>>>>> far future. >>>>>>> >>>>>>> >>>>>>> >>>>>>> My personal opinion is that fossil works great over NFS but would >>>>>>> >>>>>>>> caution >>>>>>>> anyone trying it to test thoroughly before trusting it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> could well be worse. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> sshfs is an excellent work-around for an expert user but not a >>>>>>>>>> replacement >>>>>>>>>> for the feature of ssh transport. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> yes I would love to see a stable solution not suffering from >>>>>>>>>> >>>>>>>>> interference >>>>>>>>> of terminal output (there are people out there loving the good old >>>>>>>>> `fortune' as part of their login script...). >>>>>>>>> >>>>>>>>> btw: why could fossil not simply(?) filter a reasonable amount of >>>>>>>>> terminal >>>>>>>>> output for the occurrence of a sufficiently strong magic pattern >>>>>>>>> indicating >>>>>>>>> that the "noise" has passed by and fossil can go to work? right now >>>>>>>>> putting >>>>>>>>> `echo " "' (sending a single blank) suffices to let the transfer >>>>>>>>> fail. >>>>>>>>> my >>>>>>>>> understanding is that fossil _does_ send something like `echo test' >>>>>>>>> (is >>>>>>>>> this true). all unexpected output to tty from the login scripts >>>>>>>>> would >>>>>>>>> come >>>>>>>>> _before_ that so why not test for receiving the expected text >>>>>>>>> ('test' >>>>>>>>> just >>>>>>>>> being not unique/strong enough) at the end of whatever is send (up >>>>>>>>> to >>>>>>>>> a >>>>>>>>> reasonable length)? is this a stupid idea? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I thought of trying that some time ago but never got around to it. >>>>>>>> Inspired >>>>>>>> by your comment I gave a similar approach a quick try and for the >>>>>>>> first >>>>>>>> time I saw ssh work on my home linux box!!! >>>>>>>> >>>>>>>> All I did was read and discard any junk on the line before sending >>>>>>>> the >>>>>>>> echo >>>>>>>> test: >>>>>>>> >>>>>>>> http://www.kiatoa.com/cgi-bin/******fossils/fossil/fdiff?v1=**<http://www.kiatoa.com/cgi-bin/****fossils/fossil/fdiff?v1=**> >>>>>>>> **<http://www.kiatoa.com/cgi-**bin/**fossils/fossil/fdiff?v1=****<http://www.kiatoa.com/cgi-bin/**fossils/fossil/fdiff?v1=**> >>>>>>>> > >>>>>>>> 935bc0a983135b26&v2=******61f9ddf1e2c8bbb0<http://www.** >>>>>>>> kiatoa.com/cgi-bin/fossils/****fossil/fdiff?v1=**** >>>>>>>> 935bc0a983135b26&v2=**<http://kiatoa.com/cgi-bin/fossils/**fossil/fdiff?v1=**935bc0a983135b26&v2=**> >>>>>>>> >>>>>>>> 61f9ddf1e2c8bbb0<http://www.**kiatoa.com/cgi-bin/fossils/** >>>>>>>> fossil/fdiff?v1=**935bc0a983135b26&v2=**61f9ddf1e2c8bbb0<http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26&v2=61f9ddf1e2c8bbb0> >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> ===========without========== >>>>>>>> rm: cannot remove `*': No such file or directory >>>>>>>> make: Nothing to be done for `all'. >>>>>>>> ssh matt@xena >>>>>>>> Pseudo-terminal will not be allocated because stdin is not a >>>>>>>> terminal. >>>>>>>> ../fossil: ssh connection failed: [Welcome to Ubuntu 12.04.1 LTS >>>>>>>> (GNU/Linux >>>>>>>> 3.2.0-32-generic-pae i686) >>>>>>>> >>>>>>>> * Documentation: https://help.ubuntu.com/ >>>>>>>> >>>>>>>> 0 packages can be updated. >>>>>>>> 0 updates are security updates. >>>>>>>> >>>>>>>> test] >>>>>>>> >>>>>>>> ==============with============******=== >>>>>>>> >>>>>>>> >>>>>>>> fossil/junk$ rm *;(cd ..;make) && ../fossil clone >>>>>>>> ssh://matt@xena//home/matt/******fossils/fossil.fossil >>>>>>>> >>>>>>>> >>>>>>>> fossil.fossil >>>>>>>> make: Nothing to be done for `all'. >>>>>>>> ssh matt@xena >>>>>>>> Pseudo-terminal will not be allocated because stdin is not a >>>>>>>> terminal. >>>>>>>> Bytes Cards Artifacts Deltas >>>>>>>> Sent: 53 1 0 0 >>>>>>>> Received: 5004225 13950 1751 5238 >>>>>>>> Sent: 71 2 0 0 >>>>>>>> Received: 5032480 9827 1742 3132 >>>>>>>> Sent: 57 93 0 0 >>>>>>>> Received: 5012028 9872 1137 3806 >>>>>>>> Sent: 57 1 0 0 >>>>>>>> Received: 4388872 3053 360 1168 >>>>>>>> Total network traffic: 1037 bytes sent, 19438477 bytes received >>>>>>>> Rebuilding repository meta-data... >>>>>>>> 100.0% complete... >>>>>>>> project-id: CE59BB9F186226D80E49D1FA2DB29F******935CCA0333 >>>>>>>> server-id: 3029a8494152737798f2768c799192******1f2342a84b >>>>>>>> >>>>>>>> >>>>>>>> admin-user: matt (password is "7db8e5") >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> great. that's essentially what I had in mind (but your approach of >>>>>>>> >>>>>>> sending two commands while flushing >>>>>>> the first response completely probably is better, AFAICS). will >>>>>>> something >>>>>>> like this make it into a future release? >>>>>>> >>>>>>> joerg >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sun, Nov 11, 2012 at 2:01 AM, Ramon Ribó <[email protected] >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > Sshfs didn't fix the problems that I was having with >>>>>>>>>> fossil+ssh, >>>>>>>>>> or >>>>>>>>>> >>>>>>>>>> at >>>>>>>>>>> least >>>>>>>>>>> > only did so partially. >>>>>>>>>>> >>>>>>>>>>> Why not? In what sshfs failed to give you the equivalent >>>>>>>>>>> functionality >>>>>>>>>>> than a remote access to a fossil database through ssh? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2012/11/11 Timothy Beyer <[email protected]> >>>>>>>>>>> >>>>>>>>>>> At Sat, 10 Nov 2012 22:31:57 +0100, >>>>>>>>>>> >>>>>>>>>>> j. van den hoff wrote: >>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > thanks for responding. >>>>>>>>>>>> > I managed to solve my problem in the meantime (see my previous >>>>>>>>>>>> mail in >>>>>>>>>>>> > this thread), but I'll make a memo of sshfs and have a look at >>>>>>>>>>>> it. >>>>>>>>>>>> > >>>>>>>>>>>> > joerg >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> Sshfs didn't fix the problems that I was having with >>>>>>>>>>>> fossil+ssh, or >>>>>>>>>>>> at >>>>>>>>>>>> least only did so partially. Though, the problems that I was >>>>>>>>>>>> having >>>>>>>>>>>> with >>>>>>>>>>>> ssh were different. >>>>>>>>>>>> >>>>>>>>>>>> What I'd recommend doing is tunneling http or https through ssh, >>>>>>>>>>>> and >>>>>>>>>>>> host >>>>>>>>>>>> all of your fossil repositories on the host computer on your web >>>>>>>>>>>> server >>>>>>>>>>>> of >>>>>>>>>>>> choice via cgi. I do that with lighttpd, and it works >>>>>>>>>>>> flawlessly. >>>>>>>>>>>> >>>>>>>>>>>> Tim >>>>>>>>>>>> ______________________________********_________________ >>>>>>>>>>>> fossil-users mailing list >>>>>>>>>>>> [email protected].********org >>>>>>>>>>>> <[email protected]** >>>>>>>>>>>> scm.org <[email protected]**s**cm.org <http://scm.org> >>>>>>>>>>>> <fossil-users@lists.**fossil-scm.org<[email protected]> >>>>>>>>>>>> > >>>>>>>>>>>> >> >>>>>>>>>>>> http://lists.fossil-scm.org:********8080/cgi-bin/mailman/** >>>>>>>>>>>> listinfo/**** >>>>>>>>>>>> fossil-users<http://lists.****fo**ssil-scm.org:8080/cgi-bin/** >>>>>>>>>>>> ** <http://ssil-scm.org:8080/cgi-bin/**>< >>>>>>>>>>>> http://fossil-scm.org:8080/**cgi-bin/**<http://fossil-scm.org:8080/cgi-bin/**> >>>>>>>>>>>> > >>>>>>>>>>>> mailman/listinfo/fossil-users<****http://lists.fossil-scm.org:* >>>>>>>>>>>> *** >>>>>>>>>>>> 8080/cgi-bin/mailman/listinfo/****fossil-users<http://lists.** >>>>>>>>>>>> fossil-scm.org:8080/cgi-bin/**mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ______________________________********_________________ >>>>>>>>>>>> >>>>>>>>>>> fossil-users mailing list >>>>>>>>>>> [email protected].********org >>>>>>>>>>> <[email protected] >>>>>>>>>>> ** >>>>>>>>>>> scm.org <[email protected]**s**cm.org <http://scm.org>< >>>>>>>>>>> fossil-users@lists.**fossil-scm.org<[email protected]> >>>>>>>>>>> > >>>>>>>>>>> >> >>>>>>>>>>> http://lists.fossil-scm.org:********8080/cgi-bin/mailman/** >>>>>>>>>>> listinfo/**** >>>>>>>>>>> fossil-users<http://lists.****fo**ssil-scm.org:8080/cgi-bin/****<http://ssil-scm.org:8080/cgi-bin/**> >>>>>>>>>>> <http://fossil-scm.org:8080/**cgi-bin/**<http://fossil-scm.org:8080/cgi-bin/**> >>>>>>>>>>> > >>>>>>>>>>> mailman/listinfo/fossil-users<****http://lists.fossil-scm.org:** >>>>>>>>>>> ** >>>>>>>>>>> 8080/cgi-bin/mailman/listinfo/****fossil-users<http://lists.** >>>>>>>>>>> fossil-scm.org:8080/cgi-bin/**mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> Using Opera's revolutionary email client: >>>>>>>>> http://www.opera.com/mail/ >>>>>>>>> ______________________________********_________________ >>>>>>>>> fossil-users mailing list >>>>>>>>> [email protected].********org >>>>>>>>> <[email protected]** >>>>>>>>> scm.org <[email protected]**s**cm.org <http://scm.org>< >>>>>>>>> fossil-users@lists.**fossil-scm.org<[email protected]> >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> http://lists.fossil-scm.org:********8080/cgi-bin/mailman/**** >>>>>>>>> listinfo/** >>>>>>>>> **fossil-users<http://lists.******fossil-scm.org:8080/cgi-bin/****<http://fossil-scm.org:8080/cgi-bin/**> >>>>>>>>> <http://fossil-scm.org:8080/**cgi-bin/**<http://fossil-scm.org:8080/cgi-bin/**> >>>>>>>>> > >>>>>>>>> mailman/listinfo/fossil-users<****http://lists.fossil-scm.org:**** >>>>>>>>> 8080/cgi-bin/mailman/listinfo/****fossil-users<http://lists.** >>>>>>>>> fossil-scm.org:8080/cgi-bin/**mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>>>>>> ______________________________******_________________ >>>>>>> fossil-users mailing list >>>>>>> [email protected].******org <[email protected] >>>>>>> ** >>>>>>> scm.org >>>>>>> <[email protected]**scm.org<[email protected]> >>>>>>> >> >>>>>>> http://lists.fossil-scm.org:******8080/cgi-bin/mailman/** >>>>>>> listinfo/**** >>>>>>> fossil-users<http://lists.**fo**ssil-scm.org:8080/cgi-bin/**<http://fossil-scm.org:8080/cgi-bin/**> >>>>>>> mailman/listinfo/fossil-users<**http://lists.fossil-scm.org:** >>>>>>> 8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>> ______________________________****_________________ >>>>>> fossil-users mailing list >>>>>> [email protected].****org <[email protected]** >>>>>> scm.org <[email protected]>> >>>>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/**** >>>>>> fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/** >>>>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>>> ______________________________****_________________ >>>> fossil-users mailing list >>>> [email protected].****org <[email protected]** >>>> scm.org <[email protected]>> >>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/** >>>> **fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/** >>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >>>> > >>>> >>>> >>> >>> >>> >> >> -- >> Using Opera's revolutionary email client: http://www.opera.com/mail/ >> ______________________________**_________________ >> fossil-users mailing list >> [email protected].**org <[email protected]> >> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** >> fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users> >> > >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
