Re: [fossil-users] Shared SSH account consideration.
Thus said Stephan Beal on Wed, 24 Jul 2013 16:51:07 +0200: This probably isn't what you want to do, but i think you could add anonymous support by piping the /json/anonymousPassword and /json/login calls through to manage the two-step authentication process for anonymous users. That'd be an ugly way to do it, but it should work. I think I need to understand how ``anonymous'' works (not to mention my lack of fossil json knowledge) before I'll be able to say for certain which method would work with SSH. Anonymous SSH fossil access was just a thought that occurred to me and I wanted to share to see if there was any interest. Most of the setup for it is likely outside the scope of fossil. Basically it involves setting up a passwordless SSH account (perhaps named anonfsl) that when used has a ForceCommand that runs a special shell (possibly in a chroot) which will simply setup a fossil http with the requested fossil. At that point, fossil authentication would do the rest (including anonymous/nobody access). Thanks for the suggestion. Andy -- TAI64 timestamp: 400051f0c19c ___ 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 on cygwin64
2013/7/24 Warren Young war...@etr-usa.com: The bundled SQLite is almost certainly broken with that patch because it probably isn't using the Cygwin 1.7.20+ F_LCK_MANDATORY feature, so it won't cooperate properly with any program based on native Windows SQLite. Agreed. It was just an experiment. Closed now. I've already indicated that I'm going to wait until 3.7.18 comes out to see if they've fixed the backslash problem, and if they haven't, hack around it in Cygwin SQLite. That still requires you to build Fossil with the system SQLite to get my fixes. Next SQLite will be 3.8.0, which is in beta now, is already included in Fossil. This means that the backslash problem is not fixed yet. However, I think I found the cause of this problem! In os_win.c, the function used to determine the temporary directory is GetTempPath(). This function is documented to return: 1) The path specified by the TMP environment variable. 2) The path specified by the TEMP environment variable. 3) The path specified by the USERPROFILE environment variable. 4) The Windows directory. We see that it apparently returns the Windows directory, it cannot fiund any of the environment variables! SQLITE_CANTOPEN: os_win.c:34887: (5) winOpen(C:\Windows\etilqs_S8FDopj6QWC9mu4) - Access is denied. $ ls -la /cygdrive/c total 7265374 .. drwxrwx---+ 1 TrustedInstaller TrustedInstaller 0 May 23 09:10 Windows .. We don't have sufficient rights in the C:\Windows directory! Cygwin clears the Windows environment space, therefore none of the environment variables can be found. Proposed solution here (should move to sqlite if accepted): http://www.fossil-scm.org/index.html/info/fec3c7fe3a Regards, Jan Nijtmans ___ 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 on cygwin64
Native, pure-blooded windows binaries run just fine on cygwin, right? So why are we complicating the code with exceptions, special cases, and hacks for cygwin? -- 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 on cygwin64
2013/7/25 Richard Hipp d...@sqlite.org: Native, pure-blooded windows binaries run just fine on cygwin, right? So why are we complicating the code with exceptions, special cases, and hacks for cygwin? There are three things that a windows fossil binary can never do in the Cygwin environment: 1) handle Cygwin (Unix) links and mount points 2) setting the Windows file-system case-sensitive (use both Makefile and makefile) 3) use a Cygwin program as commit/stash editor For me personally those 3 things are not important, but apparently (see earlier messages in this thread) for other people it is. Unfortunately! I'm trying to find out what the minimum patch is to get the Cygwin build of fossil (both 32-bit and 64-bit) working again, so fossil can be built out-of-the box on Cygwin again. Of course, any feedback is welcome. Regards, Jan Nijtmans ___ 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 on cygwin64
Le 2013-07-25 06:43, Jan Nijtmans a écrit : 2013/7/25 Richard Hipp d...@sqlite.org: Native, pure-blooded windows binaries run just fine on cygwin, right? So why are we complicating the code with exceptions, special cases, and hacks for cygwin? There are three things that a windows fossil binary can never do in the Cygwin environment: 1) handle Cygwin (Unix) links and mount points 2) setting the Windows file-system case-sensitive (use both Makefile and makefile) 3) use a Cygwin program as commit/stash editor For me personally those 3 things are not important, but apparently (see earlier messages in this thread) for other people it is. Unfortunately! I'm trying to find out what the minimum patch is to get the Cygwin build of fossil (both 32-bit and 64-bit) working again, so fossil can be built out-of-the box on Cygwin again. Of course, any feedback is welcome. In Theory, fossil should build and work on fossil like on any other unix like Operating system (like linux/*bsd etc..) That's what cygwin is for. I have the feeling that in some part of the code, cygwin is treated as windows and in other place it is treated as unix-like (posix). I guess this is the problem. I believe that when building for cygwin, it should never goes on any #ifdef that are special for windows. So if cygwin really work as expected, fossil/sqlite code should not need much exceptions in order to work in Cygwin. Per example, on native windows we cannot just do ./configure make, we need a special manually maintain Makefile. But on cygwin, it *should* work. May be I'm a bit naive ? -- Martin G. ___ 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 on cygwin64
On Thu, Jul 25, 2013 at 07:44:16AM -0400, Martin Gagnon wrote: Le 2013-07-25 06:43, Jan Nijtmans a écrit : 2013/7/25 Richard Hipp d...@sqlite.org: Native, pure-blooded windows binaries run just fine on cygwin, right? So why are we complicating the code with exceptions, special cases, and hacks for cygwin? There are three things that a windows fossil binary can never do in the Cygwin environment: 1) handle Cygwin (Unix) links and mount points 2) setting the Windows file-system case-sensitive (use both Makefile and makefile) 3) use a Cygwin program as commit/stash editor For me personally those 3 things are not important, but apparently (see earlier messages in this thread) for other people it is. Unfortunately! I'm trying to find out what the minimum patch is to get the Cygwin build of fossil (both 32-bit and 64-bit) working again, so fossil can be built out-of-the box on Cygwin again. Of course, any feedback is welcome. In Theory, fossil should build and work on fossil like on any other unix like Operating system (like linux/*bsd etc..) That's what cygwin is for. I have the feeling that in some part of the code, cygwin is treated as windows and in other place it is treated as unix-like (posix). I guess this is the problem. I believe that when building for cygwin, it should never goes on any #ifdef that are special for windows. So if cygwin really work as expected, fossil/sqlite code should not need much exceptions in order to work in Cygwin. Per example, on native windows we cannot just do ./configure make, we need a special manually maintain Makefile. But on cygwin, it *should* work. This is also my understanding. And as for why we need fossil-for-cygwin from Richard... I think it is almost the same reason of why we need cygwin. :) I don't use windows because I like it's UI. When I use windows, I want it the closest to unix. This means terminals, fds, unix sockets, fork, process groups, etc. Cygwin is great at building all that over the weird windows OS. Using a non-cygwin program in cygwin quite breaks the magic (terminal fds not passing on fork, different filesystem views, paths, permissions, etc.). 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] how to delete old history?
Thank you all for the ideas. I'll have a look at shunning, if it could be used. I'll have a look at it. Best regards, Petr ___ 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 on cygwin64
On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote: In Theory, fossil should build and work on fossil like on any other unix like Operating system (like linux/*bsd etc..) That's what cygwin is for. grep tells me that there are 33 instances of the __CYGWIN__ macro in Fossil, in 8 different files. So if you use sed to change them all to __CYGWIN_OFF_ (or something else harmless) and then do ./configure; make, does it work? (I don't have cygwin installed so this is not something I can easily test.) If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. If it doesn't work, is that a bug in cygwin? -- 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 on cygwin64
On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote: On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote: In Theory, fossil should build and work on fossil like on any other unix like Operating system (like linux/*bsd etc..) That's what cygwin is for. grep tells me that there are 33 instances of the __CYGWIN__ macro in Fossil, in 8 different files. So if you use sed to change them all to __CYGWIN_OFF_ (or something else harmless) and then do ./configure; make, does it work? (I don't have cygwin installed so this is not something I can easily test.) If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. fossil clone in cygwin64 now works perfectly: $ sed s/__CYGWIN__/__CYGWIN__OFF__/ -i src/* $ ./configure $ make -j4 Thank you! :) ___ 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 on cygwin64
On Thu, Jul 25, 2013 at 8:05 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote: On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com wrote: In Theory, fossil should build and work on fossil like on any other unix like Operating system (like linux/*bsd etc..) That's what cygwin is for. grep tells me that there are 33 instances of the __CYGWIN__ macro in Fossil, in 8 different files. So if you use sed to change them all to __CYGWIN_OFF_ (or something else harmless) and then do ./configure; make, does it work? (I don't have cygwin installed so this is not something I can easily test.) If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. fossil clone in cygwin64 now works perfectly: $ sed s/__CYGWIN__/__CYGWIN__OFF__/ -i src/* $ ./configure $ make -j4 Move to banish __CYGWIN__ from both Fossil and SQLite sources. Do I have a second? -- 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 on cygwin64
On 7/25/13 2:05 PM, Lluís Batlle i Rossell wrote: [---] grep tells me that there are 33 instances of the __CYGWIN__ macro in Fossil, in 8 different files. So if you use sed to change them all to __CYGWIN_OFF_ (or something else harmless) and then do ./configure; make, does it work? (I don't have cygwin installed so this is not something I can easily test.) If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. fossil clone in cygwin64 now works perfectly: So .. we used the __CYGWIN__ macro to explicitly break fossil on cygwin? That seems unnecessarily creative to me. Out of curiosity (there must be one or two here who put them there): What are/were their intended purposes [in the fossil code]? /Jan ___ 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 on cygwin64
On 7/25/13 2:10 PM, Richard Hipp wrote: Move to banish __CYGWIN__ from both Fossil and SQLite sources. Do I have a second? Seconded. /Jan ___ 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 on cygwin64
2013/7/25 Richard Hipp d...@sqlite.org: If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. Doing that will break four things: - Accessing a check-out repository on Cygwin, while the previous check-out was done in win32. - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil. - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of UNC paths. - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN) If it doesn't work, is that a bug in cygwin? More likely, it's a limitation of Cygwin running on Windows. Not seconded. In SQLite various __CYGWIN__ #ifdef's can be removed if another locking mechanism is put in place. Attached is the current patch the Cygwin people use for their build of SQLite accomplishing this. But this only works on Cygwin 1.7.20, and it doesn't follow the SQLite coding style, so it will need some more work. Regards, Jan Nijtmans sqlite3-3.7.17-3.src.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] Fossil on cygwin64
On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote: 2013/7/25 Richard Hipp d...@sqlite.org: If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. Doing that will break four things: - Accessing a check-out repository on Cygwin, while the previous check-out was done in win32. - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil. - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of UNC paths. - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN) As a cygwin user, this breakage is what I expect by any cygwin version of a program, be it fossil, mercurial, git, vim, ... I'd never use a cygwin-git checkout with non-cygwin-git, for example. I never tried and i would not expect it to work. If it doesn't work, is that a bug in cygwin? More likely, it's a limitation of Cygwin running on Windows. Not seconded. In SQLite various __CYGWIN__ #ifdef's can be removed if another locking mechanism is put in place. Attached is the current patch the Cygwin people use for their build of SQLite accomplishing this. But this only works on Cygwin 1.7.20, and it doesn't follow the SQLite coding style, so it will need some more work. I have no idea how locking has to be handled in cygwin, but if the issue is at using a sqlite db with both cygwin and non-cygwin programs, this is a tricky thing. As for me, I don't expect cygwin programs' data to cope well with windows programs' data. 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] Random thoughts on Fossil v2
On Sun, Jul 21, 2013 at 10:12 AM, Eduardo Morras emorr...@yahoo.es wrote: On Sun, 21 Jul 2013 12:54:05 +0200 Stephan Beal sgb...@googlemail.com wrote: I post them here then: a) Creation of graphs to show statistics. I'm on it now, writing a minimal png with 32bit ARGB color and a minimal graph lib. Link ? Do you know lodepng / picopng ? http://lodev.org/lodepng/ -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato Tcl'2013, Sep 23-27, New Orleans, LA, USA @ http://www.tcl.tk/community/tcl2013/ EuroTcl'2013, July 6-7, Munich, GER ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Status of the hidden tag
From fossil's /shun page: Do not shun artifacts merely to remove them from sight - set the hidden tag on such artifacts instead. The only other reference I could find while searching this list was a note from drh (circa 2009 or so?) noting that it had not been implemented yet. Is this still the case? I just tried, via the web interface, adding a hidden tag to a checkin on one of my mistake branches and the timeline still showed the item. Perhaps there's a setting I've missed -- or perhaps something else? $ fossil version This is fossil version 1.26 [674a24a360] 2013-07-20 16:43:45 UTC Best Regards, Themba ___ 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 on cygwin64
On 7/25/2013 06:24, Jan Danielsson wrote:
So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.
It is well known that the creators of Cygwin do this sort of thing
because They're Just Mean. Maybe Fossil's creators are the same way?
Out of curiosity (there must be one or two here who put them there):
What are/were their intended purposes [in the fossil code]?
I'm up for some spelunking. Let's go:
compat/zlib/gzguts.h: Forces HAVE_VSNPRINTF to true. This sounds like a
configure script bug to me. If it's fixed now, the ifdef should go. If
vsnprintf() is still not being detected on Cygwin, that problem should
be corrected at its source, not hacked around like this.
compat/zlib/contrib/inflate86/inffast.S: ELF vs. COFF executable format
inference, to provide the leading underscore MS linkers want. Since the
resulting binary works, one of the following must be true:
a) Fossil is using the plain C version, not the optimized assembly; or
b) the Cygwin linker now copes with this difference; or
c) WIN32 is somehow getting defined by this point, so the __CYGWIN__
test is redundant.
compat/zlib/contrib/puff/pufftest.c, compat/zlib/{examples,test}/*:
Example code that came with zlib, so it doesn't matter if it doesn't
build and work correctly.
compat/zlib/zutil.h: This seems bogus. The way it's coded implies that
WIN32 is defined when __CYGWIN__ is, which isn't currently true,
unless you pass -mwin32 to the compiler, which you shouldn't in this
case. However, if I'm wrong, and WIN32 *is* somehow being defined here,
the test is appropriate and shouldn't be removed: zlib blobs created
under Cygwin *should* be marked as having been created on Unix rather
than on Win32.
src/sqlite3.c: __CYGWIN__ stuff to be removed through other channels. :)
src/th_tcl.c: Not sure if this one can go or not. It might depend on
whether your Fossil is linking to a Cygwin Tcl or the native Windows
Tcl. Lluís, if you're reading this, did you test TH1 under Cygwin?
Which Tcl is your fossil.exe linked to? (Ask ldd if you're not sure.)
___
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 on cygwin64
On Thu, Jul 25, 2013 at 02:42:23PM -0600, Warren Young wrote:
On 7/25/2013 06:24, Jan Danielsson wrote:
So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.
It is well known that the creators of Cygwin do this sort of thing
because They're Just Mean. Maybe Fossil's creators are the same
way?
Out of curiosity (there must be one or two here who put them there):
What are/were their intended purposes [in the fossil code]?
I'm up for some spelunking. Let's go:
compat/zlib/gzguts.h: Forces HAVE_VSNPRINTF to true. This sounds
like a configure script bug to me. If it's fixed now, the ifdef
should go. If vsnprintf() is still not being detected on Cygwin,
that problem should be corrected at its source, not hacked around
like this.
compat/zlib/contrib/inflate86/inffast.S: ELF vs. COFF executable
format inference, to provide the leading underscore MS linkers want.
Since the resulting binary works, one of the following must be true:
a) Fossil is using the plain C version, not the optimized assembly; or
b) the Cygwin linker now copes with this difference; or
c) WIN32 is somehow getting defined by this point, so the
__CYGWIN__ test is redundant.
compat/zlib/contrib/puff/pufftest.c, compat/zlib/{examples,test}/*:
Example code that came with zlib, so it doesn't matter if it doesn't
build and work correctly.
compat/zlib/zutil.h: This seems bogus. The way it's coded implies
that WIN32 is defined when __CYGWIN__ is, which isn't currently
true, unless you pass -mwin32 to the compiler, which you shouldn't
in this case. However, if I'm wrong, and WIN32 *is* somehow being
defined here, the test is appropriate and shouldn't be removed: zlib
blobs created under Cygwin *should* be marked as having been created
on Unix rather than on Win32.
src/sqlite3.c: __CYGWIN__ stuff to be removed through other channels. :)
src/th_tcl.c: Not sure if this one can go or not. It might depend
on whether your Fossil is linking to a Cygwin Tcl or the native
Windows Tcl. Lluís, if you're reading this, did you test TH1 under
Cygwin? Which Tcl is your fossil.exe linked to? (Ask ldd if you're
not sure.)
I'm wondering, why someone would want to build cygwin version of fossil
and link with native TCL and vice-versa ? When you build cygwin
version, you can have everything you need in cygwin version under the
cygwin tree. Tyring to mixte native and cygwin stuff here is looking for
trouble.
If you use mingw toolchain inside cygwin to produce native Windows
binary, it's another story, (this is like cross compiling) and in that
case, __CYGWIN__ should not be defined at all and this should behave
exactly like building directly fossil on a mingw/msys setup using the
Makefile.mingw. Exactly like cross-compiling mingw apps under FreeBSD
or Linux.
(I don't know how the ./configure script deal with cross-compiling)
--
Martin G.
___
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 on cygwin64
On 7/25/2013 07:46, Jan Nijtmans wrote: 2013/7/25 Richard Hipp d...@sqlite.org: If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. Doing that will break four things: - Accessing a check-out repository on Cygwin, while the previous check-out was done in win32. Are you merely predicting this, or are you reporting that you've tried it and found that it does break when you do this? I don't recall seeing any __CYGWIN__ protected code blocks on my spelunking trip -- reported to the list earlier -- that would cause such an incompatibility. - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil. What are you talking about? Fossil's __CYGWIN__ protected code blocks don't affect how the Cygwin DLL interprets file paths. - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of UNC paths. Ditto. - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN) What problem are you actually envisioning here? There is no TortoiseFossil to cause problems in this case. If someone builds a pure Cygwin fossil.exe without the __CYGWIN__ blocks enabled, what native Windows program runs to break the Cygwin fossil.exe? If there is such a problem, the fix is simple: ./configure --disable-internal-sqlite Then it builds against my Cygwin SQLite library, which *does* cope with the problems you're thinking of. If you build Fossil with all the __CYGWIN__ blocks disabled and use the internal SQLite, it should behave as if linking to Cygwin SQLite 3.7.17-3+ with the POSIX advisory locking mode enabled. That's perfectly fine if you don't need the SQLite DB file to be accessible from a native Windows SQLite based program at the same time. this only works on Cygwin 1.7.20 That isn't a problem in the Cygwin SQLite package, since you have to go out of your way to update the SQLite package only, without updating the Cygwin DLL, too. I can understand if the SQLite developers want to hold off adopting this patch into the shipped version of SQLite. They may have Cygwin based customers who don't keep their Cygwin installations up to date. Plus, I'd like to see this mandatory locking feature get more than a month of use before all the __CYGWIN__ blocks get ripped out of upstream SQLite. Once we're sure the new Cygwin DLL based locking works just as well as the stuff we've replaced, I'd be happy to see upstream adopt this patch. and it doesn't follow the SQLite coding style, so it will need some more work. I tried to write the patch to blend into the surrounding code. I've just noticed the spaces-vs-tabs difference, which I've fixed in my local copy. Is there anything more substantial that needs changing? Perhaps you don't like my enum naming scheme, or the fact that I used an enum for my constants instead of preprocessor macros. ___ 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 on cygwin64
Warren Young wrote: I'm up for some spelunking. Let's go: What about all the __CYGWIN__ blocks in the following files? 1. add.c 2. blob.c 3. checkin.c 4. db.c 5. file.c 6. utf8.c Frankly, I'm not convinced of how many of these are actually necessary. -- Joe Mistachkin ___ 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] New command proposal?
It appears that gitolite works much like mercurial-server. What I would expect (I haven't set up fossil yet, because I need this functionality) is that the authorized_keys file for the fossilcm user would have: command=/home/fossilcm/bin/fossil gate admin ssh-rsa ... command=/home/fossilcm/bin/fossil gate someuser ssh-rsa ... command=/home/fossilcm/bin/fossil gate amb ssh-rsa ... command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... where the name after gate defines the fossil user that this represents, and the ... are the public keys from the particular users. Then fossil would do whatever the remote command is with LOGIN set to user, e.g., amb, so that whatever permissions amb has to the particular xxx.fossil file would apply. All the fossils would reside in a directory, e.g. ~/fossils and the remote user would say something like: fossil clone ssh://fossilcm@fossilhost/one.fossil one.fossil and it would only validate against the public key that that user has. This way the remote user can't access any files other than the fossils in that directory. In the simplest version of this, the administrator of the fossilcm account would have to manually add user amb's public key to fossilcm's authorized_keys file and add the command= to the front of it (but I outline below a very simple way to allow this to be done remotely after the first one is set up by the admin). mercurial-server automates this via a commit/push hook on a special repository so that keys get automatically added to the authorized_keys file. Their setup is more complicated than necessary, given existing fossil controls. I would simply set it up as follows: ~fossilcm/bin: fossil - the executable ~fossilcm/.ssh: authorized_keys - auto generated by changes to the admin fossil ~fossilcm/fossils: fossil-admin.fossil - the special repository one.fossil - user accesible fossils two.fossil three.fossil the fossil-admin repository would simply contain the ssh pub files for the users allowed to access any of the controlled fossils: admin.pub someuser.pub amb.pub otheruser.pub and all the permission would be handled by the normal fossil commands against the set of users defined in the fossil-admin fossil - in this case: admin, someuser, amb, otheruser. (Presumably only admin is allowed to commit to fossil-admin.) You could make the fossil-admin.fossil more complex to make the permissions controlled by the ssh key as well, but if I understand fossil, that's already well handled by existing mechanisms. Sorry, that's long, but I think complete and simple. If not clear, please ask for clarification. This is functionality that I *REALLY* want, but I don't know enough about fossil and the code base to make it happen. Thanks ../Dave ___ 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 on cygwin64
On 7/25/2013 04:29, Richard Hipp wrote: Native, pure-blooded windows binaries run just fine on cygwin, right? Mostly, yes. There are exceptions. The Windows console infrastructure isn't as general and as easy to hook into a the Unix TTY equivalent, so there are programs that only work properly in a native Windows console. Programs in this class typically fail when run in mintty, or under screen, or via Cygwin ssh. So why are we complicating the code with exceptions, special cases, and hacks for cygwin? Ideally, Cygwin should be treated as just another Unix-like OS. Unfortunately, it runs on top of a Windows kernel, which simply doesn't do some things in a way that allows it to provide proper POSIX/Linux semantics. Over time, Cygwin has gotten better at patching over these differences, but some are intractable enough that they remain. Part of the problem is a need to continue working with the native Windows side of things. The mandatory vs advisory file locking stuff is a good example. I assume you're aware -- at least peripherally -- of the changes that happened to Cygwin SQLite recently. It's all an attempt to paper over yet another of these differences between Windows and POSIX semantics. ___ 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 on cygwin64
On 7/25/2013 16:03, Joe Mistachkin wrote: Warren Young wrote: I'm up for some spelunking. Let's go: What about all the __CYGWIN__ blocks in the following files? I guess they already got taken out of the trunk. I did my spelunking in a current pull of the tree. That explains why Richard referred to 8 files having CYGWIN blocks, but I found only 7. He must have been referring to src/* only. I assume that whoever removed these blocks did the same sort of analysis I did for those outside the src subtree, and determined that they were in fact pointless. ___ 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 on cygwin64
Warren Young wrote: I guess they already got taken out of the trunk. I did my spelunking in a current pull of the tree. I'm simply searching trunk for __CYGWIN__. -- Joe Mistachkin ___ 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] Random thoughts on Fossil v2
My apologies for taking so long to respond myself, I've been a little under the weather the last couple of days. I appreciate the time you took in responding to my first message on this thread. On Tue, Jul 23, 2013 at 4:54 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice jayare...@gmail.comwrote: ...Some random thoughts on Fossil v2 as a library (call it libfossil2) and as a default client / server binary which makes use of the library (call it fossil2client or fossil2scm, I seem to have used both names), which I realize you might already know about or have thought of but just in case... (if only because I have a terminal case of Male Answer Syndrome) (and, wow, this got longer than I expected, and I apologize in advance for telling you in detail all about everything you Probably Already Knew and moreover Knew Far More About Than I Do...): Rabid rants are in no way excluded from participation, provided they remain polite ;). * Fossil2client should *not* expect or require libfossil2 to be compiled into it statically, or have an embedded copy of the source for libfossil2 within the source of fossil2client. Right. My goal here is a normal library/client relationship. Static linking is an important option for fossil (because it's popular with users) but is not a requirement. Debian, which is the Linux distro I am most familiar with, already does this (or appears to anyway) with fossil v1, see http://packages.debian.org/jessie/fossil where the fossil binary depends on libsqlite3-0 (= 3.7.11 at this instant). I don't know if fossil v1 ships with an embedded code copy of sqlite (I haven't looked), Strange. Yes, fossil embeds its own. That dependency was probably automatically determined by a script which looks for common symbol names in the resulting binary. but if it does they're stripping it in favor of sqlite as an independent library object and making their binary for fossil v1 dependent on that independent sqlite library object. i suspect it's only a bookkeeping error, and that (ld fossil) on that system will reveal that it does not link against /usr/lib/libsqlite3.so I fully expect they would / will do the same with fossil2scm as a dependency of libfossil2. They'll probably do what's easiest - if it's distributed as a package which builds everything together (as i suspect it will be) then they'll probably just 'make; make install'. I'm responding to all these together as they're related. I fully agree that, for binaries (and sources) distributed by The Fossil Project (e.g. via www.fossil-scm.org) for the MS Windows platform, and likely MacOS/X, etc, static linking (modulo libraries known to be provided by the platform itself) and providing all the necessary auxiliary libraries (either as embedded sources or as a separate tar ball) is the way things are done. I also fully agree that, for binary distribution by TFP to Unix/Linux platforms, static linking is the way things are done (especially since I see pretty much only one generic For Linux binary being distributed), and that for source distribution by TFP again providing all the necessarily auxiliary libraries via one means or another is done if only as a convenience to the person downloading so that they don't have to try to find all the necessary parts, figure out if they have parts that are compatible, etc. However. I do sincerely believe that in general, for binary (and source) distribution of the Fossil application by independent Unix and Linux distributions to end-users of those distributions (e.g. where an end-user is not receiving Fossil directly from TFP but from the creator of the distribution that end-user is using), static linking of the binary Fossil application to the libraries it uses (and in particular to sqlite3) is not done, and distribution of any library sources embedded within the source to the Fossil application is not done. Instead, the binary Fossil application as compiled by the distribution is configured to link dynamically to a system copy also provided by the distribution of any libraries it needs (and in particular to the system copy of the library for sqlite3), and the source for the Fossil application has any embedded copies of library sources stripped out (in particular the source for the sqlite3 library) in favor of the source to the system copy of any libraries it needs (again in particular the sqlite3 library). Furthermore, it is possible at least in principle for the version of the binary Fossil application to be updated independently of the versions of the libraries it uses (again in particular sqlite3); the system copy of sqlite3 that is available might be an older version or a newer version then the version of sqlite3 which TFP ships with the source to fossil as an embedded source. Under these circumstances, it is not possible for the Fossil binary as distributed by an independent Unix / Linux
Re: [fossil-users] Random thoughts on Fossil v2
[Effing GMail sent this before it was fully responded to. My fault for writing my response using the GMail web interface instead of composing it in a text editor like a Real Programmer would have done.] On Thu, Jul 25, 2013 at 9:17 PM, Joseph R. Justice jayare...@gmail.comwrote: My apologies for taking so long to respond myself, I've been a little under the weather the last couple of days. I appreciate the time you took in responding to my first message on this thread. On Tue, Jul 23, 2013 at 4:54 AM, Stephan Beal sgb...@googlemail.comwrote: On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice jayare...@gmail.comwrote: ...Some random thoughts on Fossil v2 as a library (call it libfossil2) and as a default client / server binary which makes use of the library (call it fossil2client or fossil2scm, I seem to have used both names), which I realize you might already know about or have thought of but just in case... (if only because I have a terminal case of Male Answer Syndrome) (and, wow, this got longer than I expected, and I apologize in advance for telling you in detail all about everything you Probably Already Knew and moreover Knew Far More About Than I Do...): Rabid rants are in no way excluded from participation, provided they remain polite ;). * Fossil2client should *not* expect or require libfossil2 to be compiled into it statically, or have an embedded copy of the source for libfossil2 within the source of fossil2client. Right. My goal here is a normal library/client relationship. Static linking is an important option for fossil (because it's popular with users) but is not a requirement. Debian, which is the Linux distro I am most familiar with, already does this (or appears to anyway) with fossil v1, see http://packages.debian.org/jessie/fossil where the fossil binary depends on libsqlite3-0 (= 3.7.11 at this instant). I don't know if fossil v1 ships with an embedded code copy of sqlite (I haven't looked), Strange. Yes, fossil embeds its own. That dependency was probably automatically determined by a script which looks for common symbol names in the resulting binary. but if it does they're stripping it in favor of sqlite as an independent library object and making their binary for fossil v1 dependent on that independent sqlite library object. i suspect it's only a bookkeeping error, and that (ld fossil) on that system will reveal that it does not link against /usr/lib/libsqlite3.so I fully expect they would / will do the same with fossil2scm as a dependency of libfossil2. They'll probably do what's easiest - if it's distributed as a package which builds everything together (as i suspect it will be) then they'll probably just 'make; make install'. I'm responding to all these together as they're related. I fully agree that, for binaries (and sources) distributed by The Fossil Project (e.g. via www.fossil-scm.org) for the MS Windows platform, and likely MacOS/X, etc, static linking (modulo libraries known to be provided by the platform itself) and providing all the necessary auxiliary libraries (either as embedded sources or as a separate tar ball) is the way things are done. I also fully agree that, for binary distribution by TFP to Unix/Linux platforms, static linking is the way things are done (especially since I see pretty much only one generic For Linux binary being distributed), and that for source distribution by TFP again providing all the necessarily auxiliary libraries via one means or another is done if only as a convenience to the person downloading so that they don't have to try to find all the necessary parts, figure out if they have parts that are compatible, etc. However. I do sincerely believe that in general, for binary (and source) distribution of the Fossil application by independent Unix and Linux distributions to end-users of those distributions (e.g. where an end-user is not receiving Fossil directly from TFP but from the creator of the distribution that end-user is using), static linking of the binary Fossil application to the libraries it uses (and in particular to sqlite3) is not done, and distribution of any library sources embedded within the source to the Fossil application is not done. Instead, the binary Fossil application as compiled by the distribution is configured to link dynamically to a system copy also provided by the distribution of any libraries it needs (and in particular to the system copy of the library for sqlite3), and the source for the Fossil application has any embedded copies of library sources stripped out (in particular the source for the sqlite3 library) in favor of the source to the system copy of any libraries it needs (again in particular the sqlite3 library). Furthermore, it is possible at least in principle for the version of the binary Fossil application to be updated independently of the versions of the libraries it uses (again in
Re: [fossil-users] Fossil on cygwin64
On 7/25/2013 16:52, Joe Mistachkin wrote: Warren Young wrote: I guess they already got taken out of the trunk. I did my spelunking in a current pull of the tree. I'm simply searching trunk for __CYGWIN__. I was stuck on a branch from February. wince Now that I'm actually looking at the trunk, back into the cave we go: add.c, line 25: You should be #including windows.h here instead of providing these prototypes. That makes Cygwin's w32api package a build dependency, but if fossil.exe is going to do registry API calls when built with Cygwin, that seems a reasonable dependency. add.c, filenames_are_case_sensitive(): Keep it. The Cygwin registry setting *is* a better default here than the Unix case default. blob.c, blob_write_to_file(): Why not let the OS catch this error? I'd take this test out for native Windows, too. blob.c, BOM and UTF-16 awareness: I think this code is well-intentioned for Cygwin, but probably not quite right. For Cygwin, you should probably assume UTF-8 by default, as for any modern *ix. Text editors under Cygwin default to UTF-8, not UTF-16 as do native Windows Unicode text editors. If there is a BOM, you should probably do the conversion from UTF-16 to UTF-8 on all platforms, not just Windows and Cygwin. checkin.c, commit_warning(): Really? Why can't you use iconv(3)? db.c, db_open(): Wrong. Fix or remove. First, hard-coding a conversion to /cygdrive/%c/%s will break if the user has changed the cygdrive mount point in /etc/fstab. This is more common than you may realize. If you mount cygdrive at the root, you can use shorter quasi-DOS paths like /c/Windows. I use this feature. Second, if Fossil really must mung Windows drive paths to POSIX paths on Cygwin instead of passing paths blindly to the OS like any other program would, it should be done at a higher level than the DB layer. If you really must mung paths, ask the Cygwin DLL to do it for you, via cygwin_conv_path(). This fixes the cygdrive mount point problem, too. Personally, I'd say remove the ifdef entirely. db.c, db_open_config(), user DB location: This function has its heart in the right place, but it's awfully brittle. Consider just the native Windows case. If, the first time you run Fossil, LOCALAPPDATA isn't defined, it will put the DB in %APPDATA%. But if LOCALAPPDATA is then later defined, it doesn't continue searching the fall-back hierarchy to find its earlier DB file. It will create a new one in %LOCALAPPDATA% and ignore the one it created earlier, losing any settings you had. The following algorithm provides proper fall-back behavior for native Windows and ensures that pure Cygwin users get the ~/.fossil file they expected: 1. Search the three native Windows environment variable directories for _fossil, using the first one found. 2. If none are found and this is Cygwin, try ~/.fossil, too. 3. If the DB still isn't found, create a new one in ~/.fossil if this is Cygwin, or in %FOO%/_fossil on native Windows, where %FOO% is the highest-precedence environment variable found. Alternatively, add a feature to Fossil that lets you override the hard-coded DB file location(s) with a high-precedence environment variable. (That is, a second EV on Unix, and a fourth on Windows.) Say, FOSSILDB. Then you can set it to c:\cygwin\home\foo to get interoperability between native and Cygwin fossil.exe. There might be Unix users who can find a use for this feature, too. db.c, db_open_config(), '.' - '_' smashing: Cargo cult detected. Windows NT derivatives and programs written with NT-derived OSes in mind treat files with a leading dot like any other file. The only programs that don't are those that insist on having a file name extension -- which shouldn't be given .fossil files to begin with -- and programs with DOS/Win9x heritages. Cygwin dropped Win9x support in 2009. Microsoft dropped Win9x support in 2006. DOS and Win16 compatibility got dropped for 64-bit systems in Vista, in 2007. We no longer need to pussy-foot around leading dots on Windows in 2013. The comment claims some window systems [have] problems with file names beginning with a dot. Are any of these systems still supported by Microsoft? And, many apps have problems? Quantify many. If nonzero, how many of these require access to Fossil DB files? db.c, cmd_open(): Same as above. For that matter, I think Fossil 2.0 should use .fslckout on native Windows, too, and avoid the need for any special-casing here at all. (Why 2.0? It's a breaking change, so it shouldn't be done lightly.) db.c, db_open_config(), file access test: This should be unconditional, or be removed. Unix gets by without it, so there must be some higher level code that checks whether the DB was opened for writing. Surely chmod 400 ~/.fossil is a problem on Unix, too? db.c, db_open_repository(): Another bogus /cygdrive hack. Remove or replace with a
Re: [fossil-users] Fossil on cygwin64
On 7/24/2013 05:06, Warren Young wrote: On 7/24/2013 02:33, Jan Nijtmans wrote: Just wait on the Cygwin64 people to bring out a new Sqlite package with the same fixes already done in Cygwin32. Um, it's the same people. Me. :) Oh, I see what you mean. I forgot that I didn't release 3.7.17-3 for 64-bit as well. You're the first person to ask, and it was so obliquely that I didn't realize it at first. :) I'll be RFU'ing 3.7.17-3 for Cyginw64 soon. ___ 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 on cygwin64
Some of what I wrote was based on wrong assumptions due to being stuck here on a February branch of Fossil's repo. Now that I've looked at the __CYGWIN__ blocks in an up-to-date Fossil trunk, I understand your post better, Jan. Updated commentary inline below. On 7/25/2013 15:59, Warren Young wrote: On 7/25/2013 07:46, Jan Nijtmans wrote: 2013/7/25 Richard Hipp d...@sqlite.org: If it does work, then I move for the immediate banishment of all __CYGWIN__ macros. Doing that will break four things: - Accessing a check-out repository on Cygwin, while the previous check-out was done in win32. I proposed two fixes for this in my second spelunking report. (My improved algorithm for finding _fossil, and the FOSSILDB feature.) - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil. For the most part, Fossil shouldn't be caring as much about path details as it currently does. Most programs just blindly throw paths at the OS, and let it deal with it. To the extent that Fossil *does* have to care, it shouldn't try to fix backslashes or drive letters for Cygwin users. The Cygwin DLL does this already, albeit with a warning. Duplicating the functionality in Fossil is wrongheaded, for the same reason you don't duplicate functionality in any other program. ./configure --disable-internal-sqlite Then it builds against my Cygwin SQLite library, which *does* cope with the problems you're thinking of. I see that this doesn't work right now, because I hadn't yet shipped 3.7.17-3 for Cygwin64. I'm working on fixing that now. I've just noticed the spaces-vs-tabs difference, which I've fixed in my local copy. This will appear in my 64-bit packages. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
