Re: [fossil-users] Two trunks?
Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700: matt@xena:/tmp/testing$ fossil sync Sync with file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 4 received: 0 Server says: ** WARNING: a fork has occurred ** Server says: ** WARNING: a fork has occurred ** I assume you actually had 2 forks in the content that you were syncing? Would it be possible to detect and warn on update, status and push? push should behave the same as sync already. I'm not sure about update and status at the moment and just what that might involve. status will already show multiple children if you are on a node that has forked, however, if you are at the tip of a fork, that is a bit trickier to handle (I think). Also, update will complain if you are on a node that has forked and try to update without specifying which of the descendants you want to use. They may require more thought... Thanks, Andy -- TAI64 timestamp: 4000552602a5 ___ 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] Two trunks?
Thus said Ron W on Wed, 08 Apr 2015 22:27:57 -0400: 2. The presence of such a tag will serve as a reminder that the fork exists. If the goal is simply to make it easier to find forks, I don't think a tag is necessary for that. Fossil can already calculate the presence of forks, so maybe this is more about just extracting the data from Fossil and displaying it better? As for what currently works, there is /leaves which will show all open leaves. Maybe it could be extended to only show leaves that are forks? Or something else? Thanks, Andy -- TAI64 timestamp: 40005525f727 ___ 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] Two trunks?
On Wed, Apr 8, 2015 at 9:39 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700: matt@xena:/tmp/testing$ fossil sync Sync with file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 4 received: 0 Server says: ** WARNING: a fork has occurred ** Server says: ** WARNING: a fork has occurred ** I assume you actually had 2 forks in the content that you were syncing? One fork: fossil leaves (1) 2015-04-08 06:14:13 [0c744c0023] Borked (user: matt tags: trunk) (2) 2015-04-08 06:13:23 [9042062869] Fooblah (user: matt tags: trunk) Would it be possible to detect and warn on update, status and push? push should behave the same as sync already. Ah, I see. The check and message only happens when there is data synced. I'm not sure about update and status at the moment and just what that might involve. status will already show multiple children if you are on a node that has forked, however, if you are at the tip of a fork, that is a bit trickier to handle (I think). Also, update will complain if you are on a node that has forked and try to update without specifying which of the descendants you want to use. # Detection of multiple descendants only happens if the forked nodes are ahead in time # matt@xena:/tmp/testing$ fossil update Autosync: file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 267 received: 410 ip: === 2015-04-08 === 06:14:13 [0c744c0023] Borked (user: matt tags: trunk) 06:13:23 [9042062869] Fooblah (user: matt tags: trunk) +++ no more data (2) +++ Multiple descendants # If you are on the tip of one of the legs of the fork - no warning # matt@xena:/tmp/testing$ fossil co 0c74 Blahfoo matt@xena:/tmp/testing$ fossil update Autosync: file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 266 received: 412 ip: --- checkout: 0c744c002354132468b38afa0e128cd76a024e5e 2015-04-08 06:14:13 UTC leaf: open tags: trunk comment: Borked (user: matt) changes: None. Already up-to-date This last one is the worst scenario, the user has a potentially serious problem and *no* hint that it exists. They may require more thought... Thanks, Andy -- TAI64 timestamp: 4000552602a5 ___ 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] Two trunks?
On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700: What we are seeing is that forks happen due to simultaneous, partially overlapping, commits and that neither party involved in the two commits has any idea that a fork was committed. Perhaps this will help: http://www.fossil-scm.org/index.html/info/6b410f914ef5be53 Probably needs a review and possibly some testing, but it does seem to work for me: Thanks Andy, this looks like a serious move in the right direction (at least from my point of view). Here is what I see: # Sync with the server - yep, get WARNINGS, very nice! # matt@xena:/tmp/testing$ fossil sync Sync with file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 4 received: 0 Server says: ** WARNING: a fork has occurred ** Server says: ** WARNING: a fork has occurred ** Round-trips: 1 Artifacts sent: 4 received: 0 Sync done, sent: 618 received: 467 ip: # No messages on update # matt@xena:/tmp/testing$ fossil up Autosync: file:///home/matt/fossils/blah.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 267 received: 412 ip: --- checkout: 90420628697a12efe24747212c0ecdcb159706a3 2015-04-08 06:13:23 UTC leaf: open tags: trunk comment: Fooblah (user: matt) changes: None. Already up-to-date # No message on status # matt@xena:/tmp/testing$ fossil status repository: /tmp/testing/../blah.fossil local-root: /tmp/testing/ config-db:/home/matt/.fossil checkout: 90420628697a12efe24747212c0ecdcb159706a3 2015-04-08 06:13:23 UTC parent: 0b2ffb8eedfaaf7cb53a6461dd905411811b829c 2015-04-08 06:12:46 UTC leaf: open tags: trunk comment: Fooblah (user: matt) matt@xena:/tmp/testing$ Would it be possible to detect and warn on update, status and push? Thanks much for your effort on this. Matt -=- $ fossil set autosync autosync (local) off $ echo $RANDOM file $ fossil ci -m forked New_Version: cd32dadcd1658f99ead152583122df658c9ce458 $ fossil sync Sync with http://amb@remote:8080/ Round-trips: 1 Artifacts sent: 2 received: 0 Server says: ** WARNING: a fork has occurred ** Round-trips: 2 Artifacts sent: 2 received: 2 Sync done, sent: 3135 received: 3102 ip: 192.168.50.39 Thanks, Andy -- TAI64 timestamp: 40005525ceb8 ___ 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] Two trunks?
Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700: What we are seeing is that forks happen due to simultaneous, partially overlapping, commits and that neither party involved in the two commits has any idea that a fork was committed. Perhaps this will help: http://www.fossil-scm.org/index.html/info/6b410f914ef5be53 Probably needs a review and possibly some testing, but it does seem to work for me: $ fossil set autosync autosync (local) off $ echo $RANDOM file $ fossil ci -m forked New_Version: cd32dadcd1658f99ead152583122df658c9ce458 $ fossil sync Sync with http://amb@remote:8080/ Round-trips: 1 Artifacts sent: 2 received: 0 Server says: ** WARNING: a fork has occurred ** Round-trips: 2 Artifacts sent: 2 received: 2 Sync done, sent: 3135 received: 3102 ip: 192.168.50.39 Thanks, Andy -- TAI64 timestamp: 40005525ceb8 ___ 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] Two trunks?
Thus said Ron W on Wed, 08 Apr 2015 12:13:29 -0400: Ideally, this should never happen, but real working conditions might dictate making a commit during non-idea situations. Right, specifically, offline checkins and situations where autosync is entirely off. I think in these cases it makes sense for the server to send a non-fatal message indicating that it found a fork. Andy -- TAI64 timestamp: 40005525e212 ___ 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] Two trunks?
On Wed, Apr 8, 2015 at 8:57 PM, Andy Bradford amb-fos...@bradfords.org wrote: Perhaps this will help: http://www.fossil-scm.org/index.html/info/6b410f914ef5be53 Thanks. I would still like to see a special tag automatically added to a fork commit when one is detected. 2 reasons: 1. If there is an intermediate repo, the fork might not be detected until the commit is pushed/pulled further upstream. (Or if there is a cluster of Fossil servers not unlike how fossil-scm.org is redundantly hosted on 3 servers.) 2. The presence of such a tag will serve as a reminder that the fork exists. ___ 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] Symlink trouble
Andy Goth wrote: My andygoth-versioned-open branch (just checked in) addresses this problem and seems to fix the symlink issue. However, the Fossil coding style is rather alien to me, particularly the way it leaks memory on purpose, so the way I'm doing things may not be the best. Please have a look, and feel free to ask questions and make suggestions and further changes. I've made some tweaks on the branch. Here are the highlights: 1. By changing the return code checking for historical_version_of_file(), which apparently returns greater than zero on success. 2. Set noWarn based on the historical version of that file, if it exists. 3. Unrelated: Removed superfluous slash in the .fossil-settings path used by print_setting(). -- Joe Mistachkin ___ 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] Two trunks?
On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200: If they can happen when two people push to central repository one after another, then IMHO they should be blocked. Or at least there should be a possibility to enable/disable some kind of lock mechanism. I wonder just what this means? What part of the sync should be blocked? If I'm not mistaken, Fossil's design prefers to have the fork than not. I agree that good communication is essential, yet I also think the best way is to make software actively protecting us from making forks by accident. The software already warns users that a fork is imminent. They have the choice to ignore the warning, or not. If only this were true then this discussion would have been over long ago. Today I got to hear from a team that had a very near serious QA escape due to an undetected fork. In my opinion Fossil needs to either block a push that would result in a fork or on any and every operation loudly complain about any forks lingering in the timeline. Forks add little value but have a potentially high cost because they can be so confusing when they happen. To reiterate; An adequate solution would be on every checkout or update loudly inform the user that there is a fork in the timeline. A much better solution is to block a push that creates a fork and inform the user that they need to fix the fork and push again. Andy -- TAI64 timestamp: 400055248f46 ___ 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] Symlink trouble
I don't know if it's just me, or if there's a school of thought regarding this, but if this is a case of maintaining symlinks to publish as part of a distribution, I usually relegate their management to a script that will be part of a release generation process (with repository != release in mind). Are the problematic uses of symlinks different from that? On Apr 7, 2015 11:14 PM, Joe Mistachkin sql...@mistachkin.com wrote: Andy Goth wrote: My andygoth-versioned-open branch (just checked in) addresses this problem and seems to fix the symlink issue. However, the Fossil coding style is rather alien to me, particularly the way it leaks memory on purpose, so the way I'm doing things may not be the best. Please have a look, and feel free to ask questions and make suggestions and further changes. I've made some tweaks on the branch. Here are the highlights: 1. By changing the return code checking for historical_version_of_file(), which apparently returns greater than zero on success. 2. Set noWarn based on the historical version of that file, if it exists. 3. Unrelated: Removed superfluous slash in the .fossil-settings path used by print_setting(). -- Joe Mistachkin ___ 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] Two trunks?
On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote: On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford [1]amb-fos...@bradfords.org wrote: Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200: If they can happen when two people push to central repository one after another, then IMHO they should be blocked. Or at least there should be a possibility to enable/disable some kind of lock mechanism. I wonder just what this means? What part of the sync should be blocked? If I'm not mistaken, Fossil's design prefers to have the fork than not. I agree that good communication is essential, yet I also think the best way is to make software actively protecting us from making forks by accident. The software already warns users that a fork is imminent. They have the choice to ignore the warning, or not. If only this were true then this discussion would have been over long ago. Today I got to hear from a team that had a very near serious QA escape due to an undetected fork. In my opinion Fossil needs to either block a push that would result in a fork or on any and every operation loudly complain about any forks lingering in the timeline. What are you supposed to do when you try to push (or pull) and it get blocked because of a fork ? If there's a fork, it's too late. Fork's happens because autosync is off or because some commits was done while the remote repo was not accessible. When it's not the case, if you try to commit while you are not in sync with the remote repo, you get a warning that it might create a FORK and fossil give you chance to do a *up* before. Then you can figure out if there's some conflict, fix them if necessary, have a discussion with the other developer if necessary and commit again. Forks add little value but have a potentially high cost because they can be so confusing when they happen. To reiterate; An adequate solution would be on every checkout or update loudly inform the user that there is a fork in the timeline. A much better solution is to block a push that creates a fork and inform the user that they need to fix the fork and push again. Sometimes, Fork are inevitable. User should understand the concept of a distributed SCM. Fossil have a nice timeline graph that will show you the FORK clearly. And the CLI timeline command tell you that there's a FORK. (by adding *FORK* to the checkin entry): http://www.fossil-scm.org/index.html/info/62b10da0e1fe8ee5fa8b1af9aa35696079bb48ee?txt=1ln=1825+1829 May be it could help if fossil status or fossil change command could print a warning when the current checkin is part of a fork ? Regards, -- Martin 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] Two trunks?
On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote: Forks add little value but have a potentially high cost because they can be so confusing when they happen. I completely disagree on this. Forks add a lot of value and getting complains for every single action would be extremely annoying. To reiterate; An adequate solution would be on every checkout or update loudly inform the user that there is a fork in the timeline. Inacceptable for me. A much better solution is to block a push that creates a fork and inform the user that they need to fix the fork and push again. This is practically impossible by the nature of the sync protocol. Joerg ___ 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] Symlink trouble
On 4/8/2015 1:14 AM, Joe Mistachkin wrote: I've made some tweaks on the branch. Thank you, I appreciate it. I hesitated to do much more than move existing code around since I don't know how strong the stylistic preferences are. For example, one thing I wanted to do was treat pointers as booleans, e.g. if(pointer) rather than if(pointer!=0), but the precedent seemed to go against me. I'd like to do refactoring but really don't want to step on toes, especially regarding the memory leak policy: we're already relying on the ultimate garbage collector. Penultimate I mean, since power failure is the ultimate. :^) Here are the highlights: 1. By changing the return code checking for historical_version_of_file(), which apparently returns greater than zero on success. I'm pretty sure it returns its final argument if there's a failure, or panics on failure if its final argument is zero. So it should be sufficient to check if its return value doesn't match its final argument. However, it's not clear what it returns on success (you say greater than zero, but you also say apparently suggesting you don't know the full specification). In my tests I found it returned 1, so when its final argument was 1 it was impossible to distinguish between success and failure. So I went with -1 as the final argument. Sorry, not going to dig into the code just this second, so I don't recall what the names of the parameters. 2. Set noWarn based on the historical version of that file, if it exists. I thought about doing this but figured it didn't matter all that much for the open operation, but I will gladly accept your enhancement. 3. Unrelated: Removed superfluous slash in the .fossil-settings path used by print_setting(). Baseline issue, but again thanks. Also I recall you made it not try to update the cached value of allow-symlinks if there aren't any check-ins in the repository. This is fine, though now that we're forcing the initial empty check-in again, I'm not sure of the benefit. Maybe you're just dodging a NULL dereference in the case of a repository made with an older Fossil. Or maybe you could shun the initial empty check-in and rebuild, but the rebuild might make another initial empty check-in. Not sure, but still this is a good check to add. -- 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] Two trunks?
On Tue, Apr 7, 2015 at 10:14 PM, Andy Bradford amb-fos...@bradfords.org wrote: The software already warns users that a fork is imminent. They have the choice to ignore the warning, or not. Even when auto-sync is enabled and the upstream repo can be contacted, there is still a window where 2 (or more) commits can be made against the same parent. Ideally, this should never happen, but real working conditions might dictate making a commit during non-idea situations. ___ 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] autosync tickets
On Wed, Apr 8, 2015 at 5:24 PM, li...@ggp2.com wrote: Thanks for the response, and sorry for bugging you :) You're not bugging! i wish i could respond more fully to your posts, but my left hand simply can't do it for the time being, and typing any notable amount with only one hand is a real pain in the butt. I saw a couple references in the archives, but apparently didn't look quite hard enough to find posts explaining its pitfalls. I'll take another pass at it and see if it's something I'm capable of sorting out. Richard's answer pretty well sums up the related problems. -- - 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] autosync tickets
I have not looked at the source yet, but I think your explanation gives me a clear picture of the issues this would involve. This would need some sort of polling/persistent connection, and I'm not sure how well that meshes with Fossil's current web implementation. This is somewhat OT, but I've been tackling a similar problem that may be of interest down the road. I had a project that required a small FCGI C server to serve up pages. Rather than compiling templates myself, I decided that I could make life easier by pushing that onto 3rd party JS libraries. What I ended up doing was creating a small FCGI C server that only dealt in JSON. I served up a static page, and rendered everything using AngularJS. I dislike JS as much as the next guy. However, I still feel that keeping the C simple makes the server cleaner and more auditable and the web UI more capable. I've only used Fossil for a week so far so take it for what it's worth, but it seems like a nice long-term direction for the web UI to follow something like this. On Wed, Apr 08, 2015 at 11:19:37AM -0400, Richard Hipp wrote: This does not go against any core Fossil ideas. I just think it might be tricky to implement. The way the web interface works is that each HTTP request is handled by a separate process. In other words, a new fossil process is forked for each incoming HTTP request. That subprocess receives the HTTP request (in your case a ticket update) and then sends a reply back to the client, and then exits. The change you propose would be that the subprocess continues running after sending the HTTP reply and does a sync to its registered server (if it has one). Some potential problems: (1) How do you handle errors? The HTTP reply has already been sent. There is no way to notify the user that something went wrong. (2) If you try to deal with (1) by delaying the HTTP reply until after the sync takes place, then a slow sync will seriously delay the HTTP reply, which will make the interface seem to freeze form the point of view of the user. (3) Depending on how the subprocess was originally launched (CGI, SCGI, inetd, ssh, etc) the parent process might kill off the subprocess after receiving the HTTP reply, but before the subprocess has finished doing the sync. -- 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 ___ 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] autosync tickets
FWIW: The three Fossil self-hosting repositories stay in sync via a cron job running on each server. See https://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for additional information;. On 4/8/15, Richard Hipp d...@sqlite.org wrote: On 4/8/15, li...@ggp2.com li...@ggp2.com wrote: Is anyone interested in a diff with this functionality? I don't mind digging into the code, but I don't want to waste my time if it goes against a core idea of Fossil. I'd just like the option of using it with nothing external-facing other than SSH. This does not go against any core Fossil ideas. I just think it might be tricky to implement. The way the web interface works is that each HTTP request is handled by a separate process. In other words, a new fossil process is forked for each incoming HTTP request. That subprocess receives the HTTP request (in your case a ticket update) and then sends a reply back to the client, and then exits. The change you propose would be that the subprocess continues running after sending the HTTP reply and does a sync to its registered server (if it has one). Some potential problems: (1) How do you handle errors? The HTTP reply has already been sent. There is no way to notify the user that something went wrong. (2) If you try to deal with (1) by delaying the HTTP reply until after the sync takes place, then a slow sync will seriously delay the HTTP reply, which will make the interface seem to freeze form the point of view of the user. (3) Depending on how the subprocess was originally launched (CGI, SCGI, inetd, ssh, etc) the parent process might kill off the subprocess after receiving the HTTP reply, but before the subprocess has finished doing the sync. -- D. Richard Hipp d...@sqlite.org -- 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] Two trunks?
On Wed, Apr 8, 2015 at 2:19 AM, Matt Welland mattrwell...@gmail.com wrote: A much better solution is to block a push that creates a fork and inform the user that they need to fix the fork and push again. I disagree. Automatic shunning of an incoming commit by the receiving repo is anathema to Fossil's underlying promise to preserve history. There are real reasons that the existing shunning mechanism requires human intervention. Auto-adding a special tag to warn the (core) team will allow any (core) team member to take action in the even the original committer fails to (for whatever reason). If the commit is auto-shunned, then only the original committer's repo (and maybe an intermediate repo) will have the resources required to take action. ___ 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] Two trunks?
On Wed, Apr 08, 2015 at 06:55:17AM -0400, Martin Gagnon wrote: Sometimes, Fork are inevitable. User should understand the concept of a distributed SCM. Fossil have a nice timeline graph that will show you the FORK clearly. Also: fossil leaves --bybranch Joerg ___ 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] Two trunks?
On 4/8/15, Matt Welland mattrwell...@gmail.com wrote: Today I got to hear from a team that had a very near serious QA escape due to an undetected fork. Can you provide more detail on this incident so that I can better understand what Fossil can do to help prevent a recurrence? -- 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] autosync tickets
On Wed, Apr 08, 2015 at 05:15:10PM +0200, Stephan Beal wrote: i'm (still) on medical leave with a disabled hand, so won't say more than: there are a couple old posts in the list archives explaining various pitfalls involved with autosync of ticket changes. Short form: it introduces all sorts of new error conditions (primarily network-related) which currently don't exist. The same applies to changes made in the wiki. (That's not to say that it'd be impossible.) Thanks for the response, and sorry for bugging you :) I saw a couple references in the archives, but apparently didn't look quite hard enough to find posts explaining its pitfalls. I'll take another pass at it and see if it's something I'm capable of sorting out. ___ 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] autosync tickets
Is anyone interested in a diff with this functionality? I don't mind digging into the code, but I don't want to waste my time if it goes against a core idea of Fossil. I'd just like the option of using it with nothing external-facing other than SSH. On Sat, Apr 04, 2015 at 03:07:41PM +, li...@ggp2.com wrote: Hello all! I'm currently using fossil in a way which I think is somewhat nonstandard, but had a feature request that could potentially be useful to others as well. Rather than having a central, pseudo-public facing process, we are using fossil exclusively behind SSH. There is a shared account (fos...@server.com) with PKI, and we all have default user accounts to track changes (fossil user default xxx). The reason for this is that the codebase is sensitive, and we prefer to keep services behind ipsec/ssh when possible. Fossil supports ssh pretty well, so we determined this is easier for some of our non-technical users to get up and running. For developers, this process works great. Autosync performs flawlessly, and we go about our business. However when filing tickets through the UI, a fossil sync seems to be mandatory. My request is that tickets also get pushed via an autosync function on changes. Also, I was pleasantly surprised to find that fossil has a statically-linked flavor on OpenBSD, which makes it trivial to chroot via ssh. We have had nightmares in the past trying to do this with git (why does it need /dev/random access!?, and no, git-shell doesn't count). Thanks everyone who helped make fossil possible. We have quite enjoyed it thus far :) ___ 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] Two trunks?
On Wed, Apr 8, 2015 at 6:16 AM, Richard Hipp d...@sqlite.org wrote: On 4/8/15, Matt Welland mattrwell...@gmail.com wrote: Today I got to hear from a team that had a very near serious QA escape due to an undetected fork. Can you provide more detail on this incident so that I can better understand what Fossil can do to help prevent a recurrence? The problem: What we are seeing is that forks happen due to simultaneous, partially overlapping, commits and that neither party involved in the two commits has any idea that a fork was committed. Fossil sometimes doesn't give the multiple descendents message and so a fork can go undetected in the timeline. In the case in question a critical change was committed but it ended up being isolated on the tip of a fork and was lost in the hundreds of subsequent commits. Luckily a QA check caught the issue but only very late in the game and there was quite a scramble to recover. Needless to say this upset quite a few people. The picture below is of a fork that happened a few days ago in one of our busiest repos where we are seeing as much as several forks a week. Most devs using that repo are now being vigilant and fixing the forks as they happen but this is an annoying distraction from getting real work done. BTW, we've had a few cases of committing of a fork fix create another fork. [image: Inline image 1] A case of fixing a fork creating a new fork: [image: Inline image 2] Possible solutions: 1. Aggressive notification of existing forks on running any of; update, sync, pull, push, commit, checkout, or status. 2. Improved on sync detection during commit (the git model of blocking forks or similar). 3. Add a setting controlled server mode where the commit process gets a server-side lock to serialize commits. -- 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 ___ 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] autosync tickets
On Wed, Apr 8, 2015 at 5:02 PM, li...@ggp2.com wrote: Is anyone interested in a diff with this functionality? I don't mind digging into the code, but I don't want to waste my time if it goes against a core idea of Fossil. I'd just like the option of using it with nothing external-facing other than SSH. i'm (still) on medical leave with a disabled hand, so won't say more than: there are a couple old posts in the list archives explaining various pitfalls involved with autosync of ticket changes. Short form: it introduces all sorts of new error conditions (primarily network-related) which currently don't exist. The same applies to changes made in the wiki. (That's not to say that it'd be impossible.) For developers, this process works great. Autosync performs flawlessly, and we go about our business. However when filing tickets through the UI, a fossil sync seems to be mandatory. My request is that tickets also get pushed via an autosync function on changes. -- - 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] autosync tickets
On 4/8/15, li...@ggp2.com li...@ggp2.com wrote: Is anyone interested in a diff with this functionality? I don't mind digging into the code, but I don't want to waste my time if it goes against a core idea of Fossil. I'd just like the option of using it with nothing external-facing other than SSH. This does not go against any core Fossil ideas. I just think it might be tricky to implement. The way the web interface works is that each HTTP request is handled by a separate process. In other words, a new fossil process is forked for each incoming HTTP request. That subprocess receives the HTTP request (in your case a ticket update) and then sends a reply back to the client, and then exits. The change you propose would be that the subprocess continues running after sending the HTTP reply and does a sync to its registered server (if it has one). Some potential problems: (1) How do you handle errors? The HTTP reply has already been sent. There is no way to notify the user that something went wrong. (2) If you try to deal with (1) by delaying the HTTP reply until after the sync takes place, then a slow sync will seriously delay the HTTP reply, which will make the interface seem to freeze form the point of view of the user. (3) Depending on how the subprocess was originally launched (CGI, SCGI, inetd, ssh, etc) the parent process might kill off the subprocess after receiving the HTTP reply, but before the subprocess has finished doing the sync. -- 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] Symlink trouble
On Wed, Apr 8, 2015 at 12:17 PM, Ron W ronw.m...@gmail.com wrote: On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison sc...@casaderobison.com wrote: Or whatever your team dictates. :) In our case, we are required to follow industry guidelines, except where compelling technical issues require a deviation. And such deviations must be documented. Also, use of NULL is considered more indicative of the intent, therefore, more readable. I agree the rationale for using it is valid, and particularly the idea that if(p!=NULL) works whether or not your environment is standards compliant. So I'm not saying you're wrong to use that particular construct, just observing that 0 is not wrong in a standards compliant compiler as it will do the right thing. There are many ways to do the same task. Each has its pros cons. I live mainly in C++ land, so I avoid NULL. I do like the nullptr constant of C++11 and later, since there is no way for it to be accidentally converted to an integer. I happen to like the if(p) syntax as succinct terminology for if(p is valid) (or if(!p) for if(p is not valid)), though. None of them are perfect, and good reasons can be given for any of them IMO. Recently I've been working in C++ code where the programmer liked to use if(TRUE==someBOOL) which I hate on so many levels: 1. If you have to use BOOL due to the Windows API, fine, but limit your use of BOOL to that, use bool the rest of the time. 1a. Same for TRUE FALSE vs true false. 2. I dislike Yoda conditionals of the form constant op variable. I realize there are reasons why people use them, to avoid accidental assignment in a conditional, but the modern compilers I work with diagnose these problems for me so that I can have clearer code without the risk of accidental assignment. 3. If someBOOL returns a true value that happens to not be exactly equal to 1 (the definition of TRUE) then the statement will fail when perhaps maybe it shouldn't have? 3a. If you are really depending on the value to be 0 1 vs zero not zero, don't call it a BOOL. 4. I dislike someBOOL op constant statements. Just say someBOOL or !someBOOL. But I digress. Sorry. Carry on. 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] autosync tickets
On Wed, Apr 8, 2015 at 5:48 PM, li...@ggp2.com wrote: I dislike JS as much as the next guy. However, I still feel that keeping the C simple makes the server cleaner and more auditable and the web UI more capable. I've only used Fossil for a week so far so take it for what it's worth, but it seems like a nice long-term direction for the web UI to follow something like this. Some examples of this: http://fossil.wanderinghorse.net/wikis/ those wikis all use fossil's JSON API to manage wiki pages stored in Google Code format, rendered on the client using JS. -- - 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] Symlink trouble
On 4/8/2015 1:33 AM, bch wrote: I don't know if it's just me, or if there's a school of thought regarding this, but if this is a case of maintaining symlinks to publish as part of a distribution, I usually relegate their management to a script that will be part of a release generation process (with repository != release in mind). Are the problematic uses of symlinks different from that? I prefer your approach, however I did not get to pick in this instance since I am trying to import an existing repository from ClearCase, actually a snapshot, and it uses symlinks. Furthermore I think some of the symlinks are used stupidly, but once again I don't get to pick. -- 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] Symlink trouble
(email to reporter of problem several years ago, copying list so discussion can continue here) I made a fix to Fossil opening a repository containing symlinks. It's currently on a branch. For details, see this thread: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20112.html And here's code: http://www.fossil-scm.org/index.html/timeline?r=andygoth-versioned-open -- 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] Two trunks?
On Wed, Apr 8, 2015 at 6:55 AM, Martin Gagnon eme...@gmail.com wrote: Fossil have a nice timeline graph that will show you the FORK clearly. And the CLI timeline command tell you that there's a FORK. (by adding *FORK* to the checkin entry): I had not encountered this. Nor the would fork warning when doing a commit. Obviously my teammates and I have been following our procedures well enough to successfully avoid forks. Question: Does the timeline webpage similarly highlight forks? Still, I think that auto-adding a special tag to a fork-commit, when detected, will reduce the cost of emitting warnings to the developers. (And yes, a configuration option to enable/disable these warnings would be appropriate.) ___ 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] Symlink trouble
On 4/8/15, Andy Goth andrew.m.g...@gmail.com wrote: On 4/8/2015 1:33 AM, bch wrote: I don't know if it's just me, or if there's a school of thought regarding this, but if this is a case of maintaining symlinks to publish as part of a distribution, I usually relegate their management to a script that will be part of a release generation process (with repository != release in mind). Are the problematic uses of symlinks different from that? I prefer your approach, however I did not get to pick in this instance since I am trying to import an existing repository from ClearCase, actually a snapshot, and it uses symlinks. Furthermore I think some of the symlinks are used stupidly, but once again I don't get to pick. 1) It's nice to hear that others are like this 2) That you imported a (in our opinion) poorly-laid-out project is a good point to remember -- it's not always greenfield repositories that we work with. Thanks for the reminder. Cheers, -- 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 ___ 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] Symlink trouble
On Wed, Apr 8, 2015 at 11:13 AM, Ron W ronw.m...@gmail.com wrote: FWIW, the coding rules I work under require us to write if(pointer!=NULL) because the invalid pointer is a compiler-dependent value. I've actually used a compiler where NULL was not 0. Instead it was 0x. Presumably this was partially because this the address of the last byte of the reset vector (as well as being the highest addressable byte) and because the erased/unwritten value of a byte of Flash ROM is 0xFF. (At for every Flash ROM device I've ever (directly) used.) For any standard compliant C compiler, the zero comparison is legal regardless of the bit pattern representation of a null point on the given platform. The 1990 ISO standard (virtually identical to the 1989 ANSI standard) includes the following (from section 6.2.2.3 Pointers): An integral constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer. the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Two null pointers, converted through possibly different sequences of casts to pointer types, shall compare equal. So even though the internal bit pattern representation might not be zero, the standard guarantees zero can be used as the null pointer constant value. C++ changes the rules slightly, in that void* types won't auto cast like in C, so only 0 was a valid null pointer constant (prior to the introduction of nullptr). I don't include NULL as a null pointer constant as it is only a macro that expands to a null pointer constant. So unless one is dealing with a non-standard compiler, if(p) and if(p!=0) and if(p!=NULL) are all semantically identically. One could argue that if(p!=NULL) is the safest of the available options, as it would work on all compilers that define NULL. If you're dealing with a non-standard compiler (which would include pre-standard compilers), use what you have to use for the platform. Otherwise use whatever you feel most comfortable with. Or whatever your team dictates. :) -- 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] Symlink trouble
On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison sc...@casaderobison.com wrote: Or whatever your team dictates. :) In our case, we are required to follow industry guidelines, except where compelling technical issues require a deviation. And such deviations must be documented. Also, use of NULL is considered more indicative of the intent, therefore, more readable. ___ 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] Symlink trouble
Here is another problem with symlinks: Last login: Tue Apr 7 20:11:50 on ttys004 : ~ ; cd /tmp : /tmp ; fs init foo.fossil project-id: d24564a4337e8c50f77a20ee355e2f76a9b84b78 server-id: aa025469a22046732337b7fa075c7c4e85f45c0a admin-user: dmason (initial password is d5a283) : /tmp ; cd foo : /tmp/foo ; fs open ../foo.fossil project-name: unnamed repository: /private/tmp/foo/../foo.fossil local-root: /private/tmp/foo/ config-db:/Users/dmason/.fossil project-code: d24564a4337e8c50f77a20ee355e2f76a9b84b78 checkins: 0 : /tmp/foo ; mkdir foo : /tmp/foo ; touch foo/bar foo/blat : /tmp/foo ; fs add foo ADDED foo/bar ADDED foo/blat : /tmp/foo ; fs ci -m foo New_Version: d01c99b9316832532f4acdf7b1afb06e9c071e43 : /tmp/foo ; mv foo ../foob : /tmp/foo ; ln -s ../foob foo : /tmp/foo ; fs stat repository: /private/tmp/foo/../foo.fossil local-root: /private/tmp/foo/ config-db:/Users/dmason/.fossil checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41 UTC leaf: open tags: trunk comment: foo (user: dmason) : /tmp/foo ; ls -l total 8 lrwxr-xr-x 1 dmason wheel 7 8 Apr 15:21 foo - ../foob : /tmp/foo ; fs stat repository: /private/tmp/foo/../foo.fossil local-root: /private/tmp/foo/ config-db:/Users/dmason/.fossil checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41 UTC leaf: open tags: trunk comment: foo (user: dmason) EDITED foo/bar : /tmp/foo ; As you can see if a directory is replaced with a link to a directory outside of the working directory it doesn't recognize it. And it thinks that files in that directory (which is outside the WD) are still to be tracked. This bit me when I was moving several projects into fossil, and I recognized a common subdirectory (TeX to be exact), so I did something like the above. Took a while to figure out what went wrong and to fix it. Same problem if you move the directory into a nested working directory. Continuing from the previous example (hence the first couple of commands to revert to the original situation): : /tmp/foo ; rm foo;mv ../foob foo : /tmp/foo ; cd .. : /tmp ; fossil init bar.fossil project-id: a52834ead71c0589bfe88c2874c45fb05818d3d4 server-id: 9b79fad662c144ea54dca3ab3f5b5fc522030c0d admin-user: dmason (initial password is d4f221) : /tmp ; cd foo : /tmp/foo ; fs stat repository: /private/tmp/foo/../foo.fossil local-root: /private/tmp/foo/ config-db:/Users/dmason/.fossil checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41 UTC leaf: open tags: trunk comment: foo (user: dmason) EDITED foo/bar : /tmp/foo ; mkdir bar : /tmp/foo ; cd bar : /tmp/foo/bar ; fs open --nested ../../bar.fossil project-name: unnamed repository: /private/tmp/foo/bar/../../bar.fossil local-root: /private/tmp/foo/bar/ config-db:/Users/dmason/.fossil project-code: a52834ead71c0589bfe88c2874c45fb05818d3d4 checkins: 0 : /tmp/foo/bar ; cd .. : /tmp/foo ; ls bar foo : /tmp/foo ; mv foo bar : /tmp/foo ; ln -s bar/foo . : /tmp/foo ; fs stat repository: /private/tmp/foo/../foo.fossil local-root: /private/tmp/foo/ config-db:/Users/dmason/.fossil checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41 UTC leaf: open tags: trunk comment: foo (user: dmason) EDITED foo/bar : /tmp/foo ; cd bar : /tmp/foo/bar ; fs ext foo/bar foo/blat : /tmp/foo/bar ; So now we have the same files in 2 repositories. Not the expected (nor, I suspect, intended) behaviour. Moving and symlinking *within* a repo seems to work properly. ___ 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] Symlink trouble
What Scott says, abbreviated from the C FAQ: http://c-faq.com/null/ptrtest.html FWIW, I always use if(p) to verify a pointer is valid. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
