Re: [fossil-users] fossil-users@lists.fossil-scm.org
Try CC=gcc ./configure before you run 'Make'. The autoconfig tool uses cc, which is an alias for the 'clang' compiler frontend. On Mon, Mar 25, 2013 at 11:14 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Thanks, I did install the CL tools, but something is clearly awry if its working for others. A reinstall should sort it. Thanks again, Stephen On Monday, March 25, 2013, Clive Hayward wrote: It looks like your command line c compiler is not configured as expected. Did you install the command line Xcode? See http://stackoverflow.com/questions/9329243/xcode-4-4-command-line-tools On one of my machines I have no difficulty building fossil from sources. which cc /usr/bin/cc cc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Mon, Mar 25, 2013 at 10:29 AM, Stephen De Gabrielle spdegabrie...@gmail.com wrote: Hi, anyone had trouble compiling fossil on osx? I've not done it for a while and I'm wondering If I've missed something important? cheers, Stephen sp-laptop:fossil spdegabrielle$ ./configure Host System...x86_64-apple-darwin12.3.0 Build System...x86_64-apple-darwin12.3.0 C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...not found Error: Compiler does not work. See config.log Try: 'configure --help' for options sp-laptop:fossil spdegabrielle$ xcrun -find gcc /Applications/Xcode.app/Contents/Developer/usr/bin/gcc sp-laptop:fossil spdegabrielle$ cat configure #!/bin/sh dir=`dirname $0`/autosetup WRAPPER=$0 exec `$dir/find-tclsh` $dir/autosetup $@ sp-laptop:fossil spdegabrielle$ open . -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Clive Hayward -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen Professor: Oh God! I clicked without reading! Cubert: And I slightly modified something I own! Professor: We're monsters! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] timezone in ubuntu
On Wednesday, September 5, 2012, E. Timothy Uy wrote: In case anyone ever runs into this issue (an xinetd env issue), the solution is to add the following to your service: server = /usr/local/bin/fossil server_args = http REPOSITORY env = TZ=PST8PDT (insert your timezone here) I suggest using time zone names in stead of the old Posix time zone designators. If you use 'America/Chicago' or such daylight savings time will start and end on the correct date. Gé -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Signing
On Fri, May 25, 2012 at 10:59 AM, Ron Wilson ronw.m...@gmail.com wrote: On top of that, could support signing one or more of the existing signatures at the time of signing. When I sign a commit, it can mean multiple things: 1) I wrote this (authentication) 2) I approve this (authorization) In case 1, we have a one-to-one and immutable correspondence between signature and commit artifact. This signature is the one used to pin the blame on someone if you find a backdoor in the code :-( In case 2, there can be multiple signatures, some after the fact. These could be used to keep track of code reviews and/or manager approvals. Now If I'm signing your type 2 signature, what does that actually mean? I approve of you approving this? Signing type 1 signatures is just the 'authorization' type signature. -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil commands will not follow through managed symlink dirs
To prevent stupid stuff from happening fossil could (on (Lin|Un|Pos)ix at
least) track whether any file it manages shows up twice by looking at the
output of the stat() system call:
if (S_ISREG(statdata.st_mode) statdata.st_nlink 1) {
if (seen_before(statdata.st_dev, statdata.st_ino))
- if the link count is 1 remember the device inode number
- look for duplicate device-inode pairs, and throw a fit if a combination
shows up more than once.
Backup programs do this to handle hard links.
On Tue, May 15, 2012 at 5:20 PM, Ron Wilson ronw.m...@gmail.com wrote:
On 5/15/12, James Masters james.d.mast...@gmail.com wrote:
Sorry, I missed the crucial step of adding and comitting dir_b as a
symlink. Please append this to my example above:
% fsl add dir_b
ADDED dir_b
% fsl commit dir_b -m 'adding symlink'
ADDED dir_b
...
% fsl ann dir_b/foo
fossil: no such file: dir_b/foo
The confusion is that dir_b is a symlink to dir_a and when I follow that
symlink for normal file operations, it operates upon the file as if it
were
a normal dir/file at the OS level. But not with fossil.
To most applications, dir_a/foo and dir_b/foo are 2 seperate files. In
Unix derived OSes, symbolic links are designed to be transparant to
applications that are ignorant of sym links.
You might argue that Fossil has a need to be aware of sym links, else
you end up with 2 (or more) of the same file under different names
(where name == the full path), but there are more complications. Even
if sym links worked exactly the same in all OSes, how to treat any
given sym link is an open question subject to a lot of debate.
For me, sym links would be a way to reference the working copy of a
shared subproject in a project's working copy. While SVN's way of
handling external references works, in my experience, it is too easy
to end up with multiple working copies of the same shared project, so
even with that usage model, there are complications.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Gé
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 1:49 PM, Steve Bennett ste...@workware.net.auwrote: Joe Mistachkin has recently added support for calling TH1 scripts on certain actions. See http://www.fossil-scm.org/index.html/info/0b61e3c019 In the jimtcl branch, TH1 is replaced with Jim Tcl, so any of these scripts has the full power of Jim Tcl, including exec. This sounds a whole lot like mobile code. I was left wondering: would it be enough to do a 'fossil clone something' to download a malware script onto my system? How is this capability secured? -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil/git interaction
On Sunday, January 8, 2012, Russ Paielli wrote: I am wondering about fossil/git interaction. Everyone else seems to be using git and github. I see that fossil can import from, and export to, git. If I understand it correctly, however, that is only for creating a new fossil or git repository. Shouldn't it be possible to pull from, or push to, a git repository using fossil? If that were the case, one could use fossil seemlessly with git. Wouldn't that be the ideal situation? Or am I missing something? It's not impossible, but some usage models for git won't work with fossil. The main git repository for git itself for instance has a branch that does not grow linearly but gets 'rewritten' (git push -f) once in a while. That won't fly with fossil, which refuses to rewrite history, however ugly :-) The branching models also differ, in fossil a branch name is an attribute of a commit, in git it's a pointer into the graph of commits. To make a two-way mapping between git and fossil you'd need a database that keeps a one-to-one correspondence between git commits and fossil commits, and intelligently deal with the mismatches between the two. This has been done for Mercurial and Git with some success, but I don't know how successful it is, and what the limitations are. Gé -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Automatically enabled hyperlinks
One approach I have seen is to add a link that when traversed classifies the IP address as belonging to a robot. It could be put on the timeline page, preceded by a warning not to follow the link. -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] IPv6
The best way to handle this is to use getaddrinfo and getnameinfo, deal with multiple sockets and be blissfully unaware of the actual protocol being used in 99% of the code. All the #if stuff is a pain to deal with. -- Gé On Oct 16, 2011, at 18:59, Christopher Vance cjsva...@gmail.com wrote: I note someone (ashish?) is working on IPv6. Thankyou, but there is a caution here. To do this properly, you need to be aware that some operating systems (including OpenBSD, which I'm using) which do not allow IPv4 traffic on IPv6 sockets, therefore requiring separate sockets for IPv4 and IPv6. (Specificially, these OSs drop all traffic to ::/96 and :::0:0/96.) One of the checkins I saw looked something like #if IPv6 is available do IPv6 stuff #else do original IPv4 stuff #endif I'd suggest a more appropriate phraseology might be more like do original IPv4 stuff #if IPv6 is available also do IPv6 stuff #endif or if you still want to collapse the number of sockets where possible #if (IPv6 is not available) || (IPv6 can't do IPv4) do original IPv4 stuff #endif #if IPv6 is available do IPv6 stuff #endif If there are places you really don't want a pair of sockets where there used to be just an IPv4 one, maybe you can add an option (on appropriate OSs) which say to do IPv6 only instead of IPv4 only. (You can always tell IPv4 from IPv6 when you look at the address.) -- Christopher Vance ___ 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] [PATCH] IPv6 support and improved reverse proxying support
Hi Ashish,
On Wed, 5 Oct 2011, Ashish SHUKLA wrote:
I wasn't aware of both sockaddr_storage, and getnameinfo(). They seem good to
me, and I've updated diff[1] to use them.
References:
[1] http://people.freebsd.org/~ashish/fossil-ipv6-rev-proxy.diff
A few comments (not all about your code):
You are using the ss_len member of struct sockaddr_storage. 'ss_len' is
not required to be there by Posix AFAIK. You can just use the size
returned by 'getsockname' or 'getpeername' (third argument).
In my own code I use getaddrinfo(...localhost, port) to generate one
or more sockets to allow connection to localhost only. Works quite well,
and you don't need any special-purpose code for generating a local-only
socket. This would require restructuring the cgi server code to handle
multiple sockets, because on some systems (FreeBSD) you _will_ get
multiple sockets. In general it should be possible to write both the
client and server code without referring to a specific protocol (IPv4 or
IPv6), except if you want to pass a specific protocol to getaddrinfo.
It would simplify things if you pass the port number to 'getnameinfo' as a
string in stead of assigning it later in your code. This code could then
be removed:
+if(i-ai_family == AF_INET) {
+ ((struct sockaddr_in*)i-ai_addr)-sin_port = htons(g.urlPort);
+} else if(i-ai_family == AF_INET6) {
+ ((struct sockaddr_in6*)i-ai_addr)-sin6_port = htons(g.urlPort);
+}
The existing code (before your patch) has one problem: if a connection
disappears between the return of 'select' and the 'accept' call the accept
can 'hang' until the next connection gets made. The 60 second timeout will
therefor not always work. The way to get around that is set the listening
socket to non-blocking, and turn non-blocking back off for the socket you
get from 'accept'. If accept produces and error with errno equal to
EWOULDBLOCK or ECONNABORTED you just ignore it.
I've attached some sample code that more or less implements this. The code
does not fork a new process, but it does the other stuff.
Ge'#include stdio.h
#include stddef.h
#include stdlib.h
#include string.h
#include errno.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include netdb.h
#include sys/select.h
#include fcntl.h
#include unistd.h
int open_server_sockets(int socklist[], unsigned maxsock, const char *host,
const char *svc)
{
int r;
struct addrinfo hints, *res, *res0;
const char *fail = NULL, *code = NULL;
unsigned numsock = 0;
memset(hints, 0, sizeof(hints));
hints.ai_flags = AI_ADDRCONFIG | AI_PASSIVE;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
r = getaddrinfo(host, svc, hints, res0);
if(r != 0){
fprintf(stderr, can't resolve %s:%s: %s\n, (host ? host : ANY),
(svc ? svc : ANY), gai_strerror(r));
return -1;
}
for(res = res0; res != NULL numsock maxsock; res = res-ai_next){
int s = socket(res-ai_family, res-ai_socktype, res-ai_protocol);
int yes = 1, t;
if(s 0){
fail = socket; code = strerror(errno);
continue;
}
if(setsockopt(s, SOL_SOCKET, SO_REUSEADDR, yes, sizeof(yes)) 0){
fail = setsockopt; code = strerror(errno);
continue;
}
if(bind(s, res-ai_addr, res-ai_addrlen) 0){
fail = bind; code = strerror(errno);
continue;
}
t = fcntl(s, F_GETFL, 0);
if(t 0 || fcntl(s, F_SETFL, t | O_NONBLOCK) 0){
fail = fcntl; code = strerror(errno);
continue;
}
if(listen(s, 256) 0){
fail = listen; code = strerror(errno);
continue;
}
socklist[numsock++] = s;
}
freeaddrinfo(res0);
if(numsock == 0 fail){
fprintf(stderr, %s failed: %s\n, fail, code);
return -1;
}else if(fail){
fprintf(stderr, warning: %s failed: %s\n, fail, code);
}
return (int)numsock;
}
int simple_server(int sock)
{
char host[NI_MAXHOST], svc[NI_MAXSERV];
int err, t;
struct sockaddr_storage sa;
socklen_t salen = sizeof(sa);
if(getpeername(sock, (struct sockaddr *)sa, salen) 0){
fprintf(stderr, can't get peer address: %s\n, strerror(errno));
return -1;
}
if((err = getnameinfo((struct sockaddr *)sa, salen, host, sizeof(host),
svc, sizeof(svc), NI_NUMERICHOST | NI_NUMERICSERV)) 0){
fprintf(stderr, can decode socket address: %s\n, gai_strerror(err));
return -1;
}else{
printf(connection originating from %s:%s\n, host, svc);
}
t = fcntl(sock, F_GETFL, 0);
if(t 0 || fcntl(sock, F_SETFL, t ~O_NONBLOCK) 0){
fprintf(stderr, can't turn off O_NONBLOCK: %s\n, strerror(errno));
return -1;
}
Re: [fossil-users] Why you should not shun
On Wed, 5 Oct 2011, Michal Suchanek wrote: And when you find an issue with a commit that is some way back in your personal branch it is more logical and easier to review your branch if you append the fix to the commit where it belongs logically or if you append it at the top of the history interspersed with some possibly unrelated changes? One of the downsides of rebasing is that the following workflow does present problems: - develop commit - sync with upstream, rebase/commit - test - sync with upstream, rebase/commit and push The version you tested now no longer exists in the repository. This may not be a big issue in some environments, but it may be a showstopper elsewhere (where I work it is). If you have to use a Git repository in such an environment you end up using hooks to log all updates, and block all forced updates (updates that edit history). Otherwise one clueless developer can do serious damage. Ge' ___ 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] [PATCH] IPv6 support and improved reverse proxying support
On Mon, 3 Oct 2011, Lluís Batlle i Rossell wrote: Additionally, I don't know how portable it is to use always getaddrinfo (POSIX-2001?) while requiring C89. C89 does not address networking, so this issue is unrelated to C89. If getaddrinfo is not supported on a platform that uses the socket API it may be time to move away from it :-( The only extra complexity it adds is that a server has to be able to listen to multiple sockets. Some OSes may give you a single socket that can handle both IPv4 and IPv6 connections, and others will not. Ge' The code could go right now into a branch, and then we change it according to needs and tests. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] is there a fossil/sqlite3 routine to get a Unix Epoch GMT int (current time)?
On Fri, 16 Sep 2011, Richard Hipp wrote: time(0) should give you UTC directly. No need to convert. This is the common implementation, but not required by any standard. Most OSes do it this way, but POSIX and C99 do only require that time_t be an integer or real type (so it could be a double) and the epoch is not specified. So if you want to write utterly portable code: - get the time_t value - use gmtime() to get a 'struct tm' value representing UTC - calculate the # of seconds since 1970-01-01T00:00+0:00 from this representation, which except for counting leap years is simple enough. The downside is that this code is not reentrant. Using strftime(%s, ...) does not work either, %s is non-standard (it's not even part of POSIX). Isn't writing fully portable C code wonderful? BTW: I would not blame anyone for ignoring this issue Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] is there a fossil/sqlite3 routine to get a Unix Epoch GMT int (current time)?
Stephan,
'mktime' converts localtime, it's not designed to do what you want it to
do. Setting is_dst just sets the assumption about whether DST is in
effect. Setting it to -1 makes the routine look it up. I don't know what
happens in that one 'ambiguous' hour each year.
http://pubs.opengroup.org/onlinepubs/7908799/xsh/mktime.html
(FreeBSD added a 'timegm' routine to their library, but it's not
portable.)
This may work:
long UnixTime(time_t now)
{
struct tm *p = gmtime(now);
int y = p-tm_year+1900;
long days = 365l * y + y/4 - y/100 + y/400 + p-tm_yday - 719527l;
return (((days*24) + p-tm_hour) * 60 + p-tm_min) * 60 + p-tm_sec;
}
There's an alternative formula here:
http://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap04.html#tag_04_14
long UnixTime(time_t now)
{
struct tm *p = gmtime(now);
return p-tm_sec + p-tm_min*60l + p-tm_hour*3600l + p-tm_yday*86400l
+ (p-tm_year-70)*31536000l + ((p-tm_year-69)/4)*86400l
- ((p-tm_year-1)/100)*86400l + ((p-tm_year+299)/400)*86400l;
}
Gé___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] is there a fossil/sqlite3 routine to get a Unix Epoch GMT int (current time)?
time(0) returns the current time in whatever representation your system
uses. 'gmtime' is supposed to be able to convert whatever the system uses
into a representation based on UTC. So UnixTime(time(0)) will return the
number of seconds passed since 1970-01-01T00:00+0:00 (the Unix epoch).
That's assuming your clock's in sync :-).
BTW: look at mkgmtime in cgi.c. The assumption that time_t is seconds
after the Unix Epoch is assumed there. Trying to write a fully portable
implementation of that thing will only give you grief.
You should probably ignore all my rambling and directly use the result of
time(0). It doubt there's a system out there that can compile Fossil _and_
uses a different representation of time.
Gé
On Sat, 17 Sep 2011, Stephan Beal wrote:
On Sat, Sep 17, 2011 at 12:25 AM, Gé Weijers g...@weijers.org wrote:
long UnixTime(time_t now)
{
struct tm *p = gmtime(now);
but now the question: if time(0) returns time in either GMT or local TZ, how
can i know which value to pass to UnixTime()?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ignoring CVS/*
Hi, Is there any way I can get fossil to ignore all the CVS directories and anything under it? I can't seem to get ignore-glob to do anything useful here. Thanks, Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Current status on hooks?
On Sat, 10 Sep 2011, Richard Hipp wrote: The hook mechanism should include a delay. This is because client-to-server push operations can occur in multiple stateless steps, and we really want to wait and run the hooks after all steps of the push operation are complete. So, for example, after the first push step, the server says to itself I'm going to run the hooks if I don't get any new information within 15 seconds. Then as additional rounds of push arrive, the counter is reset. The 15-second wait interval should be configurable. I don't like timers like that, a single server may have clients on fast connections 50 feet away, and at the end of a slow intercontinental link, so setting the timer correctly is about impossible. On top of that: they'll be hard to implement for cgi or inetd based servers, where nothing is running unless a client has an open connection. It's been a while since I looked at the protocol specs, but the client usually maintains (implicit) state in this type of protocol, and could very well indicate to the server that a push operation step is the first one (for a pre-commit hook), last one (for a post-commit hook), or both, which could then trigger the hooks immediately. Downsides: - needs a protocol change - what do you do if the last step never arrives? Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Issues with 1.19 ...
My guess: because you're running as root fossil locks itself in a 'chroot' jail. Try creating a directory 'root' in the directory your repository lives in, and make sure the owner of the repository can write to that directory. Or you can set HOME=/ which sets the home directory to the root of the chroot jail. Ge' On Wed, 7 Sep 2011, Jousef Lofstrom wrote: myself@myhostls -ld /root drwxr-x--- 8 root root 4096 Aug 24 15:40 /root myself@myhost mount|grep bind|grep root myself@myhost ... '/root' is not a symlink and not bound (mount bind) to another location, just a normal directory. /Jousef ___ 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] delete: Retrieve versions?
On Fri, 26 Aug 2011, Gilles wrote: I'm not very clear at what a manifest is: www.sqlite.org/debug1/doc/trunk/www/fileformat.wiki It seems to be a list of artifacts (ie. changes?) for each file under source control. The manifest describes a committed revision. It's mostly file names and hashes. When an artifact (in this case the contents of a file) is stored its SHA1 hash is calculated. It's extremely unlikely that two different sequences of characters ever hash to the same SHA1 hash, so Fossil (and Git, Mercurial, ...) use the hash as a way to identify the file content. To reconstruct a particular revision from a manifest you have to create each file listed in the manifest, retrieve the contents using the hash and store it into the named file. Recently the flag '-showfiles' was added to 'fossil timeline'. It shows which files were added, deleted or modified in each commit. The next release should contain this feature. Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Timestamps should be in local time.
On Sat, 20 Aug 2011, Vikrant Chaudhary wrote: Timestamps should be recorded in local timezone rather than in UTC. 1. It hurts eyes and brain to see the time in UTC and then calculate it in local time. 2. For forensics. I'll be able to know which timezone I was while committing that change. And we can always calculate the UTC time anyway. And by storing the time in local time we'll only gain the timezone information in history and loose nothing. Re: 1) as others have pointed out: this is configurable through the UI. Re: 2) If there is a convincing use case for your proposal I would store the time stamp in UTC and store the time zone separately (offset in minutes from UTC). Currently fossil can just use an SQL 'ORDER BY' clause to retrieve commits etc. in order, using local time stamps would make that more painful and definitly slower (you cannot create a simple index for that) Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Concepts: why close a lead
On Fri, 12 Aug 2011, Jos Groot Lipman wrote: One question that pops up: why/when would I close a leaf. I mostly do it to make non-active branches no longer show up in the UI and as the result of some command lines (fossil leaves). I use feature branches a lot, and when I'm done with one I merge it back into to mainline development branch, and then I mark its leaf node as 'closed' to minimize clutter. In Subversion you would just remove the branch (you can revive it if need be). Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] bug: extraordinarily slow rebuild
On Wed, 17 Aug 2011, Christopher Vance wrote: How about fossil test-integrity? fossil: checksum mismatch on blob rid=7657: da39a3ee5e6b4b0d3255bfef95601890afd80709 vs 76ce4c2d48d71c1c50113303fa40dbf1805bfad7 But I also notice that a fresh clone from www.fossil-scm.org on two different OSs shows fossil: checksum mismatch on blob rid=2: da39a3ee5e6b4b0d3255bfef95601890afd80709 vs f62f7b3cc4dfa0516391806d2c1276dd170be809 I just pulled a clean copy of fossil down on two different OS'es (Linux and FreeBSD). I got the same result twice: $ fossil test-integrity -R fos.fos skip phantom 13005 ee2d352b3e23c80eaf4bfa5465be546b12db6e1b 13004 non-phantom blobs (out of 13005 total) verified So no checksum mismatches. Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
On Tue, 9 Aug 2011, Richard Hipp wrote: Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation. If you create the branch first you cannot forget later and commit to the wrong branch. It avoids operator error later on. If you need to edit a file and save your changes to a copy you may do the same: - open the file - use the 'save as' command to change the name - edit for 30 minutes - use the 'save' command. If you could just tell fossil that you intend to commit to a new branch from the current workspace/checkout creating that extra commit object could be avoided without risking a commit to the wrong branch. $ fossil open ~/repos/mrcoffee.fossil $ fossil branch next espresso-feature much later $ fossil commit Commit to new branch 'espresso-feature'? (y/N) Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
On Tue, 9 Aug 2011, Lluís Batlle i Rossell wrote: If you could just tell fossil that you intend to commit to a new branch from the current workspace/checkout creating that extra commit object could be avoided without risking a commit to the wrong branch. You can *later* change the branch, after commit, as we have talked in this thread. And it's not about overwriting files, like your file save example. True, but if your commit is to the wrong branch you're now in a race with other people. If someone performs an 'update' before you change the branch name using the GUI and push the change to the main repository your bad commit propagates. If you do that to, say, the fossil 'trunk' branch for instance someone somewhere is going to end up with your half-finished feature in their production build. Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
On Tue, 9 Aug 2011, Richard Hipp wrote: On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers g...@weijers.org wrote: If you create the branch first you cannot forget later and commit to the wrong branch. I beg to differ! Just this past Friday, I did three separate commits to SQLite that went into the wrong branch even though the correct branch already existed. [...] In fossil (and in most other SCMs) you certainly can. It would be different if the simplest way of creating a branch and moving your workspace over would be a single action. In git for instance branch creation can be done by $ git checkout -b branchname -m which creates the branch (locally) and moves any uncommitted changes over in one go. Because git does not need to create a commit object to create a branch the end result is similar to using $ fossil commit --branch branchname i.e. you do not end up with a commit that is essentially a copy of another one. BTW: the 'fossil branch next' idea is not original in retrospect. Mercurial's 'hg branch' command works this way. It requires that the branch does not yet exist, and the new branch is created upon commit. Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil destroys repositories?
On Mon, 25 Jul 2011, Russ Paielli wrote: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html I expect that mr. Shaw will shoot himself in the foot using git rebase or git push --force one day and abandon git for something else... I use feature branches all the time, and I have never lost anything that can be blamed on Fossil. And I have backups, because I cannot expect to protect me against head crashes, OS bugs, and Monday mornings Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Tarball generation fix (please test)
Hi, I have just committed a fix for issues with long path names when Fossil generates a tar file. What first looked simple wasn't because of backward compatibility requirements. You can find my work in branch 'ge-tarfix'. I have attempted to use the rules laid out on the latest POSIX.1 standard to generate files that are backward compatible with older versions of 'tar'. These rules are described in the 'pax' section of IEEE Std 1003.1-2008. The subset of features I used have been in the standards for over 10 years, and GNU and BSD tar support them fully. If you use very long or non-ASCII file names and your 'tar' program is out-of-date you may see a directory 'PaxHeader' show up. It contains the file information your program was not able to recognize. All feedback is welcome. I'd especially like to have feedback on any issues on non-Unix platforms. Thanks, Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tar file is different then zip file
On Thu, 21 Jul 2011, Rene wrote: Thanks for the bug report. I wonder are you able to get the same (mis)behavior out of fossil as I did out of my repository? Yes, it's reproducible. Once the file path length goes over 100 characters the file quite reliably does not come out right. All the tar implementations I tried (GNU tar and 'pax' on Ubuntu Linux, and BSD tar on FreeBSD) do not create the right file names. Gé -- Rene ___ 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] tar file is different then zip file
I have submitted a bug report on this issue. The 'tar' format has been extended over the years, and it's now a fairly interesting mess. File names over 100 bytes are split into two. Posix requires this to be done at a '/' (which you can delete). Fossil splits it anywhere, which confuses all the extraction utilities I've tried. If the splitting position is calculated correctly Fossil should be able to support file names that: - have = 256 characters. - have a slash no further than 100 characters from the end. - have a slash no further than 155 character from the beginning. - contain only ASCII characters if standard compliance is required. The 2001 Posix.1 standard defines extensions that can support any length of file name, encoded in UTF8, any size file (tar is otherwise limited to 8GB), and all kinds of other stuff. It's known as Pax Interchange Format. GNU and FreeBSD tar understand these extensions. The pax utility on Linux and FreeBSD does not implement it (beats me). Gé On Mon, 18 Jul 2011, Rene wrote: On Mon, 18 Jul 2011 16:15:50 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 4:09 PM, Rene wrote: It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. What version of Fossil are you running on the server, and what version are you running locally? odd the command fossil tarball ffd22b79fe24110d rene.tar --name rene does create a single directory rene. with and without the --name option it is still one single directory -- Rene ___ 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] tar file is different then zip file
The old tar 'v7' format only supports file names up to 99 characters, according to the GNU tar documentation. The check in 'tar_add_header' (tar.c) checks for nName 100. The file name that gets mangled is exactly 100 chars long Gé On Mon, 18 Jul 2011, Rene wrote: On Mon, 18 Jul 2011 15:38:07 -0400, Richard Hipp wrote: On Mon, Jul 18, 2011 at 3:32 PM, Rene wrote: I have converted a cvs repo to fossil. I checked if the tag release_v5_1_0 would yield the same number of files as you can see from this timeline fragment it is version 186f4fdca4 [186f4fdca4] brokerhost geintroduceert * Upd mxflex/gbo/app_po.inc: 1.39 * Upd mxflex/gbo/app_bo.inc: 1.36 (user: renez, tags: trunk, release_v5_1_0) mxflex/gbo/app_bo.inc [diff] mxflex/gbo/app_po.inc [diff] The tar file contains 2 directories mxflex-186f4fdca41c087b(has 991 files) xflex-186f4fdca41c087b(has 2 files) while the zip file contains only one directory mxflex-186f4fdca41c087b(has 993 files) The tar file doesn't produce the release while the zip does. Perhaps the long filename support in tarball generator is busted. Do the two files that differ have very long pathnames? Are they the longest two pathnames in the repository? -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org [1] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users [2] xflex-186f4fdca41c087b has xflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.assemble_plugin_filepath.php mxflex-186f4fdca41c087b has mxflex-186f4fdca41c087b/mxflex/xbr_bus/general/gui/smarty/internals/core.process_cached_inserts.php which is 1 shorter. If I do a tar bal from the head i get this in the top directory 22b79fe24110d d22b79fe24110d -ffd22b79fe24110d x-ffd22b79fe24110d 2b79fe24110d ex-ffd22b79fe24110d flex-ffd22b79fe24110d xflex-ffd22b79fe24110d 79fe24110d fd22b79fe24110d lex-ffd22b79fe24110d b79fe24110dffd22b79fe24110d mxflex-ffd22b79fe24110d while the zip just produces mxflex-ffd22b79fe24110d It seems how closer I come to the latest the more directories the tarbal creates. It must be something specific for this repo because if I do a tarball from my local copy of fossil (hence the same version) I don't see multiple directories. -- Rene ___ 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] sqlite3.h and sqlite3.c
fossil built from the tip has mismatched versions of these two files. The version numbers do not match, and therefor 'fossil sqlite3' is not working. Gé___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] sqlite3.h and sqlite3.c
You're right, thanks. 'touch src/sqlite3.h' followed by a 'make' does not cause any files to be rebuilt. That explains it. Gé On Mon, 27 Jun 2011, Richard Hipp wrote: On Mon, Jun 27, 2011 at 6:41 PM, Gé Weijers g...@weijers.org wrote: fossil built from the tip has mismatched versions of these two files. The version numbers do not match, and therefor 'fossil sqlite3' is not working. The version numbers are correct. But I think there is something wrong with the makefile - a missing dependency. If you do make clean; make it will start working for you. Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Non-synchronized Fossil repositories for same project, can it be done?
Nolan, That should work just fine. I would put the closed-source variant in a separate branch, so they can pull your changes and either merge wholesale or cherrypick at will. Ge' On Wed, 25 May 2011, Nolan Darilek wrote: A commercial company is interested in productizing one of my open source apps. The thought is to keep all existing pieces as open, but to change the app's name, and to add in various proprietary code designed to tap into their own services. Even so, development on the open code will continue, and occasionally changes will be pulled from the open codebase into the closed one. I'd like to stick with using Fossil for both projects, but I'm wondering how to manage this case where these two repositories aren't truly in sync. I'd like to keep closed code completely outside of any open repositories to avoid accidentally tainting open code, so private branches wouldn't seem to be an option. My current thoughts are to clone the open project's repository, deliver that to the company as something they can host on their server. Any open development happens in the open repository, then when I want to merge in changes, I cd to the closed project and run: fossil pull --once http://open.project.url/ My guess is that this would just pull in open changes and won't try to push closed code (I.e. just one side of sync.) Is this going to complain about anything, though? I.e. will it complain if the repositories aren't exact copies before the pull? Also, ideally the changes won't introduce conflicts, since the closed code will be in an entirely separate package. There will be changes in at least one file in the closed branch, though, the AndroidManifest.xml which changes the app name and such. Will Fossil be OK with merging changes that don't cause conflicts, even if the repositories aren't strictly in sync? I hope I can use Fossil in this scenario, as it would vastly ease the pain of trying to keep the proprietary version in sync with the open version. ___ 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] Basic question: how to create fossil web service using bash cgi
On Sun, 6 Mar 2011, David Bovill wrote: My bash scripting is very basic. I've been trying to create some cgi's on the server that will let me create new fossil repos. I've this test cgi, and am unable to issue the commands to fossil that I am able to in the terminal. fossil sees that the environment contains CGI variables and switches to CGI mode. To make this work you'll have to purge the environment, I'm not quite sure which variable you need to remove. Ge' ___ 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 with repos shared over network
I would suggest running the problematic fossil command and capturing the system call trace using 'strace -o LOG fossil cmd'. It's usually easy enough to figure out the problem from the last dozen or so lines from the 'LOG' file. Ge' ___ 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] backout a merge
After you merge in changes from a different branch, but before you check in the merge, is there any way to back out the merge? fossil revert undoes the changes but leaves the files edited, although with no changes. fossil undo type fossil help undo for an explanation Ge' ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Validating repositories
Hi, Is there any way to get fossil to validate (check the hash) of every single artifact? Ge' ___ 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] praise/questions for fossil
I add the capabilities I remove from Adnonymous and Nobody to 'Reader', and give all legitimate users either 'Reader' or 'Developer' access. Gé On Thu, 8 Apr 2010, Joshua Paine wrote: On 04/08/2010 04:57 PM, Wes Freeman wrote: - Is there a way to host a repository publicly, but make it so that anonymous (or non-logged in) people can't see anything in timeline, etc.? Most of my projects are personal or commercial and I don't need people seeing anything (even a timeline) except people I'd like to share the code with. In the web interface, go to Admin Users. Click 'anonymous' and uncheck all the Capabilities. Click 'Apply Changes'. Do the same for 'nobody'. -- Joshua Paine LetterBlock LLC http://letterblock.com/ Web applications built with joy. ___ 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] Fossil GUI for local source tree operations
On Mon, 5 Apr 2010, Twylite wrote: The point about accountability is well made though - perhaps the shun action should cause an entry in the timeline at the time the shun is effected, indicating the artifact that was shunned, the parent of the shunned artifact, and a comment (why it was shunned). The copyright of all derived works (i.e. all merges that touch the bad file) is tainted, so shunning a single object is not enough, you may actually have to shun a lot of artifacts, and modify all commits that somehow depend on any copyrighted files and any variants to keep your repository working. That's not exactly trivial. I work in a heavily regulated industry, and legal concerns have been keeping us from implementing any and all DVCSes until now. Gé -- -- Gé Weijers g...@weijers.org___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil GUI for local source tree operations
On Sun, 4 Apr 2010, D. Richard Hipp wrote: I argue that abandoned branches are part of the historical record and ought to be preserved. Fossil does distinguish between Open and Closed branches. The user interface currently displays all branches on the same page, but if it got to be a problem, the UI could be enhanced to show only the Open branches. I personally prefer to remove my false starts and mistakes, and commit an idealized version of my code development history for other people to review. It's hard enough to perform meaningful code reviews without having to parse people's late-night mistakes. I tend to agree with the Parnas Clements paper that it's often better to fake it [*]. Novelists don't publish their intermediate versions either, BTW, they've been 'faking it' since the invention of creative writing. http://www.fossil-scm.org/fossil/doc/trunk/www/shunning.wiki It's questionable whether you still have a usable repository after you attempt to remove a random artifact that's been involved in merges etc. This is not a criticism of Fossil, by the way, it's always a problem, but it's a little easier to solve on a centralized system. Happy Easter, Gé [*] A Rational Design Process, How and Why to Fake It D. Parnas P. Clements http://www.cs.tufts.edu/~nr/cs257/archive/david-parnas/fake-it.pdf___ 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] RSS feed ignores access control
And thank you for the fix in http://fossil-scm.org/index.html/ci/78a6270fdc Ge' On Thu, 2010-02-04 at 21:40 -0800, Gé Weijers wrote: Hi, I decided to configure a repo for access by a few people only. I took away all privileges for the 'nobody' and 'anonymous' users. Result: your have to authenticate first. The one annoyance is that the RSS feed still shows the titles of individual commits. I don't think it's correct to do that if 'anonymous' cannot browse the timeline. Ge' Filed Ticket 09ba8cea6fc21a4b44e426861e72e3ed88040e85 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Gé Weijers g...@weijers.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RSS feed ignores access control
Hi, I decided to configure a repo for access by a few people only. I took away all privileges for the 'nobody' and 'anonymous' users. Result: your have to authenticate first. The one annoyance is that the RSS feed still shows the titles of individual commits. I don't think it's correct to do that if 'anonymous' cannot browse the timeline. Ge' Filed Ticket 09ba8cea6fc21a4b44e426861e72e3ed88040e85 ___ 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] Passwords stored in cleartext in 'user' table
The most common approaches I know of: Unix-style password file: store salt || H(salt || password) The 'salt' value is a random string used to make attacks that precompute the hash values of common passwords harder. The downside is that the client has to send the password in plaintext. The hash is often iterated a few times to make brute force attacks more time consuming. CHAP: (originally from PPP) send a challenge string from server to client. The client sends back H(challenge || password). Someone now has to brute-force the password if the communication is intercepted. The downside is that the password is stored in plaintext on the server. There are methods that solve both problems (not storing the password on the server, and not sending the password over the wire), but you enter a major patent mine field if you try to use them. If I had to choose I'd store the password as a salted hash. Break-ins into servers are much more common than password intercepts (credit card numbers are stolen from servers, not by intercepting traffic). You can always add HTTPS if interception is an issue. Ge' On 01/10/2010 04:43 AM, D. Richard Hipp wrote: On Jan 9, 2010, at 5:24 PM, D. Richard Hipp wrote: OK. Beginning with http://www.fossil-scm.org/fossil/ci/cfe33dcf92 Fossil will store passwords on servers as either cleartext or as a SHA1 hash of the password. ... I have tagged this change experimental for now. I'm planning to make some additional (incompatible) changes to make the password handling more secure. You can experiment with this version, but you should create backups to restore from after my upcoming incompatible changes. d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Gé Weijers email: g...@weijers.org mailto:g...@weijers.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] What is maximum limit size of a .fsl file ?
Note that blobs are limited to 1G, so artifacts are limited to 1G compressed, even on a 64-bit processor with 8GB of memory (I tried). Gé On 01/07/2010 08:15 AM, Stephan Beal wrote: On Thu, Jan 7, 2010 at 4:32 PM, T.J. Yang tj_y...@hotmail.com mailto:tj_y...@hotmail.com wrote: I may split up source tree into a few branches, but What is biggest size a .fsl should limit to ? _in theory_, the largest item which can portably be committed is somewhere around 1.7GB. That number comes from: a) max memory space for 32-bit platforms = ~4GB. In my experience, 3.6-3.8GB is the max. b) fossil does its diffs in memory, meaning 2 copies (plus the delta) are in memory. That said, it is theoretically possible to create fossil repos on 64-bit platforms which will not work on 32-bit platforms if individual artifacts are too big. The file format itself is endian/bitness-neutral, but the limits of 32 bits can still be hit. For example, if an artifact is 1.95GB in size, diffing that artifact is very likely to fail on 32-bit systems because fossil probably won't be able to malloc() two contiguous chunks of 1.95GB each. Also I hope the warning of oversized .fsl should come out of the fossil commands somehow. i can't personally say how well suited sqlite3 is for 4GB resp. 32bit, but Richard can certainly enlighten us there. IMO, though, anything more than a few hundred MB is out of scope for a fossil repository. i wouldn't even bother to put such large repos in source control - i'd just put the parts which have to be versioned AND will change often into source control, and store the rest as tar files or in a separate tree. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Gé Weijers email: g...@weijers.org mailto:g...@weijers.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
