Re: [fossil-users] Ignoring Apple Xcode user files
I use the following string for Admin Settings ignore-glob: */xcuserdata/*,build/*,*.mode1v3,*.pbxuser,*.orig -- Dmitry Chestnykh http://www.codingrobots.com On Sun, Dec 16, 2012 at 10:19 PM, K k...@lightpowered.org wrote: Hello, Now that I wish to keep my Xcode project configuration 'file' in my repo, I've run into some 'fun'. I say 'file' because project.xcodeproj is actually a dir, with both project configuration and user data in it. Apparently the Git workflow to handle this is: echo 'xcuserdata/' .gitignore git add *.xcodeproj. What would be the equivalent in Fossil please? Or equivalent aside, what is the proper solution to this when using Fossil? Thank you in advance for any help. Kind regards, ^K ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to migrate up a directory.
On Mon, Dec 3, 2012 at 2:39 AM, K k...@lightpowered.org wrote: I am using Xcode as my IDE at the moment, which produces a project.xcodeproj file, and a projectsrc/ dir to contain source files. My .fossil is located in the project dir alongside the project.xcodeproj file. The location of project.fossil file is not important. You can put it anywhere on disk. E.g., I store all my repositories at ~/fossils/ directory. However, I type fossil UI in the projectsrc dir, and add files from there as well, as to date I've only wanted to keep source code files in the repository. This is where your checkout (the opened repository / working files) is located. Treat it as a root directory for everything concerning this project, and forget everything that's in the parent directories. So, currently your working directory looks something like this: /AppDelegate.h /AppDelegate.m You want it to be organized like this: /project.xcodeproj /projectsrc/AppDelegate.h /projectsrc/AppDelegate.m Now it looks obvious that what you need to do is: 1) create a new directory called 'projectsrc'; 2) move current files into it; 3) move project.xcodeproj from outside working directory into it. Do the usual `fossil mv`, `mv`, `fossil add`, `fossil commit` etc. to achieve this. After you organized your working directory as required, arrange its place on the hard drive as needed. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 version 1.25 scheduled.
On Sat, Dec 1, 2012 at 4:03 AM, Richard Hipp d...@sqlite.org wrote: I wonder if it should be even more restrictive - and only deliver static content that ends in some well-known subset of suffices: *.html, *.htm, *.jpg, *.jpeg, *.gif, *,png, *.txt, *.css, *.js I think this would be too restrictive. On a related note, I think you should consider making the previous behaviour (not serving static files) the default one, and serve static files only when --static-files or similar flag is supplied. I'm worried that this change may be surprising to some people who currently may store sensitive information along with their repositories. When they upgrade to the new version, suddenly their files become exposed to the world. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] server SSL support
On 11/13/2012 03:12 PM, Remigiusz Modrzejewski wrote: On Nov 13, 2012, at 15:09 , ST wrote: why not put it inside in order not to bother with 3rd party stuff? To keep the core small? Also, safer. TLS is a bag of vulnerabilities waiting for a chance* to get out; better to keep it closed, in a separate unprivileged chrooted process. *) chances to get out are greatly improved if combined with insanity of OpenSSL API. See also http://www.daemonology.net/blog/2009-09-28-securing-https.html -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] nowrap for file browser
Hello,
I noticed when file name in repository contains -, it will sometimes
wrap into two lines in file browser. Can we add some CSS into themes to
avoid this?
Specifically, add white-space property to ul.browser:
ul.browser {
...
white-space: nowrap;
}
Here are screenshots showing before and after:
http://imgur.com/a/Ei8DO
(I can commit this change if there are no objections.)
Thanks!
--
Dmitry Chestnykh
http://www.codingrobots.com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bug report: broken links to anchors on the same page
Hi all, Links on this page into anchors on the same page are broken: http://www.fossil-scm.org/index.html/wiki?name=Cookbook e.g. a href=#HighlightDiff... becomes http://www.fossil-scm.org/index.html/wiki?#HighlightDiff instead of http://www.fossil-scm.org/index.html/wiki?name=Cookbook#HighlightDiff The problem is that Fossil sets base href=... without parameters: base href=http://www.fossil-scm.org/index.html/wiki; / This should be base href=http://www.fossil-scm.org/index.html/wiki?name=Cookbook; / to work properly. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Hmm
On 04/02/2012 09:08 PM, Konstantin Khomoutov wrote: Please do some minimal google research next time. But then we won't know how many users have the problem ;-) -- Dmitry Chestnykh http://www.codingrobots.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] Fwd: Problem with symlinks
On 03/28/2012 04:57 PM, Greg Bailey wrote: I'm still encountering this bug with fossil 1.22. Reproduction steps are in the original email below. Symbolic links are sometimes being created as plain files. Thanks, I reproduced the bug. The reason is that before there's an open checkout, allow-symlinks option is off -- it's not read from the repository or global settings. I'm working on the fix. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Fwd: Problem with symlinks
On 03/28/2012 04:57 PM, Greg Bailey wrote:
I'm still encountering this bug with fossil 1.22. Reproduction steps are
in the original email below. Symbolic links are sometimes being created
as plain files.
OK, I fixed this particular bug, but haven't committed changes to trunk
yet (the patch is at the bottom of the message), because I think the
current behavior for the *global* setting allow-symlinks is wrong.
This global setting should be considered only when creating new
repositories, and it shouldn't affect/override repository setting.
Current behavior (with the fix below):
- When creating a new repository, allow-symlinks for this repository is
unset (thus off by default).
- When opening/checking out a repository, allow-symlinks is read both
from global settings and repository settings. If it's set to on/off in
global settings, but is unset in repository settings, global wins.
Why is it so? I think it's wrong, because what the repository says about
symlinks must be what you get in the checkout, disregarding whatever is
in your global settings.
So, I propose to always set allow-symlinks to [whatever the global
setting is] for new repositories when creating them instead of leaving
it unset.
Index: src/db.c
==
--- src/db.c
+++ src/db.c
@@ -932,11 +932,11 @@
}
db_open_or_attach(zDbName, repository);
g.repositoryOpen = 1;
g.zRepositoryName = mprintf(%s, zDbName);
/* Cache allow-symlinks option, because we'll need it on every
stat call */
- g.allowSymlinks = db_get_boolean(allow-symlinks, 0);
+ g.allowSymlinks = db_get_boolean(allow-symlinks, g.allowSymlinks);
}
/*
** Flags for the db_find_and_open_repository() function.
*/
@@ -1752,10 +1752,11 @@
usage(REPOSITORY-FILENAME ?VERSION?);
}
if( !allowNested db_open_local() ){
fossil_panic(already within an open tree rooted at %s,
g.zLocalRoot);
}
+ db_open_config(0);
file_canonical_name(g.argv[2], path, 0);
db_open_repository(blob_str(path));
db_init_database(./_FOSSIL_, zLocalSchema, (char*)0);
db_delete_on_failure(./_FOSSIL_);
db_open_local();
--
Dmitry Chestnykh
http://www.codingrobots.com
___
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 reference in DuckDuckGo
Just found out that DuckDuckGo search engine have zero-click references for Fossil commands: https://duckduckgo.com/?q=fossil+commit -- Dmitry Chestnykh http://www.codingrobots.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] Names in imported git repositories
On 03/15/2012 02:38 PM, org.fossil-scm.fossil-us...@io7m.com wrote: Is it possible to tell fossil that commits should be assigned to specific user names in the resulting fossil repository? When I converted my repos, I just did a global search/replace in the file exported from git. -- Dmitry Chestnykh http;//www.codingrobots.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] Make a CGI request WITHOUT a script file
On 03/03/2012 12:04 AM, Guillermo Estrada wrote: Hi, I've been trying to implement a webservice that hosts fossil repositories. Kinda like chiselapp.com http://chiselapp.com . I have achieved running my own server app written in golang to make the CGI requests in a routed handler (i.e /user/repository ), but the problem I'm facing is that the only way I can make it work is if a cgi script exists to pass as argument to fossil. Interesting! Will it be open source? Is there any way around this? I assume your Go program launches Fossil. When you open a CGI process, can't you just write to its standard input: repository: /path/to/repo.fossil ? -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Make a CGI request WITHOUT a script file
On 03/03/2012 03:34 PM, Stephan Beal wrote: On Sat, Mar 3, 2012 at 3:30 PM, Dmitry Chestnykh dmi...@codingrobots.com mailto:dmi...@codingrobots.com wrote: I assume your Go program launches Fossil. When you open a CGI process, can't you just write to its standard input: repository: /path/to/repo.fossil That won't work: the stdin for a CGI process is the HTTP request headers and POST data. Of course! Pardon my moment of stupidity. -- Dmitry Chestnykh http;//www.codingrobots.com ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, 3 Feb 2012 09:57:47 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. Ah, I see what you mean. I thought you forgot to commit before updating. Sorry for misunderstanding. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit -- Dmitry Chestnykh http://www.codingrobots.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] Should distributed binary require libnss to connect over http?
On Mon, 30 Jan 2012 09:11:03 +0100 Lluís Batlle i Rossell wrote: On Mon, Jan 30, 2012 at 04:27:07AM +0100, Dmitry Chestnykh wrote: On Sun, 29 Jan 2012 20:49:00 +0100 Remigiusz Modrzejewski wrote: I've hit a surprising obstacle. I've tried to use Fossil, the binary from the website, on a heavily stripped down Linux system. But trying to clone end with: fl: can't resolve host name: dev.lrem.net I traced the problem to be lack of libnss_dns.so.2. Yeah, static linking is not actually that static nowadays. When linking, GCC warns about this. For what I know, it's only *glibc* that suffers from dynamic-only name resolvers (for either hosts, services, users, ...). You mean, if you replace glibc with some other libc, it will work? Sure, but then you'll have more problems if you don't control the deployment [1]. The authors of Go programming language dropped [2] a major feature -- cross-compiling between OSes -- because it was just impossible to interface with modern OS without the provided libc, despite the fact that they had already kind of working name resolver. Solaris no longer allows static linking too [3]. I think OS X too. You can, of course, build your own OS. [1] http://www.akkadia.org/drepper/no_static_linking.html [2] http://codereview.appspot.com/4437053 [3] http://blogs.oracle.com/rie/entry/static_linking_where_did_it -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Should distributed binary require libnss to connect over http?
On Sun, 29 Jan 2012 20:49:00 +0100 Remigiusz Modrzejewski wrote: I've hit a surprising obstacle. I've tried to use Fossil, the binary from the website, on a heavily stripped down Linux system. But trying to clone end with: fl: can't resolve host name: dev.lrem.net I traced the problem to be lack of libnss_dns.so.2. Yeah, static linking is not actually that static nowadays. When linking, GCC warns about this. If fossil runs in chroot/stripped system and needs to resolve hosts, you need to put the related dynamic libraries into chroot/stripped system. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] compile error
On Thu, 22 Dec 2011 18:29:51 +0100 BohwaZ wrote: Le Thu, 22 Dec 2011 15:22:50 + (UTC), urban jc...@i2pmail.org a écrit : Hi, when compiling [feed6232af], gcc 4.2.2 gives this error: bld/http_ssl.o: In function `ssl_open': /mnt/sda6/Fossil-feed6232af207151/./src/http_ssl.c:215: undefined reference to `SSL_set_tlsext_host_name' Seems that your OpenSSL lib is too old. Maybe we should put that in the source code: #if (SSLEAY_VERSION_NUMBER = 0x00908070) !defined #(OPENSSL_NO_TLSEXT) SSL_set_tlsext_host_name(handle,hostname); #endif (took from the W3M source code) But also make a compile warning if it's not available, and display a warning when trying to make a SSL connection without tlsext_host_name as this connection might fail because of this. I don't like the run-time warning idea, but for the compiler warning, is this done like this? #if (SSLEAY_VERSION_NUMBER = 0x00908070) !defined(OPENSSL_NO_TLSEXT) SSL_set_tlsext_host_name(handle,hostname); #else #warning OpenSSL version too old, compiling without SNI support. #endif Does this work with every compiler? -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 not tracking directories / dir artifacts after switching branches
On Thu, 22 Dec 2011 19:00:18 -0500 Martin Gagnon wrote: On 2011-12-22, at 15:43, Justin Gedge justin.ge...@gmail.com wrote: If it remove directories, what fossil should do if there's some untracked files in those directories, delete the whole directory with all those files in it? Just wondering. May be another case for a so multipurpose -f switch ? ;) Fossil check-ins mirror the state of working trees and vice versa, excluding extra files in the working tree that are not present in any of the check-ins. All actions in Fossil related to this mirroring (checkout, update, commit) are not destructive in these cases: * File has changes. * File is absent. * Another file with the same path, but different contents exists. (Fossil asks to overwrite such file.) Not deleting empty directories looks like a bug, because it breaks the mirroring. For example, if a subsequent check-in removes a file, when you checkout this commit (while the working tree is in the state of previous commit), the file gets removed (unless it has changes, see above). Consider this case: Check-in 1: file.txt dir1/file1.txt dir1/file2.txt dir2/another.txt Check-in 2: file.txt dir1/file1.txt The obvious way to mirror going from check-in 1 to check-in 2 in the working tree is: 1) Remove dir1/file2.txt, because it's not present in the commit. 2) Remove dir2/another.txt, == Now, it's helpful for this exercise to treat the whole path as a file instead of looking at it as a directory/file structure: 3) Do we have files named dir1/* either in the commit or as extras in the working tree? Yes, thus, not removing dir1 part. 4) Do we have files named dir2/* in the commit or as extras? a) If we have, don't remove directory. b) If we don't, we no longer have any files with such names, thus we should remove this empty directory. Another way to look into going from ci 1 to ci 2, which is easier to understand: * KILL EVERYTHING in the working tree... except extra files. * Checkout commit 2. So, my points: + Fossil should remove empty directories. + There's no need for -f option to kill extra files. For this, we have `fossil clean` command. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote: I’m in the same boat, doing two actions for every one in other SCM systems, however I do not do it dozens of times a day, so I’ve always just done it with a little gnashing of the teeth. If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. On Wed, 21 Dec 2011 12:25:19 -0500 Richard Hipp wrote: I fear to change it now, though, since it might really mess up people who are used to the older style. I think this won't cause major problems, because the files are version controlled, after all. Or we can have a flag for destructive behavior for compatibility (but habits aside, it's better to have a flag for non-destructive behavior). -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 21 Dec 2011 18:51:33 - Eric wrote: On Wed, December 21, 2011 5:41 pm, Dmitry Chestnykh wrote: If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. It is not the job of the SCM system to keep in step with my working directory, it is its job to look after what I tell it to look after. Fossil have commands to manage your working tree, like checkout/revert/undo/redo/stash/merge. They do things to files in directories. rm/mv are inconsistent with this behavior. My working directories usually contain a fair bit of transient junk that just does not need to be in the repository, but which I know I will need for a while. I can even see that I might want to keep a file no longer considered an official part of the project. It won't do anything to your junk files -- fossil mv/rm deal with working tree files, which are registered with repository. But if you want to remove a file from the repository, but keep it in the working tree for a while, there could be an option for this. I think this scenario, though, is much less used compared to just wanting to remove files from the repository and the working copy. We should optimize for the common case. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 21 Dec 2011 16:52:54 -0500 Jeremy Cowgar wrote: fossil rm should not remove a file it doesn't manage or has changes, just like other SCM systems. In this case, the file in question has changes, as it is brand new, the entire file has changed. Thus, if you were to (in the future) do: $ fossil rm #document_manager.php# File has changes, not removing from disk. Exactly. Mercurial behavior is a bit different -- it doesn't remove it because the file has been marked for adding: ~ $ mkdir hg ~ $ cd hg ~/hg $ hg init ~/hg $ touch file.txt extra.txt ~/hg $ ls extra.txt file.txt ~/hg $ hg add file.txt extra.txt ~/hg $ hg rm extra.txt not removing extra.txt: file has been marked for add (use -f to force removal) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] SSL SNI support
On Thu, 15 Dec 2011 01:43:42 +0100 BohwaZ wrote: Server:https://boh...@fossil.kd2.org/garradin/ Bytes Cards Artifacts Deltas Sent: 279 4 0 0 waiting for server...fossil: relocation error: /lib/libnss_mdns4_minimal.so.2: symbol strlen, version GLIBC_2.0 not defined in file libc.so.6 with link time reference It seems like it was a bad decision to put statically linked Fossil on /downloads.html. Linux binaries cannot be statically linked reliably -- they depend on the particular version of glibc for DNS resolution and other things. GCC even shows a warning about this: ./bld/shell.o: In function `find_home_dir': /home/dchest/src/fossil/./src/shell.c:2547: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./bld/http_socket.o: In function `socket_open': /home/dchest/src/fossil/./bld/http_socket_.c:151: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Richard, can we go back to the dynamically linked one? -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] SSL SNI support
On Thu, 15 Dec 2011 01:43:42 +0100 BohwaZ wrote:
So it appears that Fossil doesn't support SNI.
I did a small patch in src/http_ssl.c and it seems to work, but maybe
it's not the best code for that purpose as I usually don't work in C:
214a215
SSL_set_tlsext_host_name(ssl, g.urlName);
This seems correct to me. I expanded your patch a bit to show a warning
if we fail to set SNI. I also simpified setting of the connection port.
Richard, should I commit this into trunk?
Index: src/http_ssl.c
==
--- src/http_ssl.c
+++ src/http_ssl.c
@@ -193,11 +193,11 @@
*/
int ssl_open(void){
X509 *cert;
int hasSavedCertificate = 0;
int trusted = 0;
- char *connStr ;
+ char *connStr;
unsigned long e;
ssl_global_init();
/* Get certificate for current server from global config and
@@ -210,20 +210,25 @@
hasSavedCertificate = 1;
}
iBio = BIO_new_ssl_connect(sslCtx);
BIO_get_ssl(iBio, ssl);
+
+ if( !SSL_set_tlsext_host_name(ssl, g.urlName) ){
+fossil_warning(WARNING: failed to set server name indication (SNI),
+ continuing without it.\n);
+ }
+
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
if( iBio==NULL ) {
ssl_set_errmsg(SSL: cannot open SSL (%s),
ERR_reason_error_string(ERR_get_error()));
-return 1;
+return 1;
}
-
- connStr = mprintf(%s:%d, g.urlName, g.urlPort);
- BIO_set_conn_hostname(iBio, connStr);
- free(connStr);
+
+ BIO_set_conn_hostname(iBio, g.urlName);
+ BIO_set_conn_int_port(iBio, g.urlPort);
if( BIO_do_connect(iBio)=0 ){
ssl_set_errmsg(SSL: cannot connect to host %s:%d (%s),
g.urlName, g.urlPort, ERR_reason_error_string(ERR_get_error()));
ssl_close();
--
Dmitry Chestnykh
http://www.codingrobots.com
___
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] SSL SNI support
On Thu, 15 Dec 2011 07:26:27 -0500 Richard Hipp wrote: Dynamic linking means going without SSL, which many Linux systems do not have installed. Maybe focus on providing deb/rpm for Linux? Alternatively -- wild idea -- maybe we can use dlopen() at runtime to provide SSL support if OpenSSL is installed? I did the current build on a circa 2006 32-bit SuSE linux system that has never been upgraded. And I can run the resulting binary on the very latest Ubuntu install on a 64-bit I7. Presumably it also works on everything in between. So I think the incompatibility warning is overstated. OK then. I thought this was the reason for the reported error. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 version 1.21
On Tue, 13 Dec 2011 09:29:14 -0500 Richard Hipp wrote: Fossil version 1.21 has been packaged and put on the website for convenient download. See http://www.fossil-scm.org/download.html for details including a summary of changes since the previous release. On this page, the link See the Change Log for additional details leads to the previous version of changes.wiki. The correct one is: http://www.fossil-scm.org/fossil/doc/489c67ae46/www/changes.wiki -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Slight difficulty with symlinks
On Sat, 26 Nov 2011 13:16:27 + Ben Summers wrote: allow-symlinks is not a versionable setting. Is there a reason why it shouldn't be? It sounds like it should be as it affects the checked out files. It should be, yes. The reason is that it's currently non-versionable is that I started implementing it before there were versionable settings. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Using althttpd.c
Hello, On Thu, 10 Nov 2011 22:57:37 +0100 Paolo Bolzoni ezzet...@hotmail.com wrote: I thought if could be a problem with the root jail but even if I copy sh in the default.website directory and change the interpreter to #!/sh nothing changes. Are you sure that 'sh' doesn't depend on anything else and is statically linked? Try with statically linked fossil: ./configure --static make -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 list commits made so far?
On Mon, 07 Nov 2011 15:42:35 -0800 Ross Berteig r...@cheshireeng.com wrote: At 02:32 PM 11/7/2011, Gilles wrote: I guess it would make more sense that -n stands for number of check-in's, but it's not returning that number. I updated from 1.19 to 1.20, and re-ran the command on my repo: -n 5 still doesn't return the last five check-in's. Maybe this is not what the -n switch mean. Without examining the code, I've tried a couple of experiments in a repo of my own. It appears that the -n N option specifies a desired number of lines to output, but tests it only between complete timeline entries. Also, the lines containing only a date are not counted against N. Here's a bug report from last November, with a patch: http://www.fossil-scm.org/index.html/tktview?name=3e58b8ceaf -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 virtual filesystems
On Tue, 1 Nov 2011 13:10:31 + Eduardo Tongson propol...@gmail.com wrote: Apparently Fossil chokes on symlinks to /proc or /sys, the commit went fine after I removed the symlink to /proc/self/mounts (/etc/mtab). In the latest version (1.20) you can also turn on allow-symlinks setting for your repository and Fossil will not follow symlinks, instead adding them into the repository as-is. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 Repository Does Not Exist Error
On Fri, 28 Oct 2011 18:49:56 +0800 David Baxendale (GMail - Singapore) david.baxend...@gmail.com wrote: I have recently moved all my files to a new machine and the directory structure is slightly different under Windows 7. Now when I execute a fossil status command, fossil reports the repository does not exist or is in an unreadable directory, followed by the old directory name. How do I fix this? Make sure you don't have uncommited changes. fossil close fossil open new/path/to/your/repository -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 Repository Does Not Exist Error
On Fri, 28 Oct 2011 13:31:47 +0200 Stephan Beal sgb...@googlemail.com wrote: Or if you DO have uncommitted changes you can also try: rm _FOSSIL_ Dangerous if you have stashed changes ;-) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Running a command in any sub-dir?
On Thu, 27 Oct 2011 12:24:26 +0200 Gilles gilles.gana...@free.fr wrote: Is there a way to run a command in any sub-directory below the repository, so that I don't have to cd to the right sub-directory before running a command? First of all, there's a distinction between a repository (and SQLite database file) and a working copy (a collection of your files). The repository can be located anywhere. When you open it by running `fossil open /path/to/repository`, you create a working copy in the current directory. I organize my projects the following way (~ is my home folder): * ~/fossils/pub/ (repositories for my public projects): iwl.fossil kitchen-timer.fossil ... * ~/fossils/priv/ (repositories for my private projects): configs.fossil ... I have a separate single directory for working copies: * ~/proj/ iwl/ kitchen-timer/ configs/ To create a new project I do: fossil new ~/fossils/pub/example.fossil mkdir ~/proj/example cd ~/proj/example fossil open ~/fossils/pub/example.fossil Now I'm inside a fresh working copy. Fossil here creates a special file _FOSSIL_, so that it knows that files in this directory and in subdirectories under it can be tracked. Now, while inside this working copy, I can add some files: echo Hello world file1.txt fossil add file1.txt and I can add subdirectories with files: mkdir sub echo Second file sub/file2.txt fossil add sub/file2.txt I can also 'cd' into that directory to add files: cd sub echo Third file file3.txt fossil add file3.txt Fossil allows me to do this, because it walks up the hierarchy from the current directory to find that _FOSSIL_ file: Have ~/proj/example/sub/_FOSSIL_? No. Go up. Have ~/proj/example/_FOSSIL_? Yes. That's the root of the working working copy. There it finds that I'm adding files/committing to ~/fossil/pub/example.fossil repository. Suppose I 'cd' into my home directory (/home/dchest/). Now when you run fossil add ~/proj/example/sub/file3.txt It walks up from the current directory: Have /home/dchest/_FOSSIL_? No. Have /home/_FOSSIL_? No. Have /_FOSSIL_? No. No more levels, error. Fossil expects your current directory to be inside the root of the working copy, i.e. the working copy directory itself or any other directory under it in the hierarchy. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Running a command in any sub-dir?
On Thu, 27 Oct 2011 13:54:37 +0200 Gilles gilles.gana...@free.fr wrote: Yes, but I find it odd that Fossil expects the current directory to match the path in the repository: After all, when running commands that deal with the files in the repository, it shouldn't matter where we are in the file system when typing the command. When you're inside the working copy, treat this as if you're dealing with the mirror of what's inside the repository, that is, as if you're browsing the repository tree. ls is not consistent because it just lists all files in the current checkout from the working copy root directory, which is helpful for scripts. All other commands show paths relative to the current directory: C:\Projects\Project2\ fossil changes EDITED ../Project1/Form1.vb As for why it works this way -- this is just convenient and familiar. If Fossil worked with absolute paths instead of relative ones, it would be inconvenient to work with. Consider a case where you have the following path: project/subdir1/subdir2/subdir3/file.txt If Fossil didn't accept relative paths, you'd have to type this whole directory structure any time you work with files inside 'subdir3' instead of just 'cd' into it and using file names without path. Also don't forget about shell glob expansions. If I have 10 .txt files inside the directory: dir\ - subdir\ - file1.txt - file2.txt ... And I 'cd' into 'dir/subdir', I can do: fossil diff *.txt And get the diffs for all these 10 files. I couldn't do this if I had to specify: fossil diff dir/subdir/*.txt when I'm inside 'dir/subdir', because shell works with relative paths, and will not expand this glob to the proper files. -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 is Awesome
On Wed, Oct 26, 2011 at 3:51 AM, Caleb Gray ca...@calebgray.com wrote: 2) Add (or replace zlib with) LZMA. Some of my repositories are very large; the compression difference between the DEFLATE algorithm and the LZMA algorithm is not negligible, and can even be substantial. Recently, even the Linux kernel has officially begun using lzmalib to compress their releases: http://www.kernel.org/pub/linux/kernel/v3.0/ (even the difference between BZ2 and XZ is about 13M, or 31M smaller than GZ). A quick implementation of LZMA (by editing auto.def and blob.c's blob_compress, blob_compress2, and blob_uncompress) resulted in the following repository sizes for the latest trunk of SQLite: sqlite-zlib.fossil (4.8M) (~5.0K per file) sqlite-lzma.fossil (3.5M) (~3.6K per file) How's that for bandwidth efficient enough for dial-up? LZMA is good for release tarballs, but has unacceptable speed and memory requirements for version control systems. Note that due to self-checks, Fossil compresses and then extracts and verifies content before committing it: http://www.fossil-scm.org/index.html/doc/trunk/www/selfcheck.wiki I'd say DEFLATE is a good compromise between LZO/SNAPPY and LZMA for our use. -- Dmitry Chestnykh ___ 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 is Awesome
On Wed, Oct 26, 2011 at 3:51 AM, Caleb Gray ca...@calebgray.com wrote: 1) Compress the releases found on http://www.fossil-scm.org/download.html using UPX ( http://upx.sourceforge.net/). UPX is technology from the good ol' days, when people had tiny floppies and hard drives. There's no reason to use it nowadays. It slows down execution, takes more memory, may introduce vulnerabilities, etc. Just read about all the disadvantages of UPX here http://linux.die.net/man/1/upx. Note that Fossil in CGI mode is executed for each request, so with UPX it would have to decompress itself on each request. The first time you run it, it may be faster (due to smaller disk reads compared to uncompressed version), but for each subsequent request, once Fossil is in RAM, it would be slower and require more CPU. -- Dmitry Chestnykh ___ 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 is Awesome
2011/10/26 Lluís Batlle i Rossell virik...@gmail.com: Forking and executing is not the same thing. I don't know in Windows, but in unix, a fork of a upx program should be the same as a non-upx program. Fork (on *nix) applies to fossil server. Fossil's CGI is, obviously, run by webserver with fork/exec. Also, Windows doesn't have fork. -- Dmitry Chestnykh ___ 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 is Awesome
On Wed, 26 Oct 2011 16:15:11 -0700 Caleb Gray ca...@calebgray.com wrote: @Dmitry Chestnykh: I just wrote a script for testing the speed and size difference between the different compressions available, find the results here: http://uploads.calebgray.com/contributions/compression/index.html Thanks! I grepped a bit, and found out that Fossil uses 9 level for deflate, which seem to me _not_ a good balance; and LZMA 1 level outperforms it in both compression ratio and speed. Plus I've heard that xz is for some reason slower than 7zip: http://ck-hack.blogspot.com/2011/04/quick-lrzip-comparison.html BTW, how LZMA performs for tiny files? I ask because most blobs in Fossil in normal operation (source code) are tiny due to delta compression. As far as I know, memory usage depends entirely on dictionary size... so shouldn't DEFLATE and LZMA use the same amount of memory if configured correctly? Not sure, but I thought a good part of why LZMA is so good is that it has a large dictionary size. Though, maybe low compression levels don't require a lot of memory. I'm used to 500KiB/s download speed, but my only choice at home is Clearwire (which is true, I'm sure, for more than just myself). Unfortunately, it's not rare for me to get 20KiB/s download speeds on it, if the Fossil releases were UPX compressed, that would have saved me ~5 seconds over the ZIP. Obviously, this isn't doesn't seem like a big deal, but keep in mind that the people in Australia/New Zealand have to pay for their bandwidth. It's not just time we're saving people, it's money too, in the long run. Sure, I understand. When I lived in Russia, the first Ethernet connection I got was pretty expensive: $0.15 per megabyte or so (with average income in Moscow ~$500 at that time). Today a lot of places in the world have expensive mobile internet. Still, 500 KB difference in a world of torrents, 500 MB text editors, and 2 GB software updates? Come on! :-) UPX has zero effect on memory usage, and would probably add a millisecond or two to each request, leaving CPU as the only truly impacted factor... I suppose that if a Pentium 133 uncompressed at ~10MB/s as they claim on their homepage... then if you're getting 10 requests a second on a 1MB executable... your server would begin seeing the performance impact of Fossil being compressed using UPX. Anyway, I'm not a huge proponent to the idea, it was just a thought. UPX works by allocating a buffer of original executable size, then uncompressing the file to it, and executing this buffer. The statically compiled fossil running on my server (amd64) is ~5 MB. This means that on each request, if I packed it with UPX, I'd get 5 MB allocation -- not good for my little VPS :-) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] SSL: cannot connect to host www.fossil-scm.org:443
On Mon, 24 Oct 2011 19:39:56 +0200 Jiří Navrátil j...@navratil.cz wrote: I got today instead of one question two questions on my OpenBSD box. Not sure, what was is the difference from last time. Now I don't need anymore to accept new certificate again. old question: Accept certificate [a=always/y/N]? a new questions: Accept certificate for host www.fossil-scm.org [a=always/y/N]? a Save this certificate as fully trusted [a=always/N]? a That's quite a usability mess. What answering always to the first question now means? Why you have to answer always to the second question instead of yes? The original intention with the acceptance question was: Accept certificate [a=always/y/N]? * always = as in, always, that is, save certificate and don't complain about it anymore. * y = yes, accept certificate for this sync session. * n = no, reject certificate and quit sync session. I remember there was a bug in handling yes answer -- that is, Fossil would ask this question a few times during sync. Was this two question thing intended to fix this? Thanks! -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] feature list?
On Sat, 22 Oct 2011 01:55:31 +0200 Jan Danielsson jan.m.daniels...@gmail.com wrote: A while back, drh posted a list of features which he couldn't implement due to time constraints, but I am unable to find that particular mail. Anyone have a link to the mail in the archives, or is that list available through the fossil wiki? Here it is: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05846.html -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Wed, 19 Oct 2011 14:50:26 +0200 Stephan Beal sgb...@googlemail.com wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. Just for fun: a lock sitting in FVWM CVS repository since 2008: http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15603.html -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Veracity
On Wed, 19 Oct 2011 14:56:47 +0200 Stephan Beal sgb...@googlemail.com wrote: So the master plan is to create an SCM for the sole purpose of selling books about the SCM (whose sole purpose is to sell a book about...)? Actually, Eric gave away this book ;-) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] more on side-by-side diffs
On Sun, 16 Oct 2011 19:10:58 +0200 Stephan Beal sgb...@googlemail.com wrote: On Sun, Oct 16, 2011 at 6:27 PM, Jan Danielsson jan.m.daniels...@gmail.comwrote: I'm still searching for better terminology than 1-pane and 2-pane diffs. Any opinions? Condensed vs Expanded? Terse vs Verbose? i like side-by-side, but i don't have a suggestion for 1-pane diffs. Maybe tall and wide diffs? Side-by-side diffs and Unified diffs? -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] Login seems to be broken. (Showstopping)
Using a recent version of fossil (Fossil version 1.19 [6092935ff2] 2011-10-05 02:03:04) I can't log in to any repository at all (including repos I've had up for over a year without a problem) except on the local machine. I've attached an example of this behaviour as an empty repository. There are two users on this repo: michael and nii. The former is Super-user and the latter is Developer. Both have the password 12345. I can only log in as michael when run locally (and, indeed, hitting Logout leads me to an Unable to connect message). When running remotely I can access the Login page, but can't actually log in. It *says* I've been logged in, but going anywhere other than the login window says I'm not logged in. There were some changes to login code lately: [d4a341b49d] Merge protection against timing attacks into trunk. But I can't reproduce your problem. Maybe try 'make clean' before rebuilding the code? If this won't work, try the version before this merge: [3fac77d7b0] and let us know the results. Thanks! -- Dmitry Chestnykh ___ 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] ui side-by-side diffs
On Oct 10, 2011, at 1:01 , Jan Danielsson wrote: Feedback/ideas/protests are welcome from anyone who has any preferences with regards to design/layout. I've only used cvsweb, so it'll be my primary source of inspiration. For those with wider experience of such tools, let me know if there are others I should be looking at. Here are some features that I like, which can be added later once we have a basic implementation: I like how Google Code highlights changes inside diffs: http://code.google.com/p/spiped/source/diff?spec=svn18r=17format=sidepath=/trunk/main.cold_path=/trunk/main.cold=2 Also, Google's Code Review tool collapses lots of unchanged lines: http://codereview.appspot.com/5218041/diff/26002/src/pkg/html/parse_test.go -- Dmitry Chestnykh ___ 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] Gdiff after commited files?
On Oct 10, 2011, at 17:38 , Gilles wrote: Is there a simple way to tell Fossil to call the gdiff application with the last and before-last revisions of the file by default? fossil gdiff --from previous myfile.txt -- Dmitry Chestnykh ___ 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: out of memory
On Oct 6, 2011, at 10:36 , Stephan Beal wrote: mmap() is only used by the sqlite3 code, not fossil. OS X uses mmap underneath when you do malloc for the large region. -- Dmitry Chestnykh ___ 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] SSL: cannot connect to host www.fossil-scm.org:443
Do we need to do something to the Fossil SSL implementation so that it can accept a UCC? I don't think so. On my Ubuntu VM Fossil doesn't complain about certificate, just clones without any questions. It should be the same on Mac OS X 10.4-10.6. (On 10.7 OpenSSL no longer have root certificates, so it requires dumping certificates and setting 'ssl-ca-location' to the correct path in order to silence questions.) -- Dmitry Chestnykh ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
On Oct 6, 2011, at 16:59 , Jacek Cała wrote: I've just realized that despite fossil is an executable it does not prevent if from exporting functions for other programs to use (at least on Windows, am not sure if this is possible on *nix). It doesn't matter how the program is linked. Fossil calls exit() when a function needs to fail, and it leaves it up to the OS to clean up allocated memory. -- Dmitry Chestnykh ___ 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 should know to open up perms on a file prior to update if no write access.
On Oct 6, 2011, at 19:03 , Matt Welland wrote: fossil: SQLITE_ERROR: near redoflag: syntax error fossil: near redoflag: syntax error UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT redoflag WHERE pathname='foo.txt' Is this from later trunk version? I fixed this error a few weeks before. -- Dmitry Chestnykh ___ 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 should know to open up perms on a file prior to update if no write access.
On Oct 6, 2011, at 19:49 , Matt Welland wrote: Hmmm I have 1.19 but still see the problem since I built from source before it was released? It might be a little clearer to ensure the 1.19 is only in the files from the checkin prior to the release. chlr11723 fossil version This is fossil version 1.19 [24c16584cc] 2011-08-26 14:59:43 UTC The released version (from Downloads page) is: This is fossil version 1.19 [6517b5c857] 2011-09-01 18:25:19 UTC BTW: I edited the binary (just replaced the space with a comma) and as expected it works fine: Nice patch! :-) If you use symlinks, though, there are a few more fixes for them, so you may want to recompile from trunk. If not, I think this version is fine. -- Dmitry Chestnykh ___ 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 should know to open up perms on a file prior to update if no write access.
A developer accidentally (and naively) checked in a file with no write permissions. On changing the file and checking it in others could not do an update and would get something like this: fossil update UPDATE foo.txt fossil: unable to open file /tmp/mrwellan/testing/test/foo.txt for writing Rolling back prior filesystem changes... UNDO foo.txt fossil: SQLITE_ERROR: near redoflag: syntax error fossil: near redoflag: syntax error UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT redoflag WHERE pathname='foo.txt' Fossil doesn't track permissions apart from executable bit (and symlink bit in trunk), so I'm not sure how it's even possible to get a file from the repo without write permissions: The optional 3rd argument defines any special access permissions associated with the file. The only special code currently defined is x which means that the file is executable. All files are always readable and writable. This can be expressed by w permission if desired but is optional. http://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki -- Dmitry Chestnykh ___ 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] [vb.net] Which files/folders can be safely ignored?
On Oct 4, 2011, at 13:03 , Gilles wrote: So, nobody knows why fossil includes files in a folder even though I use the --ignore option? Does it ignore files if you set ignore-glob by launching 'fossil ui' and then going to Admin Settings? -- Dmitry Chestnykh ___ 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] [vb.net] Which files/folders can be safely ignored?
On Oct 4, 2011, at 13:53 , Gilles wrote: ignore-glob=*.o,*.obj,*.exe,bin/*,obj/*,My Project/* What about */bin/*,*/obj/* ? -- Dmitry Chestnykh ___ 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] [vb.net] Which files/folders can be safely ignored?
On Oct 4, 2011, at 14:20 , Gilles wrote: On Tue, 4 Oct 2011 14:08:49 +0200, Dmitry Chestnykh dmi...@codingrobots.com wrote: What about */bin/*,*/obj/* ? That did it :-) Great! From your logs I noticed that bin was a subdirectory of another directory inside the project root, so just bin/* won't do. I don't know if it's OK for VB.Net projects to exclude My Project. Likewise, I don't know if the .sln and .user files can be safely excluded. I don't know a lot about Visual Studio, but*.sln looks to me like a solution file, don't ignore it. According to the git ignore template here https://github.com/github/gitignore/blob/master/VB.Net.gitignore, *.user and *.suo are safe to ignore. -- Dmitry Chestnykh ___ 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] Listing artifact IDs for shunning?
On Oct 4, 2011, at 23:24 , Steve Havelka wrote: This reply should be shunned from the mailing list. Agreed. Given that we all make mistakes from time to time, like checking passwords into a repo or checking in huge files, and given that there's at least one hacky, clumsy workaround for deleting stuff (export to git, modify, import from git), and given that these sorts of requests (to delete files, branches, etc) do recur, maybe the philosophy of never delete anything still needs further amendment? Oh, sorry, I'm not talking about Fossil's philosophy (I'm okay with not deleting stuff), I'm talking about about the tone of the message (nor do you understand the principles of software engineering). -- Dmitry Chestnykh ___ 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] Forms are cleared in firefox, switch pages
sometimes I'm filling a ticket, and I click to some link by error, and then I use back/forward to go to the ticket form page again. And the form is blank. Firefox uses to store the form contents along page back/forward, but it fails to do so for fossil. Can this be 'fixed'? Anyone aware of these web things understanding the problem? Firefox bug? I just tried, and Firefox preserves the content when you close the tab and then go to History Recently Closed Tabs and reopen it (presumably, it uses a different method for saving the state). However, as you said, this doesn't work when you click any link on the page or manually enter a new address. Chrome preserves the form correctly. -- Dmitry Chestnykh ___ 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] Forms are cleared in firefox, switch pages
On Oct 3, 2011, at 17:20 , Lluís Batlle i Rossell wrote: I think that's exactly what I want. Anyone against? I'm for it, but here's the ticket referring to no-store that mentions some problems with Opera: http://www.fossil-scm.org/index.html/info/b465b3bc2ceef4446b2ae770242ed0968e4dbc68 -- Dmitry Chestnykh ___ 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] [vb.net] Which files/folders can be safely ignored?
On Oct 4, 2011, at 2:08 , Ross Berteig wrote: I wonder if we should start a collection of pages at the fossil-scm.org wiki that document the collective wisdom of this group for IDEs we've encountered. Here's a useful resource: https://github.com/github/gitignore -- Dmitry Chestnykh ___ 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] Protection against timing attacks
On Oct 1, 2011, at 9:24 , Ron Wilson wrote: On Fri, Sep 30, 2011 at 2:27 PM, Dmitry Chestnykh dmi...@codingrobots.com wrote: The attacker cannot supply hash, he supplies password. To do timing attack, the attacker have to find a such string, for which the hash has a few bytes changed. You and I seem to be talking about different use cases, There are scenarios where both the client and server generate hashes. The client sends its has to the server and the server compares the hashes. This is correct, yes. -- Dmitry Chestnykh ___ 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] Protection against timing attacks
2011/9/29 Lluís Batlle i Rossell virik...@gmail.com
Well, if someone has studied those attacks, and the code by dmitry looks fine
and works based on some heavier studies than our first thoughts on that, let's
use it. No?
i can't object, i just think it's paranoid :).
Well, it is paranoid, yes :-) I'm overly paranoid about everything concerning
security. Evidence: it was unnecessary to do constant-time comparison of hashes
in xfer.c.
I'm mostly concerted about cookies, as it's impossible to time non-plain-text
passwords -- the attacker simply cannot supply passwords which, when hashed,
have a few bytes of hash modified (that is, when you supply password, the
server looks for 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 in the database,
it's impossible [at least now, with SHA-1] to supply such password which hash
has, say, 5baa61 in the beginning, but a different ending).
However, due to the use of plain-text passwords in the old versions and
compatibility with them, it is currently possible to supply password hash (if
you know project-id) instead of the password:
uid = db_int(0,
SELECT uid FROM user
WHERE login=%Q
AND length(cap)0 AND length(pw)0
AND login NOT IN ('anonymous','nobody','developer','reader')
AND (pw=%Q OR pw=%Q),
zUsername, zPasswd, zSha1Pw
);
Once we get rid of plain-text passwords, we no longer need constant-time
comparison functions in password-handling code. That leaves cookies, which are
just a 25-byte random blob + project-code + login, and Fossil searches for that
blob in database.
--
Dmitry Chestnykh
___
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] same user, multiple logins: the problem and a potential solution
Advantages are that no state is stored in the database and multiple logins are possible, with simpler code.[2] You can invalidate all logins by changing the secret key, but can't invalidate individual sessions. But that would mean a logout on one client would log out all others, doesn't it? Ignore that question, please. i didn't grasp the important words no state is stored... It's also possible to implement the variation of stateless HMAC scheme + current stateful cookie value in database scheme to allow log out all sessions functionality, like in Gmail. 1. Store some random bytes in database per user. This string will be a secret_key for HMAC. 2. Sign cookie values with HMAC(secret_key, value), where value is (login || ip || expiration_time). 3. To logout one session, clear this cookie. 4. To logout all sessions, go to step 1 (replace secret_key in database with a new randomly generated one, thus invalidating all cookies). Note: it's better to use double-HMAC as implemented in my authcookie package for Go language: https://github.com/dchest/authcookie [according to this paper: http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf] -- Dmitry Chestnykh ___ 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] same user, multiple logins: the problem and a potential solution
On Sep 30, 2011, at 16:15 , Stephan Beal wrote: On Fri, Sep 30, 2011 at 4:02 PM, Dmitry Chestnykh dmi...@codingrobots.com wrote: I have attached a patch to sha.c with HMAC implementation, and double-signing. :-D Basically, if zKey is a random secret string stored in the database, and zRest is a concatenation of the values you want to store in the cookie (e.g. login/ip-address/project-code): So zKey is the per-user secret or repo secret? If i understand correctly, this change just replaces the repo secret with user secret. Is that correct? If you want Log out all my sessions button in addition to Log out this session, then it's a per-user secret. If it's per-repository secret, then log out all my sessions is not possible. That's speaking of registered users. For anonymous users, the current code is basically what I'm proposing, but instead of HMAC it uses plain SHA1 of concatenation of per-repository secret (captcha-secret) and /TIME/IPADDR (HMAC is better, but the current code is OK too). Will this be part of the timing-based change which Richard asked be put in the trunk? If so, i'll wait until it's in there. No. Maybe we should create a new branch for overhaul of cookie code to allow multiple sessions? -- Dmitry Chestnykh ___ 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] Protection against timing attacks
I think this is a good patch and that it should be merged into trunk. Is it too early to get rid of plain-text password support? I think hashed passwords appeared about 1.5 years ago. If we remove it, we can leave pw=%Q, I think. The only code left susceptible to timing attacks will be for cookie handling. -- Dmitry Chestnykh ___ 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] same user, multiple logins: the problem and a potential solution
On Sep 30, 2011, at 17:58 , Stephan Beal wrote: Multiple login sessions will require that some fields be migrated out of the user table and into a new table. The anon user does not store the cookie data in the user table (because it would log out all other anonymous users), using only the cookie for validation. I'm thinking about reusing the current cookie column for the per-user secret key. But this will require careful handling of migrations to avoid introducing security bugs. Not sure what's better. -- Dmitry Chestnykh ___ 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] Protection against timing attacks
Actually, you can do this with a hash. When it comes to comapring 2 hashes, they are still strings of charcters. If anything, the timing attack would save even more time since, for purposes of camparing 2 strings, the hash is just a much longer password. The question then is, is the hash long enough to make the timing attack impractical? The attacker cannot supply hash, he supplies password. To do timing attack, the attacker have to find a such string, for which the hash has a few bytes changed. For example, say, our password is bird, and we store sha1(bird) in the database: 9cba2b7ebbf67f6e455af28f8445796e20ca288f. When a user supplies password, we hash it and compare with the stored hash. Let's image that the attacker supplies password ocelot. Server does sha1(ocelot) = 1d735415a0c1e05302657bb6d916f3bcd7a80385 and compares it with the stored value: 9cba2b7ebbf67f6e455af28f8445796e20ca288f != 1d735415a0c1e05302657bb6d916f3bcd7a80385 This comparison is not constant-time, so the attacker notices that the first byte is incorrect, and continues guesing by providing the next password: lion. sha1(lion) = 972b2f351f9b17a5f49a14a90fcd8a72b0eaecb4 9cba2b7ebbf67f6e455af28f8445796e20ca288f != 972b2f351f9b17a5f49a14a90fcd8a72b0eaecb4 But now it took server a bit longer to calculate the result (9=9, c != 7). The attacker notices the short response time, so he's confident he guessed that the first byte is 9. Now, to continue attack he needs to find such password, for which the hash starts with 9… And this is where it's practically impossible to continue. (Actually, one hash byte is the two hex numbers, but anyway). This is for logins. But cookies currently compare hashes, not hash and a string hashed on the server, so they are timeable. -- Dmitry Chestnykh ___ 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] is a rebuild in http mode possible?
On Sep 29, 2011, at 1:40 AM, Richard Hipp wrote: In the past there have been issues with output that rebuild sometimes generates. I haven't pressed that button lately, so I don't know if those issues are currently fixed or not. As of [2cd21f8dc2] (trunk: [ce354d0a9f]) there shouldn't be any output of rebuild progress in CGI mode. -- 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] Square brackets in filenames
What's the rationale for disallowing [ and ] in filenames? Are there any systems that don't like them (maybe FAT)? Or maybe this is due to collision with [wiki/ci links]? From file_is_simple_pathname(const char *z): ** * Does not contain any of these characters in the path: \*[]? Brackets are not mentioned here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx and here http://en.wikipedia.org/wiki/Comparison_of_file_systems however NTFS doesn't allow: : | ? * / \ -- Dmitry Chestnykh ___ 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] Scalability, a single file commit and lots of disk reads
To open the repository to a new checkout it took Fossil about 26 minutes. Roughly 13 minutes extracting the files into the directory, and then 13 minutes of ... doing something, before it came back. The equivalent command in Mercurial (hg update null to reset the checkout then the timed hg update) took 19.5 minutes No low-hanging fruits here. After profiling fossil open, I noticed nothing extraordinary -- most time is spent in compression, decompression, and calculating checksums. http://i.imgur.com/1odR8.png After checkout (13 minutes of ... doing something, before it came back), Fossil goes through all the extracted files, computes MD5 checksum and verifies that it matches the one in the manifest. As Stephan pointed out, you can disable this by turning off repo-cksum setting. Same thing with committing: Fossil checks that content is repo is correct, see http://www.fossil-scm.org/index.html/doc/trunk/www/selfcheck.wiki : Then just before transaction commit, fossil re-extracts the original content of all files that were written, computes the SHA1 checksum again, and verifies that the checksums match. If anything does not match up, an error message is printed and the transaction rolls back. -- 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] Protection against timing attacks
Dear archeologists,
Please review changes in the following branch:
http://www.fossil-scm.org/index.html/timeline?r=dmitry-security
The more eyes the better, as it touches login code.
I try to protect against timing attacks on login, cookies, and sync by using
the constant-time comparison function.
What do these attacks do? Basically, they try to guess passwords/cookies by
measuring how long it took the server to respond to the wrong result. For
example, we have the following password stored in the database (let's forget
about hashes for now):
PASSWORD
The attacker begins guessing by sending the following value:
A
The server compares it with the stored password:
if COMPARE(A, PASSWORD) == TRUE then
success
else
failure
When this COMPARE function is implemented like memcpy/strcpy, that is, compares
values byte-by-byte, but when sees the first wrong result ('A' != 'P'), it
immediately returns FALSE, it turns out, it is possible to time the result of
such comparisons to make better guesses.
For example,
COMPARE(A, PASSWORD) returns FALSE in 0.1 msec, but
COMPARE(P, PASSWORD) returns FALSE in 0.3 msec, because it did two
comparisons:
'P' == 'P'
'A' == 'A'
'A' != 'S'
Now the attacker knows that the first two bytes are correct.
To prevent such attacks, one should use a constant-time comparison function,
which always compares _each_ byte, and returns result only after all bytes have
been compared.
More information:
http://codahale.com/a-lesson-in-timing-attacks/
http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/
Examples of constant-time comparison functions written by crypto experts
(basically, they are the same):
http://golang.org/src/pkg/crypto/subtle/constant_time.go?s=503:544#L2
http://code.google.com/p/spiped/source/browse/trunk/lib/crypto/crypto_verify_bytes.c
https://github.com/jeremywohl/nacl/blob/master/crypto_verify/32/ref/verify.c
Oh, and there's no need to panic, this is a difficult and (yet) unusual attack
;-)
--
Dmitry Chestnykh
___
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] Protection against timing attacks
On Sep 29, 2011, at 20:15 , Stephan Beal wrote: Given the relatively high overhead fossil has when it opens a db or runs a query, and network latency, i cannot imagine that someone could accurately time the difference of a memcmp() operation on 8 or 10 bytes. The number of factors involved before and after COMPARE is called are just too great. As was written in the post about sha1 collisions someone linked to earlier: the chances are higher that all of the members of your dev team will be killed by wolves in separate incidences on the same night. I posted a link about this concern: http://rdist.root.org/2010/01/07/timing-independent-array-comparison/ The other misconception is that jitter is too great to get anything useful out of the measurements, especially in a network. There is an excellent paper by Crosby and Wallach* that debunks this myth by carefully analyzing noise and its causes as well as how to filter it. They conclude that an attacker can reliably detect processing differences as low as 200 nanoseconds on a LAN or 30 microseconds on a WAN given only 1000 measurements. If your server is hosted somewhere an attacker can also buy rackspace, then you are vulnerable to LAN timing attacks. *) http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf -- Dmitry Chestnykh ___ 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] Protection against timing attacks
So why not simply add the following logic to server mode: A) fetch config option add-random-sleep (integer, default=0) B) if ((A)0) AND user is nobody, sleep for random 1..(A) ms. (This attack would seem to be useless for anyone but the nobody user. If you're logged in, you've got your password, and anonymous gets a random password). Point 2 on that linked article :-) Random numbers have some distribution, most commonly, uniform. Given enough measurements, you can get rid of randomness. -- Dmitry Chestnykh ___ 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] Hashes from fossil
The zlib compressor adds a timestamp at the beginning. If you gunzip the
tarballs, you'll find that they are identical.
If I read gzip specs correctly, it allows zero timestamp:
MTIME (Modification TIME)
This gives the most recent modification time of the original file being
compressed. The time is in Unix format, i.e., seconds since 00:00:00 GMT,
Jan. 1, 1970. (Note that this may cause problems for MS-DOS and other systems
that use local rather than Universal time.) If the compressed data did not
come from a file, MTIME is set to the time at which compression started.
MTIME = 0 means no time stamp is available.
(http://www.gzip.org/zlib/rfc-gzip.html#header-trailer)
I tried to gunzip such file, and it correctly set today's time, not 1970, for
the unzipped file, when the field is 0.
SHA-1 sums for .tar.gz downloaded at different times then matched.
So maybe:
Index: src/gzip.c
===
--- src/gzip.c
+++ src/gzip.c
@@ -49,19 +49,17 @@
/*
** Begin constructing a gzip file.
*/
void gzip_begin(void){
char aHdr[10];
- sqlite3_int64 now;
assert( gzip.eState==0 );
blob_zero(gzip.out);
aHdr[0] = 0x1f;
aHdr[1] = 0x8b;
aHdr[2] = 8;
aHdr[3] = 0;
- now = db_int64(0, SELECT (julianday('now') - 2440587.5)*86400.0);
- put32(aHdr[4], now0x);
+ put32(aHdr[4], 0);
aHdr[8] = 2;
aHdr[9] = 255;
blob_append(gzip.out, aHdr, 10);
gzip.iCRC = 0;
gzip.eState = 1;
--
Dmitry Chestnykh
___
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] Hashes from fossil
I already checked in a change that sets the timestamp based on the check-in time. But I like your patch better (since it is simpler). Hehe, I started writing something similar, but was scared away by many changes required to do this, and was not sure if I the manifest time was the correct time that I needed (it is), so decided to go lazy and read gzip spec instead :-) Anyway, your change is better in case the are ungzip implementations that do not handle 0 time correctly, plus we get a nice proper timestamp when gunzipping. -- Dmitry Chestnykh ___ 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
On Sep 26, 2011, at 12:34 PM, Emil Totev wrote: fossil add * D:\utils\programs\fossil.exe: file not found D:/TEMP/proj/* Windows cmd doesn't expand * to the list of files. If you want to add all files in the directory, try this: fossil add . -- Dmitry Chestnykh ___ 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
Hm, I just tried it on my Windows XP virtual machine in cmd.exe, and it works for me: C:\Dev\t2fossil add * C:\Utils\fossil.exe: cannot add _FOSSIL_ ADDED sub/text1.txt ADDED sub2/text2.txt ADDED test.txt ADDED test2.txt I haven't found code for glob expansion in Fossil in add command, and cmd.exe definitely doesn't expand it: echo * * So what am I seeing here? :-) -- Dmitry Chestnykh ___ 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
On Sep 26, 2011, at 1:13 PM, Dmitry Chestnykh wrote: So what am I seeing here? :-) Aha, it seems like main() for binaries build with MinGW actually receive expanded arguments in argv. Are Windows binaries available from the download page build with Visual Studio? -- Dmitry Chestnykh ___ 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
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
Re: [fossil-users] Wildcards not working on windows
Yes, this one works as expected. Great! So it is a build issue? MinGW tries hard to make programs behave like they do on Unix. It seems like binaries compiled with it do shell-like expansion on arguments, before passing them to main() function. Thus, there's no need to write your own wildcard expansion code for Windows when porting Unix code. Visual Studio compiler doesn't do such thing, so wildcards are not expanded for binaries built on VS. Richard seem to have released 1.19 binary for Windows compiled with Visual Studio, while 1.18 has been compiled with MinGW. -- Dmitry Chestnykh ___ 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
Should I make a point of always building future Fossil releases using MinGW instead of MSVC? If there are no issues with MinGW binaries, then I think, yes. Any Windows users want to chime in? -- Dmitry Chestnykh ___ 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
On Sep 26, 2011, at 5:47 PM, Thomas Schnurrenberger wrote: For the Microsoft C compiler the following page explains how to enable wildcard expansion: http://msdn.microsoft.com/de-de/library/8bch7bkk%28v=VS.100%29.aspx I dont know if this also works with older compilers. Aha, so there's way to expand wildcards with VS compilers without writing more code! Other versions drop down (on en-us page) shows that it's available on VS 2003, 2005, 2008, and 2010. -- Dmitry Chestnykh ___ 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] Feature request: edit files via web interface
often I would find very useful to edit versioned files trough the web interface. Would you consider to add such a feature? Some thoughts to consider about implementation are in this ticket: http://www.fossil-scm.org/index.html/tktview?name=ad98e8f665 [ copying here for discussion: ] dmitry added on 2011-01-20 14:01:59 UTC: Here are some thoughts on implementation. • Have can edit on web permission flag. • Have special per-user staging area for edits from web, which records modifications to files. • Once file(s) are edited, they're put into the user's staging area. • User can commit his staging area if he has commit permission. • Users without commit permissions, but with can edit on web permissions, can create tickets with modifications from their staging area or download their modifications as a patch. This won't work for anonymous or other group users. For those Fossil can have per-file editing without staging area. Also, not sure how to handle merges. -- Dmitry Chestnykh ___ 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] a fix wish for the configure guru(s)...
in blob.c readlink() is used, but according to my man pages (and compiler), we need: #define _POSIX_C_SOURCE 200112L Is this Linux with glibc from 2006? :-) According to `man feature_test_macros`: If no feature test macros are explicitly defined, then the following feature test macros are defined by default: _BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE, and _POSIX_C_SOURCE=200809L (200112L in glibc versions before 2.10; 199506L in glibc versions before 2.4; 199309L in glibc versions before 2.1). -- Dmitry Chestnykh ___ 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 fossil docs: is the wiki or embedded docs preferred?
On Sep 16, 2011, at 9:39 PM, Paul Ruizendaal wrote: Hmmm… If Fossil was created today, with the knowledge of today, would it still have wiki pages? Would it make Fossil a simpler, but equally powerful tool if it just had (web editable) embedded documentation? Embedded documentation is versioned along with files, so no, I don't think it would be better. I, for one, wouldn't want to frequently merge my working copy with changes to embedded docs made from web interface. Plus, this would create unwanted forks. Also, having a separate wiki allows for more granular access control. -- Dmitry Chestnykh ___ 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] Has any fossil user ever experienced a SHA1 collision?
On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote: Just for the sake of my curiosity; is there any fossil user out there who has encountered a SHA1 collision ? Nope. You'd hear about it in the news :-) There's a theoretical collision attack at 2^51 operations (instead of the ideal 2^80), but it's a specific attack (which means that you're specifically trying to craft two messages that give the same hash), and if I'm not mistaken, the probability of collisions from a good source (not specifically crafted) is still the same as before the attack. -- Dmitry Chestnykh ___ 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] Has any fossil user ever experienced a SHA1 collision?
On Sep 15, 2011, at 2:54 PM, jos van kesteren wrote: Just for the sake of my curiosity; is there any fossil user out there who has encountered a SHA1 collision ? Nope. You'd hear about it in the news :-) There's a theoretical collision attack at 2^51 operations (instead of the ideal 2^80), but it's a specific attack (which means that you're specifically trying to craft two messages that give the same hash), and if I'm not mistaken, the probability of collisions from a good source (not specifically crafted) is still the same as before the attack. -- Dmitry Chestnykh ___ 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: numerous open trunk leaves
How'd that happen? Can/Should the open leaves 2-6 be closed? Speaking of cleanup, what about removing the following files from trunk? kktodo.wiki rse-notes.txt ci_cvs.txt ci_fossil.txt cvs2fossil.txt -- Dmitry Chestnykh ___ 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] Issues with 1.19 ...
On Sep 7, 2011, at 6:53 PM, Stephan Beal wrote:
On Wed, Sep 7, 2011 at 6:18 PM, Jousef Lofstrom jou...@bigfoot.com wrote:
invalid home directory: /root
That comes from db.c:
zHome = getenv(HOME);
...
if( file_isdir(zHome)!=1 ){
fossil_fatal(invalid home directory: %s, zHome);
}
is /root perhaps a symlink to /home/root or some such?
From file.c, file_isdir() contains:
#if !defined(_WIN32)
if( g.allowSymlinks ){
return rc ? 0 : (S_ISDIR(fileStat.st_mode) !S_ISLNK(fileStat.st_mode)
? 1 : 2);
}else{
return rc ? 0 : (S_ISDIR(fileStat.st_mode) ? 1 : 2);
}
#else
While this doesn't affect the issue in question, thanks for finding this!
Usages of file_isdir() outside of working directory shouldn't be affected by
g.allowSymlinks setting. I'll fix this tomorrow.
--
Dmitry Chestnykh
___
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] coding style guidelines: c89
On Sep 6, 2011, at 11:19 PM, Ron Wilson wrote:
The asm() calls are being used to invoke the rotate instructions. C
does not have operators for peforming bitwise rotation of an operand
and emulating a rotate using shifts is messy and very ineficient:
unsigned int rotateLeft(unsigned int x, unsigned int n)
{
unsigned int t;
t = x (SIZEOFINT - n);
return ((x n) | t);
}
FYI,
$ gcc -O2 -S rotate.c
$ cat rotate.s
…
_rotateLeft:
Leh_func_begin1:
pushq %rbp
Ltmp0:
movq%rsp, %rbp
Ltmp1:
movb%sil, %cl
movl%edi, %eax
roll%cl, %eax
popq%rbp
ret
Leh_func_end1:
..
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658)
(LLVM build 2335.15.00)
(This is GCC with LLVM backend (default on OS X Lion)).
--
Dmitry Chestnykh
___
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 performance testing and is it possible to increase the sqlite3 timeout?
On Sep 3, 2011, at 10:11 AM, Remigiusz Modrzejewski wrote: So now, why wal is not the default? I'm having a trunk build from few days back and a freshly created repo is in delete mode… See disadvantages here: http://www.sqlite.org/draft/wal.html The biggest one is that it requires two additional files. -- Dmitry Chestnykh ___ 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] Silencing warnings about deprecated OpenSSL on OS X
Well, you could just do this (see attached patch). Thanks! But should it be restricted to when compiling http_ssl? To Mac OS X? To 10.7? I think restricting it to just Mac OS X is okay. We know that they deprecated OpenSSL, and we don't have any plans to do something with it apart from making OS X users compile their own OpenSSL once Apple removes it, do we? The probability that there be something else deprecated (zlib? functions from libc?) is tiny. -- Dmitry Chestnykh ___ 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] Problem after 'make clean'
After doing 'make clean', './configure' complains that 'Makefile.in' doesn't exist (and indeed it doesn't) Seem to be deleted by merge here: http://www.fossil-scm.org/index.html/info/e4f1c1fe95 -- Dmitry Chestnykh ___ 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] Silencing warnings about deprecated OpenSSL on OS X
I was curious about this too. Seems they're replacing it with Common Crypto: http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html Yeah, the big warnings are mostly for App Store developers. They (including me :) have to statically compile OpenSSL or use Common Crypto, or else the reviewers won't approve apps. -- Dmitry Chestnykh ___ 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] Problem after 'make clean'
On Sep 2, 2011, at 11:28 AM, Dmitry Chestnykh wrote: After doing 'make clean', './configure' complains that 'Makefile.in' doesn't exist (and indeed it doesn't) Seem to be deleted by merge here: http://www.fossil-scm.org/index.html/info/e4f1c1fe95 I'm wrong, earlier: http://www.fossil-scm.org/index.html/info/2b8cbf3c41 -- Dmitry Chestnykh ___ 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] Silencing warnings about deprecated OpenSSL on OS X
OK. So this should do then. Thank 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
Re: [fossil-users] MD5 and SHA1 from OpenSSL
Maybe it depends on your specific hardware, but on linux32 (i3 core2) I get (kubuntu11-04.iso) : Yay, good then, no need to use OpenSSL. I suspect this is due to LLVM backend of OS X compiler which is default in Lion. For some crypto code I've written it compiles binaries that are slower than the ones produced by the old GCC 4.2. Clearly, the new code is much better than the old code; Good job! but it's not clear the openssl code is always a win... I'm not sure whether or not it's a good idea to try to determine at run time which to use (since the check overhead has to be measurable after all). Yes, let's leave it as it is. -- Dmitry Chestnykh ___ 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] MD5 and SHA1 from OpenSSL
Given that one of fossil's selling points is ease of installation, including having no external dependencies. Let's not change that. I agree, but I proposed (and the retracted) that OpenSSL will be used only when compiled with SSL support ;-) -- Dmitry Chestnykh ___ 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] MD5 and SHA1 from OpenSSL
BTW, if I run `openssl sha1`, it's slower than Fossil's sha1test compiled with OpenSSL SHA-1: openssl sha1: real0m3.459s user0m3.126s sys 0m0.317s fossil with OpenSSL's SHA1 from my diff: real0m3.025s user0m2.707s sys 0m0.315s current fossil trunk: real0m3.557s user0m3.236s sys 0m0.317s $ openssl version OpenSSL 1.0.0d 8 Feb 2011 I have Core 2 Duo 2.26 GHz (white unibody MacBook), OS X 10.7.1 Maybe the command-line openssl does something else? -- 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] Silencing warnings about deprecated OpenSSL on OS X
OpenSSL has been deprecated in OS X Lion (boo!), and Apple put warnings everywhere. It's kind of annoying to see this when building Fossil: ./bld/http_ssl_.c: In function ‘ssl_global_init’: ./bld/http_ssl_.c:104: warning: ‘SSL_library_init’ is deprecated (declared at /usr/include/openssl/ssl.h:1553) ... To silence these warnings I build with: CFLAGS=-Wdeprecated-declarations make I'm not familiar with the build system, could someone include this flag for darwin in autosetup? Thanks! -- Dmitry Chestnykh ___ 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] Testing 'symlinks' branch (was Testing for a release)
[stephan@cheyenne:~/cvs/fossil/whio/pfs]$ f stash apply 1 f: ./bld/blob_.c:270: blob_str: Assertion `(p)-xRealloc==blobReallocMalloc || (p)-xRealloc==blobReallocStatic' failed. Aborted This appears to have been caused by (be or related to) the the apply/pop would have applied to being truncated to 0 bytes What, you don't want to apply _filenames_ instead of the stashed deltas to your files? :-) Fixed here: http://www.fossil-scm.org/index.html/info/0317a929cb That was due to wrong column index, a mistake I made when merging trunk into symlinks branch. I'll go through the diff again to check if I made similar mistake somewhere else. I've changed the thread subject to keep bugs in symlinks branch separate from trunk testing. Keep 'em coming! (Don't forget to backup :) -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
