Re: [fossil-users] Is it advisable to put a .fossil repository on Dropbox?
On Wed, May 7, 2014 at 8:15 AM, Stephan Beal sgb...@googlemail.com wrote: The lock you're seeing is almost certainly your dropbox and should be harmless. sqlite locks the db as needed, and Dropbox should recognize that and not touch the file as long as it's locked (but posix locks are advisory locks, not required to be honored!). Actually, I may have tracked it down now. It turns out to be a hung fossil process. I no longer think it's due to Dropbox. I stopped using Dropbox and started syncing to a private remote server. I use cron to do a commit sync every hour, and fossil is run from a bash script via cron. It seems that after a couple of successful runs, the fossil process starts to hang. I get a bunch of them when I do ps aux, and when I kill them, the commits start working again. I've seen references to fossil hanging before (but can't find it now). Is this a known issue? ___ 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] Merging two leaves not on the same graph?
2014-05-01 12:28 GMT+02:00 Stephan Beal sgb...@googlemail.com: No objections, but some comments... - libfossil has been using repos without an initial commit since last summer. AFAIK there are no more open assertions related to that, but every now and then i'll run into a case which expects an RID0 and might (until the first commit) see a 0. It can always be repaired when this happens, but triggering it can be cumbersome to do (i.e. there might eventually be some (now-invalid) assertions which eventually need to be patched for this). In fossil, all of those (now-invalid) assertions have been fixed, I did extensive tests to assure that. Actually, fossil cannot do very much when dealing with an empty repository. Merging??? against what branch - Whether or not it should default to having no initial empty commit is debatable, but i can't argue strongly either way. i tend to think it should do one by default, solely for historical compatibility, but OTOH it's not a critical functionality (just an immediately-visible change for long-time users). I did additional tests to assure that historical compatibility is not affected. Three scenario's: - When people use an already exisiting repository, the initial empty commit is already there. Nothing to worry about. - When creating a new repository, no initial commit is there. But as soon as the first commit goes in, everything is exactly as before. Basic operations like add/remove/addremove/commit work fine even without the initial commit, other operations make no sense yet. 2014-05-01 21:42 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Well, I went ahead, and merged the proposed change to trunk. This means that the initial empty commit is no longer created by surprise, but it's only a change of the default behavior: When specifying --date-override, everything works as before. So I don't think existing behavior of importing and/or using already existing repositories will be affected in any way. Thanks for all remarks. But if anything unexpected happens which I didn't foresee, please report. 2014-05-01 22:21 GMT+02:00 B Harder brad.har...@gmail.com: I think that initial empty commits went in at my request. Iirc, so I could have related (but not inheriting from trunk) vendor branches. Can we review/discuss before axing? I didn't need an axe for this work, the possibility to create an initial empty commit is still there. But if during the timeline towards fossil 1.29 something unexpected is discovered: It's only a one-line code change easy to revert! Happy testing. 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] Merging two leaves not on the same graph?
Thus said Jan Nijtmans on Thu, 08 May 2014 12:29:27 +0200: Well, I went ahead, and merged the proposed change to trunk. This means that the initial empty commit is no longer created by surprise, but it's only a change of the default behavior: When specifying --date-override, everything works as before. So I don't think existing behavior of importing and/or using already existing repositories will be affected in any way. Seems like a reasonable thing to do. I wanted to test it before you actually merged, but I've been busy on the per-round-trip-commit branch and haven't had any spare time. I think having an empty repository makes sense. Andy -- TAI64 timestamp: 4000536b9840 ___ 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 Thu, May 8, 2014 at 8:43 AM, Gerald Gutierrez gerald.gutier...@gmail.com wrote: I stopped using Dropbox and started syncing to a private remote server. I use cron to do a commit sync every hour, and fossil is run from a bash script via cron. It seems that after a couple of successful runs, the fossil process starts to hang. I get a bunch of them when I do ps aux, and when I kill them, the commits start working again. I've seen references to fossil hanging before (but can't find it now). Is this a known issue? You're not by chance on Solaris, are you? That's the only platform i've see which likes to occasionally hang network traffic. (Long story there, but it's quite funny one if it wasn't your system which was affected by it. ;) -- - 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] Merging two leaves not on the same graph?
On Thu, May 8, 2014 at 12:29 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: tests to assure that. Actually, fossil cannot do very much when dealing with an empty repository. Merging??? against what branch It's funny you say that because in libfossil i've had to go back and reexamine my 0 semantics, and let them be legal (empty repo) in some cases, but stand for the current checkout in others (where 0 otherwise makes no sense). Negatives are always invalid, but 0 has a few uses. In some cases, there's a small bit of extra handling for rid 0, but nothing tragic. I did additional tests to assure that historical compatibility is not affected. Three scenario's: - When people use an already exisiting repository, the initial empty commit is already there. Nothing to worry about. - When creating a new repository, no initial commit is there. But as soon as the first commit goes in, everything is exactly as before. Basic operations like add/remove/addremove/commit work fine even without the initial commit, other operations make no sense yet. i agree: i also don't expect any problems if this is made the default (other than potential initial long-time user confusion, which they will quickly get over when they realize they can finally write the first commit message in their native language ;). I didn't need an axe for this work, the possibility to create an initial empty commit is still there. But if during the timeline towards fossil 1.29 something unexpected is discovered: It's only a one-line code change easy to revert! Sounds like a plan :) -- - 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] Trouble when making new repository
With today's version of Fossil, I can't add anything to any freshly-created repositories. andy|slack|14:25|0|~/foo $ f version This is fossil version 1.29 [3ef59c357c] 2014-05-08 10:25:32 UTC andy|slack|14:23|0|~ $ mkdir foo andy|slack|14:23|0|~ $ cd foo andy|slack|14:23|0|~/foo $ f new foo.fossil project-id: 596092ff05ecf1b03730e82affc498ebd662c3d2 server-id: 59864d643d5ca6b3b7a52a4a12da6eea43288c66 admin-user: andy (initial password is 463e8a) andy|slack|14:23|0|~/foo $ f open foo.fossil project-name: unnamed repository: /home/andy/foo/foo.fossil local-root: /home/andy/foo/ config-db:/home/andy/.fossil project-code: 596092ff05ecf1b03730e82affc498ebd662c3d2 checkins: 0 andy|slack|14:23|0|~/foo $ echo hello file andy|slack|14:24|0|~/foo $ f add file ADDED file andy|slack|14:24|0|~/foo $ f commit -m test New_Version: 3a4aff36993d288a6dfb7b5c968c3af613c25547 ERROR: [file] is 6 bytes on disk but 0 in the repository NOTICE: Repository version of [file] stored in [file-22ef63d951e2b17d] working checkout does not match what would have ended up in the repository: fbde3b8287dec3dcf10d3327eac39581 versus d41d8cd98f00b204e9800998ecf8427e -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Trouble when making new repository
On Thu, May 8, 2014 at 9:26 PM, Andy Goth andrew.m.g...@gmail.com wrote: With today's version of Fossil, I can't add anything to any freshly-created repositories. andy|slack|14:25|0|~/foo May i say: that's a a pretty crazy prompt you have there! $ f version This is fossil version 1.29 [3ef59c357c] 2014-05-08 10:25:32 UTC Confirmed: [stephan@host:~/cvs/fossil/X/x]$ f com -m test New_Version: 305f0b139456d93bacde29652503ac4ba7e11374 ERROR: [file] is 6 bytes on disk but 0 in the repository NOTICE: Repository version of [file] stored in [file-4391a7c336e76a78] working checkout does not match what would have ended up in the repository: fbde3b8287dec3dcf10d3327eac39581 versus d41d8cd98f00b204e9800998ecf8427e Looking into it now, but suspect that Jan or Andy B might have a more immediate suspicion, seeing as they've been around that code lately. -- - 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 Thu, May 8, 2014 at 9:40 PM, Stephan Beal sgb...@googlemail.com wrote: Confirmed: [stephan@host:~/cvs/fossil/X/x]$ f com -m test Seems to be caused by an ignored return value check which assumes true. Should have a fix soon. -- - 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 5/8/2014 2:40 PM, Stephan Beal wrote: On Thu, May 8, 2014 at 9:26 PM, Andy Goth wrote: andy|slack|14:25|0|~/foo May i say: that's a a pretty crazy prompt you have there! Username, hostname, time, background job count, current directory, (newline), dollar sign or pound sign depending on UID. Gives me a full line with which to type and plenty of space to see my directory since I'm working on a project which was cursed with stupidly deep nesting. You should see the colors I'm using, haha! Looking into it now, but suspect that Jan or Andy B might have a more immediate suspicion, seeing as they've been around that code lately. I think [3ef59c357c] is the culprit. In fact, the reason I made a new repository was to test that exact commit. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Trouble when making new repository
On Thu, May 8, 2014 at 9:46 PM, Andy Goth andrew.m.g...@gmail.com wrote: Looking into it now, but suspect that Jan or Andy B might have a more immediate suspicion, seeing as they've been around that code lately. I think [3ef59c357c] is the culprit. In fact, the reason I made a new repository was to test that exact commit. The return value check only solves half the issue for me, i'm still seeing the the R-card calc mismatch, but do not yet know what the manifest looks like, so don't yet know where to look next. i'll start with your suggestion. -- - 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 Thu, May 8, 2014 at 9:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, May 8, 2014 at 9:46 PM, Andy Goth andrew.m.g...@gmail.com wrote: Looking into it now, but suspect that Jan or Andy B might have a more immediate suspicion, seeing as they've been around that code lately. I think [3ef59c357c] is the culprit. In fact, the reason I made a new repository was to test that exact commit. The return value check only solves half the issue for me, i'm still seeing the the R-card calc mismatch, but do not yet know what the manifest looks like, so don't yet know where to look next. i'll start with your suggestion. http://www.fossil-scm.org/index.html/vdiff?from=f2c8b4f375b8ab00to=3ef59c357ccebfe4sbs=1 it could well be a side-effect of that. Jan's right in that an rid of 0 should fundamentally be OK (libfossil was the initial test ground for that), but i think this was one of the unexpected side effects based on assumptions that RIDs are generally positive. Going back a version does indeed fix it. i'll roll back that commit, as soon as i figure out what the proper approach is to rolling back a commit. (Suggestions welcomed ;) [stephan@host:~/cvs/fossil/X/x]$ f new ../x.fsl; f open ../x.fsl project-id: 966cd0afd6a451971081b06ab808ef899bc6750a server-id: 339ccfc900c90747a64f8862a1ab0c1d623c85b0 admin-user: stephan (initial password is 3e0e99) cproject-name: unnamed repository: /home/stephan/cvs/fossil/X/x/../x.fsl local-root: /home/stephan/cvs/fossil/X/x/ config-db:/home/stephan/.fossil project-code: 966cd0afd6a451971081b06ab808ef899bc6750a checkout: 7db72818c4eb60a7f6b7bf2e48e74fafe14ee592 2014-05-08 19:55:46 UTC leaf: open tags: trunk comment: initial empty check-in (user: stephan) checkins: 1 [stephan@host:~/cvs/fossil/X/x]$ cat file hello [stephan@host:~/cvs/fossil/X/x]$ f add file ADDED file [stephan@host:~/cvs/fossil/X/x]$ f com -m test New_Version: 81d40e387919c968fe939a22a58ae8e854730a2c [stephan@host:~/cvs/fossil/X/x]$ f version This is fossil version 1.29 [77f53423ae] 2014-05-02 08:23:06 UTC -- - 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 Thu, May 8, 2014 at 9:57 PM, Stephan Beal sgb...@googlemail.com wrote: Going back a version does indeed fix it. i'll roll back that commit, as soon as i figure out what the proper approach is to rolling back a commit. (Suggestions welcomed ;) i always forget about move to new branch... Richard just moved it. Trunk works again. -- - 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] can fossil try harder on sync failure?
On Wed, May 7, 2014 at 12:59 AM, Andy Bradford amb-sendok-1402034378.gfecjnjggaibliman...@bradfords.org wrote: Thus said Rich Neswold on Wed, 16 Apr 2014 15:40:23 -0500: It would be nice if fossil would break the pull into smaller transactions which contain valid timeline commits so, if there's a database timeout, the next time I try to pull it can continue where it left off. I've been working a bit on implementing a per round-trip commit as suggested by Richard and it does commit in smaller transactions, though not all of them will be valid timeline commits: http://www.fossil-scm.org/index.html/info/d02f144d708e89299ae28a2b99eeb829a6799c5f Basically it does a commit each round trip and defers execution of hooks until the last round-trip happens. I'm not convinced if this is correct behavior---specifically, should it execute them even if there is an error during sync? I was thinking of attacking the problem a little higher up (since I'm way too nervous touching the low-level stuff): The idea is to add a command line option to indicate that you want a partial sync (e.g. --pull-limit 1). This option would only be honored for pulls -- if pushes are occurring, ignore the option because it complicates finding an interruption point for both pulls and pushes. Process cards as they come in and decrement the counter when a card that represents a checkpoint has been completed. When the counter is zero, we break the outer loop (set 'go' to 0): https://www.fossil-scm.org/index.html/artifact/dace4194506b2ea732ca27f68300b156816e403a?ln=1482 When the loop is exited, all the database closing hooks are done and we simply haven't transferred all the history. Issuing another pull will transfer N more artifacts. Eventually, the full history will be transferred. Of course, if the command line option isn't given, then process cards until the sender says they're done sending. -- Rich ___ 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
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. On May 8, 2014 1:03 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, May 8, 2014 at 9:57 PM, Stephan Beal sgb...@googlemail.comwrote: Going back a version does indeed fix it. i'll roll back that commit, as soon as i figure out what the proper approach is to rolling back a commit. (Suggestions welcomed ;) i always forget about move to new branch... Richard just moved it. Trunk works again. -- - 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 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?
Thus said Rich Neswold on Thu, 08 May 2014 15:18:43 -0500: I was thinking of attacking the problem a little higher up (since I'm way too nervous touching the low-level stuff): So did I initially, though my first thought was simply to have autosync try multiple times when failing (in the autosync-tries branch). Then Richard mentioned that it could be done by simply committing more frequently, and so I focused on that approach. I think it actually works quite well and I even added some protections to handle corner cases where a user might receive a partial sync, but then attempt to update/merge to a checkin that is not complete: http://www.fossil-scm.org/index.html/info/f2adddfe601d33c98974f9c645e8aceb9622aa86 One is free to force the update/merge if one desires with the --force-missing option. It would be interesting to get some actual testing with the repository that was mentioned would rollback after a 1GB sync to see how it does. Make sure it's a spare clone repository just in case, though I haven't seen any problems in my testing. Thoughts? Andy -- TAI64 timestamp: 4000536c3088 ___ 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 2014-05-08 16:18, Rich Neswold wrote: On Wed, May 7, 2014 at 12:59 AM, Andy Bradford amb-sendok-1402034378.gfecjnjggaibliman...@bradfords.org wrote: Thus said Rich Neswold on Wed, 16 Apr 2014 15:40:23 -0500: It would be nice if fossil would break the pull into smaller transactions which contain valid timeline commits so, if there's a database timeout, the next time I try to pull it can continue where it left off. Does SQLite support nested transactions? If so, that would seem to be worth considering. -- Thanks, DougF (KG4LMZ) ___ 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?
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 Andy -- TAI64 timestamp: 4000536c46e4 ___ 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 Thu, May 8, 2014 at 10:08 PM, Andy Bradford amb-fos...@bradfords.org wrote: 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 I don't think nested transactions would help the problem I'm hoping will get solved. -- Rich ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
