Re: [fossil-users] Path Separators
-- Forwarded message -- From: Clark Christensen cdcmi...@yahoo.com To: fossil-us...@lists.fossil-scm.org Date: Fri, 18 Dec 2009 09:36:43 -0800 (PST) Subject: [fossil-users] Path Separators I'm using Fossil on MS Windows under the TCC/4NT shell, and am mostly really happy with it. But the one thing that causes me the most problems is the forward slash path separator in the output from many fossil commands. I often find myself using fossil status, then wanting to copy/paste a path/to/file from the output into the next command, perhaps fossil gdiff. Obviously, on Windows, this fails. And it's a hassle to have to edit the path separators every time. How do other Win/Fossil users handle this? Would it make sense to change Fossil to output backslashes as the path separator on Windows platforms (path\to\file)? Has this already been discussed? Thanks! -Clark I was also trying to use fossil under TCC, but I had problems with the space in the default COMSPEC location (c:\Programs Files... etc). Finally I gave up and now I have an alias FOSS=CMD /C D:\PROGRAMS\UTILS\FOSSIL.EXE This seems to work OK (I'm a quite basic fossil user yet though). I would be happy if fossil were made to work better under TCC and am willing to help with testing and suggestions (no coding in C). Emil ___ 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] Wildcards not working on windows
Yes, this one works as expected. So it is a build issue? Thanks Emil On Mon, Sep 26, 2011 at 2:40 PM, Dmitry Chestnykh dmi...@codingrobots.com wrote: What should matter here is that it DOES work with the previous fossil version (1.18) and does NOT work with 1.19 - so obviously _something_ changed in fossil itself. Here's a binary of the same version built with MinGW: http://www.dchest.org/temp/fossil.exe Does it work for you? -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil stash gdiff
Hi This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC on Windows 7 SP1 I have configured winmerge as my gdiff-command and it works fine for me with `fossil gdiff`, however it doesn't work with `fossil stash gdiff`. Winmerge starts with an empty screen for each modified file. It seems the program is started with parameters like /temp/xDjd8RXRlXyBTEo /temp/RgKiAnjkXUrB61Z, and I can see some temporary files like this created, but obviously winmerge cannot pick them up. Some things I don't understand: -- why '/temp' on Windows? Obviuosly this does not use an environment variable. I have such a directory, but what if I hadn't? -- why two temporary files compared with one another? I was expecting only the file from the stash to be temporary and to be able to selectively move some of the changes to the working copy of the file. Or is there something I totally misunderstand? Regards Emil ___ 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 stash gdiff
On Mon, Mar 5, 2012 at 3:47 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Mar 5, 2012 at 8:29 AM, Emil Totev em...@tot-consult.com wrote: Hi This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC on Windows 7 SP1 I have configured winmerge as my gdiff-command and it works fine for me with `fossil gdiff`, however it doesn't work with `fossil stash gdiff`. Winmerge starts with an empty screen for each modified file. It seems the program is started with parameters like /temp/xDjd8RXRlXyBTEo /temp/RgKiAnjkXUrB61Z, and I can see some temporary files like this created, but obviously winmerge cannot pick them up. Some things I don't understand: -- why '/temp' on Windows? Obviuosly this does not use an environment variable. I have such a directory, but what if I hadn't? See http://www.fossil-scm.org/fossil/artifact/3e15b2476f1e?ln=861-903 for the current algorithm for finding temporary filenames. How would you suggest that this code be improved? Well, this should definitely be platform-specific. On Windows, the temporary files should be created in the directory pointed by the following environment variables (in this order): TMP TEMP USERPROFILE or in the Windows system directory. There is an API function GetTempPath(), or even better - GetTempFileName(). http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991(v=vs.85).aspx -- why two temporary files compared with one another? I was expecting only the file from the stash to be temporary and to be able to selectively move some of the changes to the working copy of the file. Stash loads both files into memory expected to do an internal diff. Only then does it realize that you want to use an external program, and so at that point it writes them both out to disk against so that the external program can access them. This might not be the most efficient, but it is simple to implement because it involves fewer special cases. Is this really something important that needs to be optimized? Well, this depends on the way people are using it. In my case, I tend to use `gdiff` with winmerge to also merge differences. I can make multiple unrelated changes at the same time, then stash them amd start merging back into the latest version in related groups. Maybe this is what `gmerge` is supposed to do, I didn't check it, but then there is no `stash gmerge` anyway. My expectations were that `stash gdiff ` would work like the regular `gdiff` and allow to change the working copy. Other should also step in to say if this is really something important that needs to be optimised. regards Emil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SSL support
Hi Is there any reason that the default fossil download for linux has been complied without SSL support, while the windows version has it? Would it be possible to add the SSL support for linux, or add a separate download option? In the meantime, is there somewhere an easily accessible download site for a fairly up-to-date linux fossil executable with SSL support? Thanks Emil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Linux binary downloads
Hi There are still inconsistencies in the binary downloads for linux at fossil's web site. File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable. There seems to be no 32-bit linux executable download. Could someone please fix that for this and future builds? Regards Emil ___ 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] Linux binary downloads
> Subject: Re: [fossil-users] Linux binary downloads > On 2/20/17, Emil Totev <em...@tot-consult.com> wrote: >> Hi >> >> There are still inconsistencies in the binary downloads for linux at >> fossil's web site. >> >> File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable. >> There seems to be no 32-bit linux executable download. >> >> Could someone please fix that for this and future builds? > > I suspect that the Mac and OpenBSD builds are 64-bits too. I suppose > we could produce 32-bit binaries, but I worry that they would be > largely untested, since I use 64-bit machines almost exclusively, as I > suspect most of the other Fossil developers do as well. If you really > need a 32-bit binary, you can always build your own use the source > tarball, right? > > Or, perhaps you are simply asking that the downloads be relabeled from > "x86" to "x64"? > Well, at least relabeling the downloads (and renaming the files itself) in order to avoid confusion would be nice. I guess I could build my own binary, of course, but I've always felt more comfortable using 'official' binaries. And 32-bit Linux is far from being an exotic platform even these days. Thanks Emil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Linux binary downloads
Hi There was a thread some time ago about the 1.36 linux binary download, but probably because it got hijacked by a troll, there hasn't been any reaction. Unlike previous releases which were ZIP files, the linux download is now a tar.gz, and it contains a dynamically linked 64bit executable instead of the statically linked 32bit executable used before. The dynamically linked 1.36 doesn't even work on CentOS 7 because (I think) of some shared library naming issues. Furthermore, even the old 1.35 binary does not completely work on CentOS 7 - 'fossil clone' returns "bad hostname lookup" for otherwise perfectly resolvable and pingable hosts. Can someone help / explain? Regards Emil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
