[fossil-users] Automation
My apologies if this is too long for reading, but I hope you'll bear with me. I like the idea behind chiselapp, but am paranoid so I want to host something similar for myself (and just myself) to keep things private. I downloaded chiselapp and while it *could* work, I decided it was more than I really needed, plus it is Apache centric and I run lighttpd. I have ported configuration files from apache to lighttpd in the past, but just didn't want to bother with it in this case. To that end, I've started creating a few basic scripts to give me a front end to fossil from a protected webpage on a secured server. I have a directory with an index.php which enumerates a directory full of fossils and gives me simple links to each fossil. I have a two line fossil cgi script that gives me access to those repos. I've even created a little page to allow me to change a password for a single user across all repos at one time. My next goal is to script the creation of a new repository. I have the basics down, in that I can easily use a form to get the needed command line parameters and run a script to create the new repo. I'd like to go a little further with it and set the project name description, default permissions, and so on. It does not appear there is a command line based way to set certain configuration options. I've dumped repos with sqlite3 repo.fossil .dump to see how certain things work. To accomplish my goal: 1. Is there a fossil command line based way to set config options (particularly project name and description) that I'm unaware of? 2. If there is not, is this something that could be done with the json api via cli as it exists today? 3. If the json api is not an option at present, what is the significance of the mtime field in the config table? Must it be set to some particular valid value or would an initial value of 0 be okay. If that is the case (or the proper default value is easily obtained / computed) I could easily just use a little SQL to set the needed config table values. FWIW, this is very plain looking stuff (I'm not a web guy at all) but I'd be happy to share the scripts and such when I'm finished. Probably the most useful part is just the scripts in the directory that give a front end that enumerates the existing repositories. -- Scott Robison ___ 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] Automation
On Fri, May 9, 2014 at 9:15 AM, Scott Robison sc...@casaderobison.comwrote:
links to each fossil. I have a two line fossil cgi script that gives me
access to those repos. I've even created a little page to allow me to
change a password for a single user across all repos at one time.
Would you mind sharing that one with us?
My next goal is to script the creation of a new repository. I have the
basics down, in that I can easily use a form to get the needed command
line parameters and run a script to create the new repo. I'd like to go a
little further with it and set the project name description, default
permissions, and so on.
It does not appear there is a command line based way to set certain
configuration options. I've dumped repos with sqlite3 repo.fossil .dump
to see how certain things work. To accomplish my goal:
1. Is there a fossil command line based way to set config options
(particularly project name and description) that I'm unaware of?
Not currently, resp. not that see nor remember.
2. If there is not, is this something that could be done with the json api
via cli as it exists today?
Same there. The JSON API can set some stuff, like user properties, but
doesn't (it seems) have a way to set the project name/description. If you
can suggest a JSON interface for it, i can add it.
3. If the json api is not an option at present, what is the significance of
the mtime field in the config table? Must it be set to some particular
valid value or would an initial value of 0 be okay. If that is the case
(or the proper default value is easily obtained / computed) I could easily
just use a little SQL to set the needed config table values.
IIRC we don't actually use the mtime in the config file (or not often,
anyway). Feel free to set it to 0 or (as we do internally):
strftime('%s','now'). It's a Unix timestamp (so (date +%s) can be used from
scripts).
--
- 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] Automation
On Fri, May 9, 2014 at 1:21 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:15 AM, Scott Robison sc...@casaderobison.com wrote: links to each fossil. I have a two line fossil cgi script that gives me access to those repos. I've even created a little page to allow me to change a password for a single user across all repos at one time. Would you mind sharing that one with us? The fossil cgi script is just based on the one documented elsewhere, so I assume you mean the password change script. You can see it at http://tny.cz/2376d7fa (tinypaste, tny.cz). When the page is accessed via http GET it just displays the page and any optional message that might have been passed as a url parameter. When the info is filled in and the form is POSTed, it does basic validation of the username and passwords. If all is okay, it uses a foreach loop to enumerate all the fossil files in the hard coded directory, runs the fossil command to change the password for the given user on each, and redirects back to the main index with a message. If it detects errors with the username or password, it redirects back to itself with simple messages to give the user a chance to do it again. As I said in my original message, I'm not a web guy, so this is definitely not professional grade. It lives behind a protected directory so I'm the only one with access to it, so robustness and aesthetically pleasing were not my primary considerations. Just something to help automate some things that I continually have to look up whenever I need to do them. If I were looking for a place to host something open source, I'd just go to chiselapp (or expose a repository via a specific unprotected url). In my case: http://www.webducky.com/dev/ - run a front end index script to provide a menu of all the fossils .../dev/project - bash script to set the home environment variable and then... .../dev/fossil-cgi - fossil cgi script. It could be named project directly, but the settings don't work unless the home directory is set first, and this was the easiest way for me to figure out how to do it. .../dev/password.php - the below script linked to from /dev/ .../dev/blah.php - other scripts to be written / finished to create, rename, delete repos. Note there are no copyrights or licenses claimed in the code itself, as I didn't really intend to share it, though I don't mind sharing it. In any case, it is simple enough and non-strategic enough that consider I it public domain, so do with it what you will and realize there is no warranty (not that you could easily prove I was the one who provided it anyway, maybe I just found the link and am claiming it as my own creation). ;) Not nearly as useful or complex as SQLite, but hey, I'm not nearly as bright as DRH either. SDR ___ 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] Trouble when making new repository
2014-05-09 3:13 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: Also, I can commit if I do ``fossil status'' first: That's the difference!: I use fossil status a lot, therefore I didn't notice that the function unsaved_changes() doesn't do anything when vid=0. This bug can be triggered on trunk as well (although with fossil alone you cannot create the situation that vid=0). Fixed on trunk now. Thanks! Just did a fossil new, a single add, and this manifest was created: C x.txt D 2014-05-09T07:30:20.956 F x.txt a1db6bf2d7f484c7bb0c957eef08fb348de4632b R 6d1a3f680cad8c3911b58e8783e5215d T *branch * trunk T *sym-trunk * U nijtmaj Z 6f2cb303c3b860c3542d69b99a38b8f3 Looks good at first sight. But if I close/open the Fossil, the file does not come back. So let's close and open it $ fossil open ../new.fossil x.txt project-name: unnamed repository: /Localdata/workspace/xxx/../new.fossil local-root: /Localdata/workspace/xxx/ config-db:C:/Users/nijtmaj/AppData/Local/_fossil project-code: 15fb36c9fc591186d91adc1e1a636c8845fe5aa5 checkout: 6c3b32f1d696a3db27127baf84f86100d48d29e2 2014-05-09 07:30:20 UTC leaf: open tags: trunk comment: x.txt (user: nijtmaj) checkins: 1 $ fossil ls x.txt The file came back just fine. I thought I fixed all situations in fossil where vid=0, but apparently missed one. 2014-05-08 22:20 GMT+02:00 B Harder brad.har...@gmail.com: I restrained myself in the previous discussion that ended up being about the initial empty commit, but now I feel compelled: the rational, discussion, and decision to remove the initial empty commit were pretty poor, IMO. I don't want to belabor the point, so I'll leave it at that. Happy to discuss or be corrected. My impression is that the only reason for the presence of the initial empty commit is that fossil cannot handle a repository without it. If there is any other reason, please share that with us! I would like to give people a choice: People who want it (e.g. for reasons of legacy) should have it, people who don't expect it shouldn't be surprised by being given one without being asked ;-) Thanks! 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] Trouble when making new repository
On Fri, May 9, 2014 at 3:13 AM, Andy Bradford amb-fos...@bradfords.orgwrote: I too get this same error, however, not for an empty commit: From the current trunk or the one which was moved? Also, I can commit if I do ``fossil status'' first: That's a hint that the vfile table is not being updated in the first case, i think. But if I close/open the Fossil, the file does not come back. Here's the manifest: Oh, that's cool. C one D 2014-05-09T01:07:58.161 R d41d8cd98f00b204e9800998ecf8427e T *branch * trunk T *sym-trunk * U amb Z 2781012c51680d91a7faaa95a714b4af The R-card is a SHA1 of nothing: That's actually correct in a wrong way. If a manifest has a files, its R-card is the initial SHA1 hash. Historically an R-card was required, but fossil no longer requires them because the cost of calculation and verification is unbearable on massive repos. So it didn't even attempt to add the file that it said was ADDED. That's why the R-card is right. The error is the missing F-card. Please tell me that's not on the trunk? Ah, i see that Jan already resolved this, so ... back to hacking :). -- - 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] Trouble when making new repository
On Fri, May 9, 2014 at 9:53 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-05-08 22:20 GMT+02:00 B Harder brad.har...@gmail.com: I restrained myself in the previous discussion that ended up being about the initial empty commit, but now I feel compelled: the rational, discussion, and decision to remove the initial empty commit were pretty poor, IMO. I don't want to belabor the point, so I'll leave it at that. Happy to discuss or be corrected. My impression is that the only reason for the presence of the initial empty commit is that fossil cannot handle a repository without it. If there is any other reason, please share that with us! I would like to give people a choice: People who want it (e.g. for reasons of legacy) should have it, people who don't expect it shouldn't be surprised by being given one without being asked ;-) Just FYI: i explained to Brad off-list last night why RID 0 is currently a historical problem (in that is breaks existing assumptions in some places), but not a technical one. His summary of/metaphor for my rather rambling explanation might be useful to those not well versed in fossil's internals: The initial empty checkin acts as a seed for the checkin subsystem by placing an initial record in the DB from which future records can inherit/grow. That seed is technically not necessary, but some code (like what you just fixed) currently assumes a seed has been planted. -- - 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] Is it advisable to put a .fossil repository on Dropbox?
On Fri, May 9, 2014 at 3:25 AM, Gerald Gutierrez gerald.gutier...@gmail.com wrote: Annoying thing is that when I try to make it happen, even if I run the script via cron (by changing the crontab over and over), it doesn't happen. Here's a really ugly workaround: echo fossil ... | at now will run it through cron immediately ;) Other than that, i can't comment: i've only seen such behaviour in 'ping' on Solaris, where it can cause a backlog of cronjobs, which causes all other jobs to queue up until you kill the pings, at which point _all_ queued jobs, since the queue limit was reached (several days in my case), run in rapid succession! -- - 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] Automation
On May 9, 2014 3:11 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:50 AM, Scott Robison sc...@casaderobison.com wrote: It doesn't need to be great - it'll just be for my own use. i've never gotten around to using the login group support. I looked briefly into it and it seemed that the shared login group stuff only allowed read access to subordinant repos, so I just decided to build a very basic solution that met my modest needs. :) SDR ___ 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] can fossil try harder on sync failure?
On Fri, May 9, 2014 at 5:08 AM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Doug Franklin on Thu, 08 May 2014 23:00:03 -0400: Does SQLite support nested transactions? If so, that would seem to be worth considering. It does appear to support them: https://www.sqlite.org/lang_transaction.html It doesn't directly support them, but fossil/libfossil add a level of abstraction which simulates them. The notable requirement is that one use the [lib]fossil C APIs to begin/end transactions, as opposed to using BEGIN/END directly. Fossil has an assertion in place to catch if COMMIT is called directly from SQL code while C-initiated transaction is opened. -- - 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] Automation
On Fri, May 9, 2014 at 3:15 AM, Scott Robison sc...@casaderobison.comwrote: 1. Is there a fossil command line based way to set config options (particularly project name and description) that I'm unaware of? Not an easy why. You'd have to run fossil sql with appropriate SQL arguments that would update the database directly. -- 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] Trouble when making new repository
Thus said Stephan Beal on Fri, 09 May 2014 11:16:04 +0200: So it didn't even attempt to add the file that it said was ADDED. That's why the R-card is right. The error is the missing F-card. Please tell me that's not on the trunk? Yes, it was on trunk, and that's actually how I discovered it. I used the no-initial-commit fossil to create a new Fossil, then I opened it and added a file. It refused to commit the file, so I took an old version of fossil ran status and then ci and it worked, much to my surprise! Andy -- TAI64 timestamp: 4000536cea43 ___ 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] Trouble when making new repository
2014-05-09 16:45 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: Yes, it was on trunk, and that's actually how I discovered it. I used the no-initial-commit fossil to create a new Fossil, then I opened it and added a file. It refused to commit the file, so I took an old version of fossil ran status and then ci and it worked, much to my surprise! Ah! That's the bug I fixed here: http://fossil-scm.org/index.html/info/636982a564 That explains fully why the F-cards are missing. In current trunk that wouldn't happen any more. Thanks! 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] Tracking System Configuration Files - Best Practices
I was asked off the list to share what I ended up using. It was really quite simple in the end. I somehow missed the setting allow-symlinks. With this turned on, I just create symbolic links in the local tree and now, on the rare occasions that I pull, the link ins't wiped out, but the file pointed to be the link is updated. I can foresee the permission issues mentioned by others, but I rarely pull, so I hope I can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. Thanks for all your replies. Joseph ___ 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 Fri, May 9, 2014 at 5:30 PM, Joseph Mingrone j...@ftfl.ca wrote: can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. If that works, great :). i think that's the first time anyone's reported a painless solution to that problem - thanks for letting us know. -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 17:30:02 +0200, Joseph Mingrone j...@ftfl.ca wrote: I was asked off the list to share what I ended up using. It was really quite simple in the end. I somehow missed the setting allow-symlinks. With this turned on, I just create symbolic links in the local tree and now, on the rare occasions that I pull, the link ins't wiped out, but I don't think that this is the difference between allow-symlinks 'on' and 'off'? the link seems to be _never_ wiped out (independent of that setting), but when the setting is 'on' `fossil' just does not care for the actual content of the file the link points to (notably, it will not show anything with `fossil changes' even if the link(ed file) is modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? the file pointed to be the link is updated. I can foresee the permission issues mentioned by others, but I rarely pull, so I hope I can easily deal with those issues. So, ~/scm/host_config.fossil/ contains the repository (host_config.fossil) and symbolic links to files all over the system (/etc/ and /usr/local/etc/ mostly). So far this has worked well for my needs, but I haven't messed with it too much so far. Thanks for all your replies. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.comwrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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] Tracking System Configuration Files - Best Practices
FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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 -- 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 19:45:01 +0200, Matt Welland estifo...@gmail.com wrote: FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. I'm not sure whether there is a bug here (except the one noted at the end of this mail). my reading of `fossil help set' and a small test I've done right now with This is fossil version 1.29 [5e47d555e4] 2014-04-30 16:35:21 UTC (note to developers: the `This is' in the version message should go away in my view -- at least it would allow more seamless copy+paste not disrupting the syntax of the text into which one copies ;-)) seems to verify this behaviour: 1. allow-symlinks off (default): a) if the symlinks are ADDed and checkedin, content is tracked across the links, i.e. as far as fossil is concerned everything acts as if the actual files where local to the repo: changes are noted, checkouts overwrite the actual files, not the symlinks. this seems in accord with the documentation and sure is useful for the purpose of tracking disseminated config files, e.g. b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. 2. allow-symlinks on: a) if the symlinks are ADDed and checkedin, content is NOT tracked across the links, i.e. modifications of the linked files are not noticed by fossil and cannot be checked in. the content of the checkedin links (e.g. what you see with `fossil cat') just is the path to the linked files. this seems in accord with the documentation b) if this repo is cloned and opened, links materialize using verbatim the path stored as content in the original repo. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. j. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - 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 -- 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
Re: [fossil-users] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. FWIW, i've had to struggle with that question in libfossil and i (currently) feel that the current behaviour follows the Principal of Least Surprise, in that it's consistent: no symlinks means no symlinks. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. Doesn't that mean that it supports both relative and absolute, and it's up to the user to choose which one he wants? There are use cases for both, IMO. (That said, i never was a big fan of having symlink support in fossil!) -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. FWIW, i've had to struggle with that question in libfossil and i (currently) feel that the current behaviour follows the Principal of Least Surprise, in that it's consistent: no symlinks means no symlinks. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. Doesn't that mean that it supports both relative and absolute, and it's up to the user to choose which one he wants? There are use cases for both, I agree. there is no best choice here. IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. -- 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
[fossil-users] minor libfossil milestone: TH1-style web page
Hi, all,
another libfossil minor milestone update:
while libfossil does not have an official script binding, it does have a
script binding, and i recently added support similar to embedding TH1 in
fossil pages. Here's a brief demo:
// ==
const CGI = api.cgi
const F = CGI.getFossilInstance()
const symTmplish = {tttmplish()/tt}
const template = END_OF_TEMPLATE
h1Welcome to % F.getProjectName() %/h1
div
This is a demonstration of using % symTmplish % to
create HTML templates with embedded th1ish code.
/div
? if(CGI.isLocalServer)IfLocalServer ?
divRunning in local server mode./div
? IfLocalServer ?
END_OF_TEMPLATE
const code = tmplish(template) // converts tmpl to script code
eval code // runs the script code
// ==
(The template can of course be read from a file or the db as well.)
Note the different tags: ? vs % - they have different semantics. ?
treats its contents as normal code and % evaluates the contents and
outputs the result in its place.
i'm working on integrating a demo of this into the libfossil CGI bits now.
Once that's done, it'll be a straightforward matter to add custom
html+script pages in a form very much like fossil's header/footer pages.
Happy Fossiling!
--
- 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] Tracking System Configuration Files - Best Practices
On Fri, May 9, 2014 at 9:02 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. That's what has always bothered me about the symlinks support: it's inherently non-portable, opens up tricky questions about how it should behave, and it might be handy for some (it's not generally needed - i've never used it, and never missed it). i do, however, agree that (like diff-follows-rename) if you have a need for it, it's a handy feature to have. -- - 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] Tracking System Configuration Files - Best Practices
On Fri, 09 May 2014 21:07:59 +0200, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:02 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 20:42:06 +0200, Stephan Beal sgb...@googlemail.com wrote: IMO. (That said, i never was a big fan of having symlink support in fossil!) well, the possibility to do that symlink trick for tracking config files all over the place might be handy for some. That's what has always bothered me about the symlinks support: it's inherently non-portable, opens up tricky questions about how it should behave, and it might be handy for some (it's not generally needed - again agreed. but it does no harm to have it (as long as one does not demand too much of it). i've never used it, and never missed it). i do, however, agree that (like diff-follows-rename) if you have a need for it, it's a handy feature to the diff-follows-rename problem seems in a different league for me. and the how it should behave issue has a clear answer in this case (at least there would be a clear majority vote ;-)) have. -- 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
Re: [fossil-users] minor libfossil milestone: TH1-style web page
On Fri, May 9, 2014 at 9:05 PM, Stephan Beal sgb...@googlemail.com wrote: i'm working on integrating a demo of this into the libfossil CGI bits now. http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/tmplish Once that's done, it'll be a straightforward matter to add custom html+script pages in a form very much like fossil's header/footer pages. The processTemplate() function shown in that page's source code: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/tmplish?showSrc=1 is basically the basis of such a functionality. -- - 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] RFC: primitive interactive add/rm/commit/diff
The $EDITOR idea is the first thing I thought of when reading the
Stephens initial post. Low barrier to entry, high effort/reward ratio.
A curses interface would be sexy (for some definition), but I'd say a
distant second as far as functional desirability.
-bch
On 5/7/14, Stephan Beal sgb...@googlemail.com wrote:
On Wed, May 7, 2014 at 10:56 PM, Michai Ramakers
m.ramak...@gmail.comwrote:
On 7 May 2014 22:51, Stephan Beal sgb...@googlemail.com wrote:
Maybe output the list and confirm for Y/n as it does now for certain
scenarios?
I don't think I understand... I meant undo/redo as per editor
features, within a single select-files-to-operate-on editor session.
('removed filename' as in, removed the actual name from the initial
list of chown files)
i misunderstood your point about undo/redo. i only meant show the user the
proposed list and allow them to confirm it, hopefully cutting down on the
need to undo in the fossil sense.
--
- 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
--
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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 process hanging on sync to remote server?
On Fri, May 9, 2014 at 2:25 AM, Stephan Beal sgb...@googlemail.com wrote:
Other than that, i can't comment: i've only seen such behaviour in 'ping'
on Solaris, where it can cause a backlog of cronjobs, which causes all
other jobs to queue up until you kill the pings, at which point _all_
queued jobs, since the queue limit was reached (several days in my case),
run in rapid succession!
(Changed subject line to reflect new topic)
Well, it's happened again.
This time I have the cron logging on. I get a mail message every time a
cronjob completes, and it's distinctly missing the one for the fossil sync
session that is hung. If I look at processes, I get this (notice it
executed at 9:05am, about 5 minutes after cronjob started and the entire
cronjob, if successful, only takes about 30 seconds):
$ uname -a
Darwin mycomp.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
$ ps auxww | grep fossil
USER PID %CPU %MEM VSZRSS TT STAT STARTED
TIME COMMAND
xxx 7619 0.0 0.2 2490036 29836 ?? S 9:05AM
0:13.80 /usr/local/bin/fossil commit --no-warnings -m Fri May 9 09:05:41
PDT 2014
The cronjob log for the cronjob executing AFTER the one that hung says this:
added 3 files, deleted 0 files
/usr/local/bin/fossil: database is locked: {REPLACE INTO
config(name,value,mtime)
VALUES('last-sync-url','my repo url',now())}
If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.
So, there is definitely a problem here. It doesn't happen all the time, but
enough that it occurs at least once a day.
___
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 process hanging on sync to remote server?
On Sat, May 10, 2014 at 12:40 AM, Gerald Gutierrez gerald.gutier...@gmail.com wrote: So, there is definitely a problem here. It doesn't happen all the time, but enough that it occurs at least once a day. i suspect it's OS specific. Richard syncs many repositories via cron on a regular basis (hourly for the sqlite mirrors, IIRC) and has never had/reported any problem with this, nor can i remember it coming up before on the list. :/ -- - 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] Fossil process hanging on sync to remote server?
Thus said Gerald Gutierrez on Fri, 09 May 2014 15:40:13 -0700: $ ps auxww | grep fossil USER PID %CPU %MEM VSZRSS TT STAT STARTED TIME COMMAND xxx 7619 0.0 0.2 2490036 29836 ?? S 9:05AM 0:13.80 /usr/local/bin/fossil commit --no-warnings -m Fri May 9 09:05:41 PDT 2014 Any chance you could attach gdb to this process and see what it's doing? Something like: gdb fossil -p 7619 ... (gdb) bt Thanks, Andy -- TAI64 timestamp: 4000536d6a2c ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
