[fossil-users] fossil and SSL
Hi, I'm new to fossil and have several questions: 1) how do I open new tickets on fossil-scm.org? I didn't see something like "new ticket" on the web UI... 2) why do I have to do this http://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki manually? Shouldn't this be there out of the box? It's kind of basic functionality that one finds in any ticket tracking app... 3) as far as I understand if one accidentally starts fossil server/fossil ui - it will provide insecure access to the repository even if one had configured inetd/stunnel/fossil to use SSL, right? Is there a way to avoid such situations and force fossil to always use SSL? 4) what happens if one autosync/pull/push from a remote repository, does it also expose the local repository as in 3) ? thank you very much, ST ___ 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 and SSL
On 11/13/11 12:39, ST wrote: > 3) as far as I understand if one accidentally starts fossil > server/fossil ui - it will provide insecure access to the repository > even if one had configured inetd/stunnel/fossil to use SSL, right? Is > there a way to avoid such situations and force fossil to always use SSL? Depending on the situation, it may be relevant to note that "fossil ui" only listens on localhost. "fossil server" does not currently support SSL, though if there's interest in this, I can look into it. (For completeness, I mention setting up Fossil as a cgi application using apache, because you can fine-tune access to the repository using client certificate rules). > 4) what happens if one autosync/pull/push from a remote repository, does > it also expose the local repository as in 3) ? I don't quite understand what you're asking -- are you asking if sync/pull/push temporarily starts a server? If that's the case, then the answer is no. -- Kind regards, Jan Danielsson signature.asc Description: OpenPGP digital 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 and SSL
On Sun, 2011-11-13 at 16:14 +0100, Jan Danielsson wrote: > On 11/13/11 12:39, ST wrote: > > 3) as far as I understand if one accidentally starts fossil > > server/fossil ui - it will provide insecure access to the repository > > even if one had configured inetd/stunnel/fossil to use SSL, right? Is > > there a way to avoid such situations and force fossil to always use SSL? > >Depending on the situation, it may be relevant to note that "fossil > ui" only listens on localhost. So there is no chance that somebody from another IP will be able to access the repository, even if he has valid user login/password, right? > >"fossil server" does not currently support SSL, though if there's > interest in this, I can look into it. yes, there is. Thank you in advance! Should I open a feature request? (if yes where can I do it?) > >(For completeness, I mention setting up Fossil as a cgi application > using apache, because you can fine-tune access to the repository using > client certificate rules). Let's assume I did it. What happens when I accidentally start fossil server on a port different from that of apache? It will provide access to the repository without SSL, so neither apache nor stunnel do not help in such situation, correct? > > > 4) what happens if one autosync/pull/push from a remote repository, does > > it also expose the local repository as in 3) ? > >I don't quite understand what you're asking -- are you asking if > sync/pull/push temporarily starts a server? If that's the case, then the > answer is no. yes, that's what I meant :) Thank you, ST ___ 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 and SSL
On Sun, Nov 13, 2011 at 6:39 AM, ST wrote: > Hi, > > I'm new to fossil and have several questions: > > 1) how do I open new tickets on fossil-scm.org? I didn't see something > like "new ticket" on the web UI... > Anonymous ticketing was turned off because it was being flooded with support requests, rather than actual bug reports. For example, if it had been turned on, you probably would have written a bug report for this very question, wouldn't you? We prefer to reserve tickets for reporting actual malfunctions, and so on fossil-scm.org, we require a username/password in order to write a new ticket. That goes a long way toward keeping down the noise. It has been suggested that we create a "hold for moderation" system for tickets, such that anonymous tickets can be input, but do not actually go into the system until approved by a registered user. That would allow random passers-by on the internet to write tickets, but would also let us filter the tickets to keep real bug reports and discard support requests, "test tickets", and spam. I'll probably add a moderator system at some point, when I get a chance, if somebody else doesn't volunteer to do it first. But it isn't available right this moment. Sorry. > > 2) why do I have to do this > http://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki > manually? Shouldn't this be there out of the box? It's kind of basic > functionality that one finds in any ticket tracking app... > It is there out-of-the-box. The page above merely shows you how to modify the default setup, in case you want to do something a little different from what the out-of-the-box configuration does. > > 3) as far as I understand if one accidentally starts fossil > server/fossil ui - it will provide insecure access to the repository > even if one had configured inetd/stunnel/fossil to use SSL, right? Is > there a way to avoid such situations and force fossil to always use SSL? > "fossil ui" binds to 127.0.0.1 only, so it is not accessible from other machines on the network. If you do "fossil server" then your repository will be accessible remotely (on port 8080 by default) but people still need to know user names and passwords in order to log in. But it seems rather difficult to "accidently" run "fossil server", no? How do you accidentally start a server? > > 4) what happens if one autosync/pull/push from a remote repository, does > it also expose the local repository as in 3) ? > If you "fossil push" then information is transferred from the local repo to the remote repo. That's what "fossil push" is suppose to do. Fossil push/pull/sync does not activate the server mode, if that is what you are asking. > > thank you very much, > ST > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- 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 coredumping and reporting malformed manifest on sparc64
Hi, so I'm sending this mail the fourth time... are mails from outside the mailing list dropped? I got so far no mail that mine is waiting for being approved, and it was sent three days ago (g...@komkon2.de). On my NetBSD sparc64 I installed fossil 1.18 (the most recent version on pkgsrc): NetBSD $HOSTNAME 5.99.55 NetBSD 5.99.55 (NETRAT1) #6: Thu Jul 28 15:14:56 CEST 2011 $BUILDCONFIG sparc64 Compiling went fine, and after updating sqlite, it didn't even throw SQL errors anymore. ;-) So far, I can initialise a repository, add files, start a server, but whenever I want to commit, I get the message: fossil: manifest file (3) is malformed No matter how much I add or what it is. A typical log: A typical log: $ fossil init blakopf project-id: 52d8d1d05ce6b474e88e19a19b8a9a54a800589a server-id: b374ce2c60b1f7849e050f724f7f37dbd046f98e admin-user: gnrp (initial password is "115ecd") $ fossil open blakopf $ touch distinfo $ fossil add distinfo ADDED distinfo $ fossil commit -m "toll" New_Version: 248065b1c79f682e5138ebccdaf2c6da0d4e9070 fossil: manifest file (3) is malformed $ Then I installed the binary file for sparc (32-bit), and tested it as well on my old SparcStation LX, and there it ran fine. This works for now, but I'd rather like to have the right and self-compiled version for my architecture. The second issue is about fossil 1.20: I configured it manually and built it, but whenever I want to commit with that version, it simply coredumps. The pkgsrc-1.18 does not patch anything, but just compile fossil, so I think this is rather a fossil issue. I can of course provide traces of the calls, if you want. Regards, Julian ___ 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 8:53 PM, Julian Fagir wrote: > so I'm sending this mail the fourth time... are mails from outside the > mailing list dropped? Your prior mails never made it to the list - this is the first one we've gotten. > Compiling went fine, and after updating sqlite, it didn't even throw SQL > errors anymore. ;-) > Updating sqlite3? Are you linking it with a custom version instead of the one which is part of the fossil distro? > $ touch distinfo > $ fossil add distinfo > ADDED distinfo > $ fossil commit -m "toll" > is this also happening with non-empty files? > The second issue is about fossil 1.20: I configured it manually and built > it, > but whenever I want to commit with that version, it simply coredumps. The > ... > I can of course provide traces of the calls, if you want. > Yes, please - without those we can't do more than speculate about what the problem might be. AFAIK none of the regulars on this list use fossil on sparc platforms (especially BSD on sparc), so any details you can provide would be helpful. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 08:53:40PM +0100, Julian Fagir wrote: > Then I installed the binary file for sparc (32-bit), and tested it as well on > my old SparcStation LX, and there it ran fine. > This works for now, but I'd rather like to have the right and self-compiled > version for my architecture. Sure. Maybe you can debug this further? For what it is worth, fossil runs quite fine for me on linux-armv5tel. I only noticed some little troubles managing timestamps with floating point values; maybe fpu emulation there gives somewhat different values than other FPUs. I can try also on mips-n32; I still have not tried. Do you think it may be any similar? 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
[fossil-users] Providing fossil as a vcs, wiki or blog for 'users'
Hi, I'm somewhat new to fossil, but I'm absolutely astonished by the features it provides despite its simplicity. I'd like to provide fossil for our (ISPs) users because of its ease of automation: 1. fossil init 2. fossil user password 3. Generate DNS records, config and CGI for webserver Users would access the repository only via http or https, but they can also (though not automatically) get shell access. This way, we could simply provide an automated wiki and vcs creation. For people who dislike fossil as a wiki or vcs, there are still other solutions, but they're not automated, so that wouldn't stop me. So, my question: Do you think fossil is appropriate? As I said, I'm relatively new to fossil, and may not have tried out all features. Would you have security concerns about that? And do you have any suggestions what might help me with that? Are there standard settings you would suggest? Regards, Julian ___ 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 10:10 PM, Julian Fagir wrote: > Having to register to send mails to the list (and especially getting no > reports) is somewhat... unintuitive. > i can't even guess as to why the mailing list hasn't been working for you. > > Updating sqlite3? Are you linking it with a custom version instead of the > > one which is part of the fossil distro? > I'm sorry I don't remember that anymore. It didn't work, then I updated > sqlite3, then recompiled it, then it worked. > When you say "updated sqlite3", what exactly do you mean? Fossil has its own embedded copy. Did you replace that one (under src/sqlite3.*) with one you got from somewhere else? There are three files attached: > * configure log of 1.20 > * ktruss of 1.20 coredumping > This part: 11868 1 fossil write(0x5, 0x40b16808, 0x200) = 512, 1085368328 "\0\0\0\0\0\0\0\0\0\0\0\0\M-/\M^H\M-66\0\0\0\0\0\0\^B\0\0\0\^D\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" 11868 1 fossil SIGBUS SIG_DFL As best as i can tell that's your OS segfaulting, not fossil. It returns from a write() and then immediately throws a sigbus? sigbus is something i've only seen on sparc, and i've personally only seen it when linking to invalid system libs (e.g. those compiled for other platforms). A bit of googling shows sigbus to sometimes be alignment-related. The address being passed to write() is 0x40b16808 (dec=1085368328), which "should" be properly aligned for 32/64-bit. Can you run it through gdb (or the platform's equivalent) and give us a backtrace after the crash? Other googling suggests that a cast in one part of the code can cause corruption which first shows up as a sigbus further downstream. Could you run it through valgrind? That would help us rule out memory corruption. * ktruss of 1.18 complaining about manifest file > 1.18 is "ancient" and won't tell us much - a lot has happened since then. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 11:02:06PM +0100, Stephan Beal wrote: > On Sun, Nov 13, 2011 at 10:10 PM, Julian Fagir > wrote: > > Having to register to send mails to the list (and especially getting no > > reports) is somewhat... unintuitive. > > > > i can't even guess as to why the mailing list hasn't been working for you. I agree with Julian. There should be an answer, if the letter does not reach the list. I also like when it is not required to subscribe to send mails. > This part: > > 11868 1 fossil write(0x5, 0x40b16808, 0x200) = 512, 1085368328 > > > "\0\0\0\0\0\0\0\0\0\0\0\0\M-/\M^H\M-66\0\0\0\0\0\0\^B\0\0\0\^D\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" > 11868 1 fossil SIGBUS SIG_DFL > > As best as i can tell that's your OS segfaulting, not fossil. It returns > from a write() and then immediately throws a sigbus? sigbus is something > i've only seen on sparc, and i've personally only seen it when linking to > invalid system libs (e.g. those compiled for other platforms). A bit of > googling shows sigbus to sometimes be alignment-related. The address being > passed to write() is 0x40b16808 (dec=1085368328), which "should" be > properly aligned for 32/64-bit. I don't think the write is related to the SIGBUS. If it is similar to 'strace', the "= 512" means that the syscall succeeded and returned 512. > Other googling suggests that a cast in one part of the code can cause > corruption which first shows up as a sigbus further downstream. Could you > run it through valgrind? That would help us rule out memory corruption. I don't think valgrind runs on sparc. gdb will catch the sigbus perfectly. It should be quite tricky C code for a C compiler to generate bad-aligned accesses for a given platform. I'd like to know where is that bad access; I've not checked, but I'd imagine fossil has no tricky C code. 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 coredumping and reporting malformed manifest on sparc64
2011/11/13 Lluís Batlle i Rossell > It should be quite tricky C code for a > C compiler to generate bad-aligned accesses for a given platform. I'd like > to > know where is that bad access; I've not checked, but I'd imagine fossil > has no > tricky C code. > Fossil doesn't have any tricky C code (or at least it shouldn't - if you find some we'll call it a bug.) But SQLite does definitely have tricky C code. We've had SIGBUS problems running SQLite on sparc before, but I thought we had fixed all those. On the other hand, I don't have sparc on which to test SQLite so I'm not really sure. I know we don't have alignment problems on PPC, but I don't know if PPC is as fussy about alignment as Sparc is > > 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 > -- 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
Re: [fossil-users] fossil coredumping and reporting malformed manifest on sparc64
Hi, please excuse my overlengthy lines, it was easier to not-wrap this content. > As best as i can tell that's your OS segfaulting, not fossil. It returns > from a write() and then immediately throws a sigbus? sigbus is something > i've only seen on sparc, and i've personally only seen it when linking to > invalid system libs (e.g. those compiled for other platforms). A bit of > googling shows sigbus to sometimes be alignment-related. The address being > passed to write() is 0x40b16808 (dec=1085368328), which "should" be >properly aligned for 32/64-bit. Though I wouldn't bet on it, I think I've already seen SIGBUS on x86 with FreeBSD. > > It should be quite tricky C code for a > > C compiler to generate bad-aligned accesses for a given platform. I'd like > > to > > know where is that bad access; I've not checked, but I'd imagine fossil > > has no > > tricky C code. > > > > Fossil doesn't have any tricky C code (or at least it shouldn't - if you > find some we'll call it a bug.) But SQLite does definitely have tricky C > code. We've had SIGBUS problems running SQLite on sparc before, but I > thought we had fixed all those. On the other hand, I don't have sparc on > which to test SQLite so I'm not really sure. You're right, seems to be sqlite. $ gdb fossil-src-20111021125253/fossil GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64--netbsd"... (gdb) run init blakopf Starting program: /home/gnrp/temp/fossil-src-20111021125253/fossil init blakopf Program received signal SIGBUS, Bus error. 0x001b7560 in sqlite3CreateIndex (pParse=0x40b03008, pName1=, pName2=, pTblName=0x0, pList=0x40b10288, onError=, pStart=0x0, pEnd=0x0, sortOrder=0, ifNotExist=0) at ./src/sqlite3.c:82174 82174 pIndex->azColl[i] = zColl; (gdb) I used svn before which uses sqlite, too (at least it's the dependency), but it worked flawless. Regards, Julian ___ 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 05:15:59PM -0500, Richard Hipp wrote: > 2011/11/13 Lluís Batlle i Rossell > > > It should be quite tricky C code for a > > C compiler to generate bad-aligned accesses for a given platform. I'd like > > to > > know where is that bad access; I've not checked, but I'd imagine fossil > > has no > > tricky C code. > > > > Fossil doesn't have any tricky C code (or at least it shouldn't - if you > find some we'll call it a bug.) But SQLite does definitely have tricky C > code. We've had SIGBUS problems running SQLite on sparc before, but I > thought we had fixed all those. On the other hand, I don't have sparc on > which to test SQLite so I'm not really sure. There are some candidates I can think of. The easiest is definitely to just run gdb on a debug build and report the back trace of the crash. > I know we don't have alignment problems on PPC, but I don't know if PPC is > as fussy about alignment as Sparc is It isn't. (Older) ARM and SPARC are the most interesting platforms when it comes to strict alignment. PPC is normally configured to not trap, just like x86. 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 coredumping and reporting malformed manifest on sparc64
On Sun, Nov 13, 2011 at 11:21:43PM +0100, Joerg Sonnenberger wrote: > It isn't. (Older) ARM and SPARC are the most interesting platforms when > it comes to strict alignment. PPC is normally configured to not trap, > just like x86. I've only had sigbus troubles on mips, but I could have had them in arm I think. But if iirc, the linux arm has a sigbus catcher enabled by default that, although slow, corrects bad aligned accesses. I imagine most picky architectures have similar code, but not all of them have it enabled by default. Does the sparc kernel you use have that option, Julian? It can help at least to allow you running fossil. 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 and Git joint projects?
No comments on this?It works for me. Shall I commit this fix, or are there potential issues with it?On 10/11/2011, at 3:17 PM, Steve Bennett wrote:On 10/11/2011, at 2:50 PM, Steve Bennett wrote:On 10/11/2011, at 2:30 PM, Steve Bennett wrote:I tried to do something similar, using a git tag to keep track of where I was up tofor the incremental import.It mostly works, except the timeline shows each import as disconnected fromthe previous import. See attached.For the import at 21:40, I tried to import one previous rev hoping that they would bemerged, but this didn't happen. Is this "disconnect" fixable?I guess the problem is that the first commit of an incremental import has noancestor identified. Would it be possible to identify the ancestor somehow, eitheron the command line, or by finding the tip of the corresponding branch?The attached patch works for my simple case of always importing to the tip of trunk,but I'm sure it is highly dubious in other situations. --µWeb: Embedded Web Framework - http://uweb.workware.net.au/WorkWare Systems Pty LtdW: www.workware.net.au P: +61 434 921 300E: ste...@workware.net.au F: +61 7 3391 6002 import-incremental-ancestor.patch Description: Binary data ___ 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] mv + revert irregularity
Can anyone (Richard?) indicate which behavior is preferred? My suggestion (a), my suggestion (b), or the current behavior? I could work on a resolution for (a) or (b) if I knew which was desired. On Tue, 25 Oct 2011 16:29:32 -0700, wrote: I recently encountered an irregularity when using revert after a mv that is possibly a bug. Here's a shell script to demonstrate the issue: $ cat mvtest.sh #!/bin/sh -x rm -rf mvt1 mkdir mvt1 cd mvt1 fossil init t1.fossil mkdir dot1 cd dot1 fossil open ../t1.fossil touch file1 fossil add file1 fossil commit -m 'Added file1' [ -r file1 ] # verify file exists with original name mv file1 file2 fossil mv file1 file2 [ -r file2 ] # verify file exists under new name fossil revert # Error happens here: file2 is DELETED but file1 is not reinstated ls [ -r file2 -o -r file1 ] || echo "ERROR: File is gone (either name)" $ - Essentially the moved target is removed, but the original is not reinstated. I think that fossil should either (a) cancel the notion of the mv but leave the files untouched (which would match the fossil mv behavior) or (b) move the file back to the original name (which would match the revert behavior). -KQ P.S. I would have entered this as a ticket but it looks like tickets are disabled for non-contributors (which is understandable). - This mail sent through IMP: http://horde.org/imp/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- -KQ ___ 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 and Git joint projects?
On Sun, Nov 13, 2011 at 6:48 PM, Steve Bennett wrote: > No comments on this? > > It works for me. Shall I commit this fix, or are there potential issues > with it? > I think go ahead and commit. > > On 10/11/2011, at 3:17 PM, Steve Bennett wrote: > > On 10/11/2011, at 2:50 PM, Steve Bennett wrote: > > On 10/11/2011, at 2:30 PM, Steve Bennett wrote: > > I tried to do something similar, using a git tag to keep track of where I > was up to > for the incremental import. > > It mostly works, except the timeline shows each import as disconnected from > the previous import. See attached. > > For the import at 21:40, I tried to import one previous rev hoping that > they would be > merged, but this didn't happen. Is this "disconnect" fixable? > > > I guess the problem is that the first commit of an incremental import has > no > ancestor identified. Would it be possible to identify the ancestor > somehow, either > on the command line, or by finding the tip of the corresponding branch? > > > The attached patch works for my simple case of always importing to the tip > of trunk, > but I'm sure it is highly dubious in other situations. > > >-- > µWeb: Embedded Web Framework - http://uweb.workware.net.au/ > WorkWare Systems Pty Ltd > W: www.workware.net.au P: +61 434 921 300 > E: ste...@workware.net.au F: +61 7 3391 6002 > > > > > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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
