Re: [fossil-users] Fossil update goes not get lastest checkin
Is there a known problem with time skew in the first place? Maybe resolving that would fix these untraceable phantoms. I also bumped into something similar when hosting the same .fossil on two different servers with a time skew between them. Everything was fine when I fixed the time settings, though I logged an extra comment to ticket 683457aa0f in case it would be useful. > i'm wondering if perhaps your server had "system event" and the clock was > skewed for a brief period. That's probably impossible to know for sure now. >Perhaps the clock on the host NFS system is slower than the one on your >mac? Perhaps a time mis-sync is causing this? ___ 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] FossilFS. Was: libfossil + fuse
On 4/24/2014 5:04 PM, Matt Welland wrote: I'm not sure you'd be able to deliver a precompiled binary with dependencies on fuse Then call it through pointers obtained from dlopen() and dlsym(). Now have fun making that portable. :^) -- Andy Goth | ___ 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] Tracking System Configuration Files - Best Practices
They told me they use the open source version of Tripwire ( http://sourceforge.net/projects/tripwire/). They won't let me even see the scripts, but said they started with scripts they found on the web. I tried looking, but only found general stuff. On Thu, Apr 24, 2014 at 1:28 PM, Chad Perrin wrote: > On Thu, Apr 24, 2014 at 12:23:29AM -0400, Ron Wilson wrote: > > On Wed, Apr 23, 2014 at 9:38 AM, Will Parsons >wrote: > > > > > This kind of stuff isn't a "project", and you don't > > > need the extra stuff that Fossil (or Git, Mercurial, Bazaar, > > > Subversion, or CVS) provide. I've tracked system files for over a > > > decade with RCS (and before that with SCCS) and see no reason to > > > change. > > > > > > > I disagree. Very often system changes have to be coordinate across > several > > config files. Most distributions have admin tools to take care of this, > but > > don't track the history of the changes. For most uses, this is fine. > > > > Where I work, the IT people already use a tool like Tripwire to monitor > the > > status (including ownership and permissions) of system critical > directories > > and files. Another part of this tool is used to reset the permissions, > > ownership, etc of these files when changes are made. Because of this, > they > > can - and do - use Fossil to track system configuration changes. > > > > By using this combination of distribution provided tools, a few custom > > tools, the Tripwire like tool and Fossil, they actually have more and > > better control of configuration. And they save the company several $10k > per > > year in licensing fees for commercial system management suites. > > What are the chances you could produce a description of how this setup > is used such that it would provide a howto for setting up similar > systems in other people's networks, or convince someone else to write > such a thing? This could make for an excellent article somewhere. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FossilFS. Was: libfossil + fuse
+1 (and I'm bumming I only get a "1" for my +) This would be a really sweet addition to fossil. Consider caching under /var/tmp or something so that performance is decent. I'm not sure you'd be able to deliver a precompiled binary with dependencies on fuse but being able to compile in this feature would be very appreciated. On Thu, Apr 24, 2014 at 1:11 PM, Richard Hipp wrote: > > On Thu, Apr 24, 2014 at 3:47 PM, Andy Goth wrote: > >> What I most look forward to in libfossil is the potential to expose a >> repository, including all its yummy history, into a Unix filesystem. >> > > I don't think you need libfossil to do this. Looking at the "hello world" > example of fuse at > http://fuse.sourceforge.net/doxygen/hello_8c.html it seems to me that we > ought to be able to add a command (linux only) like, perhaps, > > fossil fuse $MOUNT_DIR > > and do everything that we need within the standard Fossil executable. I > propose adding this command in a new source file "src/fuse.c". (NB: The > foregoing is written without ever before used fuse or the fuse API, so > perhaps it is more difficult than I imagine.) > > The "fossil fuse" server would need to maintain a cache of recently > accessed manifests and of check-in names, for efficiency. But the "/doc" > URL already does that, so there is precedent. > > Maybe several different ways to access files: > > hash/$HASH/$filename > tag/$TAG/$HASH/$filename > date/$MMDD/$HHMMSS/$HASH/$filename > > In all of the above, $HASH would be the first 10 characters of the SHA1 > hash for the check-in if the hash is unique, or as many additional > characters as are needed to make it unique. We can think about ways of > adding support for wiki, events, and tickets later. > -- > 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 > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] libfossil + fuse
On Thu, Apr 24, 2014 at 10:05 PM, Stephan Beal wrote: > On Thu, Apr 24, 2014 at 9:47 PM, Andy Goth wrote: > >> I'd like something similar with Fossil, though completion of libfossil is >> an obvious prerequisite. Putting libfossil and fuse together could be the >> way to go. >> > > Feel free to come help out - as a registered Fossil dev you've already got > the licensing prerequisite :). > BTW: libfossil already has all the core features needed for what you're proposing, or at least has the infrastructure to support them easily. What it's completely missing, in a nutshell: - update/merge - stash: relies on merge - annotate: waiting on the devs to stop tweaking fossil's annotate so that i can port it - anything network related, including sync in any form - full tickets support: relies heavily on th1, and i want to avoid tying any given script language to the core lib and that's the order those are likely to be tackled. Though update is not a prereq for sync, the core lib will not know anything about networking. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] FossilFS. Was: libfossil + fuse
On Thu, Apr 24, 2014 at 3:47 PM, Andy Goth wrote: > What I most look forward to in libfossil is the potential to expose a > repository, including all its yummy history, into a Unix filesystem. > I don't think you need libfossil to do this. Looking at the "hello world" example of fuse at http://fuse.sourceforge.net/doxygen/hello_8c.html it seems to me that we ought to be able to add a command (linux only) like, perhaps, fossil fuse $MOUNT_DIR and do everything that we need within the standard Fossil executable. I propose adding this command in a new source file "src/fuse.c". (NB: The foregoing is written without ever before used fuse or the fuse API, so perhaps it is more difficult than I imagine.) The "fossil fuse" server would need to maintain a cache of recently accessed manifests and of check-in names, for efficiency. But the "/doc" URL already does that, so there is precedent. Maybe several different ways to access files: hash/$HASH/$filename tag/$TAG/$HASH/$filename date/$MMDD/$HHMMSS/$HASH/$filename In all of the above, $HASH would be the first 10 characters of the SHA1 hash for the check-in if the hash is unique, or as many additional characters as are needed to make it unique. We can think about ways of adding support for wiki, events, and tickets later. -- 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] libfossil + fuse
On Thu, Apr 24, 2014 at 9:47 PM, Andy Goth wrote: > I'd like something similar with Fossil, though completion of libfossil is > an obvious prerequisite. Putting libfossil and fuse together could be the > way to go. > Feel free to come help out - as a registered Fossil dev you've already got the licensing prerequisite :). > Of course, it would also be necessary to devise a mapping between > filesystem names and Fossil. ClearCase's method of naming versions fits > the Unix filesystem reasonably well, but Fossil deviates significantly, and > for good reason. I'm not saying it's impossible, only that it will take > some thought. > /doc/BRANCH/path provides a convention? Where BRANCH can be a version name/UUID. Clearly, one way to go (can certainly support multiple simultaneously) > would be to let artifact IDs, or unambiguous prefixes thereof, map to the > artifacts. Whether this is only valid for checked-in files or also for > stuff like events and wiki and tickets, that's an open question, as is what > you get when you readdir(). The top level of the repository directory > should probably contain subdirectories indicating the naming mechanism used > within, for instance /repo/artifact/01234567 is how you get artifact with > prefix 01234567 from the repository mounted at /repo. > For this purpose it would probably be useful/speedier to calculate the top-most paths in advance (the known branch names). > Ambiguous prefixes probably shouldn't be treated as nonexistent files, > since nonexistent files ought only to mean there's zero artifacts with that > prefix. Instead maybe make them directories containing all the artifacts > with the prefix. > Once you know the version you want to traverse, you can get the list of all dirs in that version, and provide a tree based on that. IIRC that list currently has to be collected in C code, but only because i have not yet found a query which can do it in one go (maybe a recursive query can do the equivalent of reading in the list of all files for any given version based on the mlink table?). > How should different artifact types be distinguished? More directory > hierarchy, I'd imagine. i wouldn't support anything but files, at least initially. Wikis are probably simple: wiki:/Name/version (maybe the version should go after files, too, and assume the tip of the branch: BRANCH/filename[/version]?). Tickets... maybe ticket:/reportName/[list of entries] ??? > And where would the metadata go? I dunno. It could be cached in the repo db. Fossil, when rebuilding, ignores tables named fx_* for such "extensions" purposes. They don't get synced (once we have proof-of-concept extensions, maybe we can extend sync support to optionally sync extension tables which follow certain conventions (TBD)). , though perhaps there are better ways to go such as making the contents of > the file be yet another kind of metadata. Or we just draw the line and say > that only file data is exposed. > i would suggest that initially, but plan for a path convention which supports extension, e.g. a URL: file:, wiki:, ticket:, event:, user:, timeline:,... > I should hope knowing the artifact IDs isn't the only way to get around. > Perhaps also have /repo/commit/VERSION/ be the root of a directory tree > containing all the files in the commit named by VERSION, which could be an > artifact ID or tag or date. > That would be "relatively easy," i think, because everything under VERSION/ is what is stored in a Manifest, e.g. the list of all files, the checkin time, the comment, etc. So maybe: VERSION/files is a pseudir containing the list of files, VERSION/comment and /user are "files" containing the checking comment and user name, VERSION/time the checkin time, etc. > This needs a great deal more thought. I'm just trying to put out some > ideas to get us started. > This should possibly be moved to the -dev list? > This would be a great way to glue Fossil to scripts or diff or vimdiff or > whatever tools you like so you can simultaneously work with normal files > and old stuff that would otherwise be buried in the repository. +1 That's the type of weird case i have been hoping to see someone suggest for libfossil - i hadn't thought of that one yet. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] libfossil + fuse
What I most look forward to in libfossil is the potential to expose a repository, including all its yummy history, into a Unix filesystem. At work I use ClearCase (when forced), and it bothers me a lot. But it does have one feature I use a bunch: mvfs. If I version /main/branch/5 of a file foo.c, I can access it as /repo/foo.c@@/main/branch/5 using any program I like, for instance vim and diff, and I'm not limited to using the rather pathetic tools that come with ClearCase for doing merges and such. I'd like something similar with Fossil, though completion of libfossil is an obvious prerequisite. Putting libfossil and fuse together could be the way to go. Of course, it would also be necessary to devise a mapping between filesystem names and Fossil. ClearCase's method of naming versions fits the Unix filesystem reasonably well, but Fossil deviates significantly, and for good reason. I'm not saying it's impossible, only that it will take some thought. Clearly, one way to go (can certainly support multiple simultaneously) would be to let artifact IDs, or unambiguous prefixes thereof, map to the artifacts. Whether this is only valid for checked-in files or also for stuff like events and wiki and tickets, that's an open question, as is what you get when you readdir(). The top level of the repository directory should probably contain subdirectories indicating the naming mechanism used within, for instance /repo/artifact/01234567 is how you get artifact with prefix 01234567 from the repository mounted at /repo. Ambiguous prefixes probably shouldn't be treated as nonexistent files, since nonexistent files ought only to mean there's zero artifacts with that prefix. Instead maybe make them directories containing all the artifacts with the prefix. How should different artifact types be distinguished? More directory hierarchy, I'd imagine. And where would the metadata go? I dunno. There are funny tricks where an object in the filesystem is both a file (you can cat it) and a directory (you can ls it), though perhaps there are better ways to go such as making the contents of the file be yet another kind of metadata. Or we just draw the line and say that only file data is exposed. I should hope knowing the artifact IDs isn't the only way to get around. Perhaps also have /repo/commit/VERSION/ be the root of a directory tree containing all the files in the commit named by VERSION, which could be an artifact ID or tag or date. This needs a great deal more thought. I'm just trying to put out some ideas to get us started. This would be a great way to glue Fossil to scripts or diff or vimdiff or whatever tools you like so you can simultaneously work with normal files and old stuff that would otherwise be buried in the repository. -- Andy Goth | ___ 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] Tracking System Configuration Files - Best Practices
On Thu, Apr 24, 2014 at 12:23:29AM -0400, Ron Wilson wrote: > On Wed, Apr 23, 2014 at 9:38 AM, Will Parsons wrote: > > > This kind of stuff isn't a "project", and you don't > > need the extra stuff that Fossil (or Git, Mercurial, Bazaar, > > Subversion, or CVS) provide. I've tracked system files for over a > > decade with RCS (and before that with SCCS) and see no reason to > > change. > > > > I disagree. Very often system changes have to be coordinate across several > config files. Most distributions have admin tools to take care of this, but > don't track the history of the changes. For most uses, this is fine. > > Where I work, the IT people already use a tool like Tripwire to monitor the > status (including ownership and permissions) of system critical directories > and files. Another part of this tool is used to reset the permissions, > ownership, etc of these files when changes are made. Because of this, they > can - and do - use Fossil to track system configuration changes. > > By using this combination of distribution provided tools, a few custom > tools, the Tripwire like tool and Fossil, they actually have more and > better control of configuration. And they save the company several $10k per > year in licensing fees for commercial system management suites. What are the chances you could produce a description of how this setup is used such that it would provide a howto for setting up similar systems in other people's networks, or convince someone else to write such a thing? This could make for an excellent article somewhere. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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 update goes not get lastest checkin
On Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff wrote: > maybe this additional observation helps to get this "missing commit" > phenomenon sorted out -- it really is a bit scary even if nothing really > bad is happening to the repo content. > It is indeed, but until we can see it happening we can only guess as to what might actually cause it :(. My setups are almost 100% identical to yours - CGI repos mostly used by one user (except that i use autosync because i forget to push if i don't). i've been using Fossil daily for over 6 years and haven't seen this happen even once. Enough people have, though, that it's obviously happening. the fork in question is [a8cbddcfc3]. In the meantime I have closed it > explicitly and edited the checkin comment (the latter I did directly in the > server-side repo where I've chosen a different user name than for the local > clone). the original ci-comment was identical to that of [efd8772a0b] (and > it's diff vs. [88f8514b9f] is a subset of the diff of [efd8772a0b] vs. > [88f8514b9f]). > i'm wondering if perhaps your server had "system event" and the clock was skewed for a brief period. That's probably impossible to know for sure now. > I could not make head nor tail of this. I also cannot rule out completely > that I am responsible for the fork (making some stupid error) but really > cannot imagine how and that it has nothing to do with the problems > discussed in this thread. but maybe it does ... > It does indeed sound somewhat related. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] Copy User & Category Configuration
On Thu, Apr 24, 2014 at 6:07 AM, Ron Wilson wrote: > The original repository: pw 'c0644e265cbb14d2c97921e7485293ff00abaa77' >> The imported configuration repository: pw >> 'a7592474d2116164ebfe0f6513c1824cd6e8511c' >> Even though the password is the same. I guess different repository has >> different password key. >> > Right. Imagine if they were the same - anyone who got ahold of any repo could potential decrypt your password. The passwords are hashed using 3 components: the user name, his password, and a "shared secret" which is local to each clone of a repo. > Is there a way to copy the password as well to other repository? >> >> Fossil has a way to designate one repository as the master for > authenticating user login. You still have to export user information to > each new repository and configure each to use the master for password > authentication, but once setup, all authentication for any of the > repositories is handled via the one. > > (Unfortunately, I can't find the documentation for this feature.) > It's called a "login group," but unfortunately i have no experience with them so can't offer any tips. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ 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] compiler warnings
2014-04-23 7:58 GMT+02:00 Ron Aaron :
> Cross-compiling for Windows using mingw32 gcc 4.8.2 ( -O3 -Wall ) I get:
>
> ./src/sqlite3.c: In function 'balance':
> ./src/sqlite3.c:57557:22: warning: array subscript is above array bounds
> [-Warray-bounds]
> pOld = apCopy[++j];
>
> and
>
> ./src/th.c: In function 'Th_ListAppend':
> ./src/th.c:194:5: warning: assuming signed overflow does not occur when
> assuming that (X + c) >= X is always true [-Wstrict-overflow]
>if( nReq>pBuffer->nBufAlloc ){
> ^
See:
and
Looks like gcc is at fault here.
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil update goes not get lastest checkin
just for the record, I believe I encountered something similar: I have a very simple setup: a remote (cgi-served) repo (acting essentially only as a backup but publicly accessible) and _one_ local clone where only _one_ user (me) does checkins (the owner of the remote server _could_ clone/do checkins but he doesn't...). autosync is 'off' right now, so I do the `sync/push' manually (by habit I use `sync' although `push' would suffice since no one _ever_ does an independent checkin to the server-side repo (no other clone, no local developer on the server) and I do not expect "incoming" changes. so what I have observed a week ago was some hickup (I don't recall what exactly, either a failed `sync' or `push') and retried (probably at that point `sync'). I then discovered a fork popping up in the timeline which, moreover, confusingly was some ten days in the past (the timeline had already progressed several commits after the fork). I don't see any reason why (and any way how) this fork could have occurred. maybe this additional observation helps to get this "missing commit" phenomenon sorted out -- it really is a bit scary even if nothing really bad is happening to the repo content. if you want to have a look, the repo is freely accessible here: http://j...@fossil.0branch.com/sd (maybe the repo content is even of some interest to someone ...) the fork in question is [a8cbddcfc3]. In the meantime I have closed it explicitly and edited the checkin comment (the latter I did directly in the server-side repo where I've chosen a different user name than for the local clone). the original ci-comment was identical to that of [efd8772a0b] (and it's diff vs. [88f8514b9f] is a subset of the diff of [efd8772a0b] vs. [88f8514b9f]). I could not make head nor tail of this. I also cannot rule out completely that I am responsible for the fork (making some stupid error) but really cannot imagine how and that it has nothing to do with the problems discussed in this thread. but maybe it does ... j. On Thu, 24 Apr 2014 07:20:56 +0200, Andy Bradford wrote: Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200: I have no clue on sync logic at all, but perhaps this helps: in all cases I remember here (3 or so), when sync of commit on host A was not seen during sync on host B, doing a dummy-commit on host A, then pulling again on B, worked, i.e. last 2 commits from A were pulled. This sounds almost identical to the problem that I described that is caused by a failed autosync except there is no mention of fork happening. The fork may or may not happen if the branches were different. But, committing after a failed sync will certainly cause another autosync and then the push with the new changes will cause the missing content to show up. Andy -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
