[fossil-users] weird: sections lost during merge
Hi, all, Dave noticed a weird thing today while trying to do what appeared to be a routine merge... here's the timeline of reference: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/timeline?c=2014-10-27 During that time Dave merged trunk into his branch and everything is great. He then makes one more commit to his branch before trying to merge his branch to the trunk. He noticed, however, that while there were no conflicts, several bits from one of the recent trunk commits were missing, specifically much (but not all) of this commit: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/898c0acbff9c365b34539a5d86d7e6dae57727e6 (the 2nd commit made on the 27th) He reported it to me, and locally i get the same thing: a clean merge of only a few files, but notable chunks of 898c0ac are missing. Using gdiff i was able to piece it back together with little effort, but we're both very puzzled as to why fossil chose to remove those pieces during the merge. To reproduce this, clone that repo: fossil clone http://fossil.wanderinghorse.net/repos/libfossil/index.cgi libfossil.fsl open it somewhere, then: - checkout version 6c18a25f11 (last commit from the 27th) - merge 6e12a39c1ae3 - diff -tk that. The majority of the red blocks on the left (in fsl_cx.c) were added by 898c0ac and not removed since then. We're not yet claiming this is a bug, but we'd like to understand what happened here. i've seen such things in svn many times, but so far never in fossil. Disclaimer: though we're hacking on libfossil, this was done using fossil(1). Any insights? -- - 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] weird: sections lost during merge
On Tue, Oct 28, 2014 at 5:27 AM, Stephan Beal sgb...@googlemail.com wrote: During that time Dave merged trunk into his branch and everything is great. He then makes one more commit to his branch before trying to merge his branch to the trunk. He noticed, however, that while there were no conflicts, several bits from one of the recent trunk commits were missing, specifically much (but not all) of this commit: When the merge from trunk into dave occurred (check-in c2d7402366) there were merge conflicts on the fsl_cx.c file. (You can see this by doing fossil up 81f67b; fossil merge 6c18a25;) These merge conflicts were manually resolved, and it is at that step that the lines went messing from fsl_cx.c. The missing lines seem to have been added to trunk by check-in 889657e03c. They never existed in the dave branch. When trunk was merge into dave at c2d7404366 those lines were removed again (manually, as part of the merge conflict resolution). Then the removal was transferred back into trunk by the merge into trunk at 61233f6026. Fossil seems to have done everything correctly, as far as I can tell. -- 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] weird: sections lost during merge
Being there, I just found by chance a typo which is probably harmless on
libfossil..
(diff against: 61233f6026)
Index: src/fsl.c
==
--- src/fsl.c
+++ src/fsl.c
@@ -107,11 +107,11 @@
return NULL;
}else{
/* realloc() */
return FLCA.f(FLCA.state, mem, n);
}
-#undef FLC
+#undef FLCA
}
#if 0
/* highly arguable */
/**
--
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil checksum
Hello All, From what I've read regarding the fossil documentation, it seems that sha1 hashes are used for the files. Is that still correct? If it is sha1, are there plans to switch to sha256? Thanks! -- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 checksum
On Tue, Oct 28, 2014 at 3:09 PM, Jungle Boogie jungleboog...@gmail.com wrote: From what I've read regarding the fossil documentation, it seems that sha1 hashes are used for the files. Is that still correct? Yes If it is sha1, are there plans to switch to sha256? I am not an authority on fossil roadmap, but I would guess that there is no such plan. Why switch? the hashes are not used for security, but as a type of checksum. The chance of two sha1 hashes colliding accidentally is astronomical. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] weird: sections lost during merge
On Tue, Oct 28, 2014 at 1:24 PM, Martin Gagnon eme...@gmail.com wrote: -#undef FLC +#undef FLCA Thank you! Probably harmless but nonetheless fixed. -- - 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 checksum
On Tue, Oct 28, 2014 at 2:42 PM, Baruch Burstein bmburst...@gmail.com wrote: If it is sha1, are there plans to switch to sha256? I am not an authority on fossil roadmap, but I would guess that there is no such plan. Why switch? the hashes are not used for security, but as a type of checksum. The chance of two sha1 hashes colliding accidentally is astronomical. i remember the topic coming up once several years ago (seems like 4+), and the chance of a problematic in the context of a single repo (which is the only place a UUID conflict matters) were proven (by those with the Powers of Math, not me) to be so unfathomably small that it was eventually dropped. An sha1 conflict between separate files in different repos is, in effect, no problem at all, which narrows down the window for real hash collisions considerably compared to if UUIDs had to be unique worldwide. i don't remember any numbers from that thread, but do remember one quote. When (whoever it was, probably Richard) explained that The Math shows that a collision is not likely to happen until some tens of thousands of years in the future, someone asked, but what then? -- - 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 checksum
On Tue, Oct 28, 2014 at 3:51 PM, Gour g...@atmarama.net wrote: On Tue, 28 Oct 2014 10:09:25 -0400 Richard Hipp d...@sqlite.org wrote: That same commit rate will cause Fossil to exceed its maximum repository size (140 terabytes) in about four minutes. What now? At that point we would ask the owners of that db to fund us full time for development of v2. And we'd have to agree to stop calling it sqLITE. -- - 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 checksum
Dear Richard, From: Richard Hipp d...@sqlite.org Sent: Tue, 28 Oct 2014 10:09:25 -0400 To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Fossil checksum On Tue, Oct 28, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: i don't remember any numbers from that thread, but do remember one quote. When (whoever it was, probably Richard) explained that The Math shows that a collision is not likely to happen until some tens of thousands of years in the future, someone asked, but what then? (Back-of-the-envelop calculations follow:) If 6 billion people are all using the same Fossil repository and are doing one commit per second, 24 hours a day, 7 days a week, then there is a 50% chance of a collision after a little more than 6 million years. That same commit rate will cause Fossil to exceed its maximum repository size (140 terabytes) in about four minutes. Let's see that envelop! That's some great math! In all seriousness to all who replied, thanks for putting any possible anxiousness to rest. Second question... The reason some people/organizations prefer a non-distributed SCM (is that the proper term?) is because you can delete commits and make it as if they never appeared. In the fossil like world, that's not possible if someone has already checked out a revision, but what can be done to prevent future checkouts? Is there a way to delete the commits and any traces of it? Thanks, jb -- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 checksum
On Tue, Oct 28, 2014 at 1:10 PM, Jungle Boogie jungleboog...@gmail.com wrote: Is there a way to delete the commits and any traces of it? https://www.fossil-scm.org/fossil/doc/trunk/www/shunning.wiki -- 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] Fossil checksum
On Tue, Oct 28, 2014 at 6:31 PM, B Harder brad.har...@gmail.com wrote: That said -- I would like an option to pop and discard from a branch tip. Possible? If the repo has been sync'd, then that work would come back to you on next sync (that's understood), but if it hasn't been sync'd, it could be useful. i looked into that sometime in the past year. In theory, once you can pop the top-most commit, you can pop any number (but always from the top). But the devil's in the details - getting each and every cross-reference and delta removed/replaced properly is remarkably difficult. -- - 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] Uncommit. Was: Fossil checksum
(copy/paste sbeal response in diff't thread) i looked into that sometime in the past year. In theory, once you can pop the top-most commit, you can pop any number (but always from the top). But the devil's in the details - getting each and every cross-reference and delta removed/replaced properly is remarkably difficult. Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? -bch On 10/28/14, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 28, 2014 at 1:31 PM, B Harder brad.har...@gmail.com wrote: I would like an option to pop and discard from a branch tip. Possible? If the repo has been sync'd, then that work would come back to you on next sync (that's understood), but if it hasn't been sync'd, it could be useful. To do an uncommit for a check-in that has not yet been synced, all you have to do is identify the particular artifacts that were added by that commit (the RCVFROM table should be helpful there) and remove them from the BLOB table of the database (taking care to also fix up the DELTA table so that it does not depend on any BLOB that you removed). Then rebuild. You could perhaps omit the rebuild step if you go to the extra work of removing the artifacts from the various other tables in the database. Or maybe you want an uncommit to force a rebuild in order to make it a little more painful, and hence discourage its use. I dunno. If somebody has a patch for the above, we can look at adding it... -- 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 7:05 PM, B Harder brad.har...@gmail.com wrote: Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? In this case it's like a stack and you could only delete from the top (and then the next top, ad nauseum...). You can't remove a link from the middle of the list without invalidating hashes. -- - 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] Uncommit. Was: Fossil checksum
That's pretty much what I figured... I'll have to dig in and understand cards (and maybe sit down again w/ you and just generally chat) -- but I expect to see a linear relationship. My intuition tells me one ought to be able to pop-and-delete back to origin -- of *course* if a repo has been replicated, a re-sync will (ought to) re-populate... which is fine and good. I guess the details would be: 1) how complex is the structure/relation that needs to be popped to do the operation as cleanly as possible 2) how much cheat room is allowed during the course of this development whereby perhaps a single card/obj could be deleted, and the dangling bits would be culled w/ a [f rebuild] ? 3) I can't think of anything else... -bch On 10/28/14, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:05 PM, B Harder brad.har...@gmail.com wrote: Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? In this case it's like a stack and you could only delete from the top (and then the next top, ad nauseum...). You can't remove a link from the middle of the list without invalidating hashes. -- - 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 1) how complex is the structure/relation that needs to be popped to do the operation as cleanly as possible On the surface it's really simple because we're guaranteed that there are no references to the top-most item. The details Richard mentioned, e.g. making sure there are no deltas referring to the content you're removing, are what i remember struggling with (on paper). i'll see if i can find the post i wrote about it (on fossil-dev) sometime... 6-9 months ago, i think. 2) how much cheat room is allowed during the course of this development whereby perhaps a single card/obj could be deleted, and the dangling bits would be culled w/ a [f rebuild] ? Only top-most commit (and any unique artifacts it introduced, e.g. new files or deltas vs older ones) could potentially be popped, or at least that's my understanding. 3) I can't think of anything else... You will. -- - 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 checksum
On Tue, Oct 28, 2014 at 7:31 PM, B Harder brad.har...@gmail.com wrote: That said -- I would like an option to pop and discard from a branch tip. Possible? If the repo has been sync'd, then that work would come back to you on next sync (that's understood), but if it hasn't been sync'd, it could be useful. There is an option to shun a whole transaction, meaning everything that was done in a single invocation of fossil (technically, everything with the same rcvid) -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 3) I can't think of anything else... You will. Perhaps looking at how shunning works would help ___ 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] Uncommit. Was: Fossil checksum
Not a bad idea -- this part of the description: Furthermore, all shunned artifacts (but not the shunning list itself) are removed from the repository whenever the repository is reconstructed using the rebuild command. may roughly be what we're looking for. We happen to be applying to a specific artifact only (tip of branch) which shouldn't be any worse than shunning in the middle of a branch, and may be simpler (barring the fact that a tip will have to be properly identified as a tip). Otherwise, there may be clues for what cards/blobs to target -- I also presume that the rebuild (for the case of shun) is to re-rationalize dependencies down the chain -- which won't be necessary w/ working on a tip (?) -bch On 10/28/14, Ron W ronw.m...@gmail.com wrote: On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 3) I can't think of anything else... You will. Perhaps looking at how shunning works would help ___ 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Uncommit. Was: Fossil checksum
On 10/28/14, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 28, 2014 at 5:17 PM, Ron W ronw.m...@gmail.com wrote: Maybe could be as simple as adding the relevant artifact IDs to the shun list and rebuilding. (Though that would be rather slow (which is not necessarily a bad thing for this feature)). Yep. Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. For that reason (and the extra baggage of the added element to the shun list) I think that shun (proper) is not the ideal long-term solution. -- 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] Uncommit. Was: Fossil checksum
Actually you might. By pushing a new tip on a branch a modified file X will likely cause the previous version of X to change to delta storage based on the new commit. IIRC. On Tue, Oct 28, 2014 at 2:46 PM, B Harder brad.har...@gmail.com wrote: On 10/28/14, Baruch Burstein bmburst...@gmail.com wrote: On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? For the purpose of this discussion (pop-and-destroy), I think there will be no deltas to have to accommodate, since we're only working against a tip of any branch. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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 ALL
I tried it and it works very well. Thanks. So, I guess I can leave all repos open all the time at both locations, and only do PULL/SYNC/PUSH at start/end of work day. (I only worry a bit about the possibility of the USB eventually becoming full during a ‘push’ what consequences will it have on my repo’s integrity – a scenario less likely to happen on a server) BTW, the syntax for Win7 is file://d:/path/file.fossil Hmm, now I wonder, could this file syncing also work with FTP over the Internet by changing file: to ftp: (or something) as I have a private FTP server on all the time (you know, those NAS/storage servers)? From: Richard Hipp Sent: Monday, October 27, 2014 3:44 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] FOSSIL ALL On Mon, Oct 27, 2014 at 9:30 AM, Tony Papadimitriou to...@acm.org wrote: I use mostly Windows, but every so often I open the repo on a Linux box (but I can do without Linux for now). Most thing we get working on Linux first, as that is the primary desktop for most of the Fossil developers (Jan excepted) That said, I think the previously described system of syncing to your thumb-drive using the file: scheme is probably going to work best for you. To recap: (1) Run fossil all setting autosync off. (2) Make copies of all repos onto your thumb drive. (3) For each working check-out: (3a) fossil remote file:/path/to/repo/on/thumb/drive The above is a one-time setup. Now, to transfer, just plug in your thumb drive and do: fossil all sync Then take the thumb drive home and do fossil all sync there too (having previously done the same 3-step setup). I'm not exactly sure what the syntax for the the file: URL is for the D: or E: filesystem (or whatever your USB stick comes up as). And I'm away from the office and don't have access to a windows machine to test it. Some experimentation is in order, but once you get it working, it should just work. -- 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
