Re: [fossil-users] How to fix parallel timeline
On Fri, Mar 13, 2015 at 12:18 AM, Tontyna tont...@ultrareal.de wrote: To reproduce Dave's timeline I was happy to still get Fossil 1.27 from the download page, but --- I think Fossil 1.30 should be removed from there or at least be tagged as don't use it with newer repos. Richard mentioned earlier that he will remove the no initial commit bits, which will (theoretically, at least) eliminate this problem for future versions. i would hate to see it go (not enough to raise a fuss about it), but it should never have ever been made the default, to avoid compatibility problems like this one. There was a long thread related to this on May 31st, 2014: https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html -- - 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] How to fix parallel timeline
2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com: Richard mentioned earlier that he will remove the no initial commit bits, which will (theoretically, at least) eliminate this problem for future versions. i would hate to see it go +1 (not enough to raise a fuss about it), but it should never have ever been made the default, to avoid compatibility problems like this one. There was a long thread related to this on May 31st, 2014: https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html The source of this problem was the (past) assumption in the code that the initial commit has rowid=1 and it doesn't contain any files. This bug was fixed here (16 months ago, available since fossil 1.28): http://fossil-scm.org/index.html/info/6791ad1185f374dc If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Therefore I respecfully disagree (based on what I read in this thread) with Richard's conclusion that work has been lost due to fossil, but David Mason should have the final word on that (the DELETE's in David's original story meant that those _unchanged_ files were removed from the working copy, but they still were in the repository even though they were invisible to the students). Thanks to Tontyna for his excellent analysis, which made it (at least to me) fully clear what really happend here. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to fix parallel timeline
On Fri, Mar 13, 2015 at 1:12 PM, Tontyna tont...@ultrareal.de wrote: A tricky SQL statement could probably create the required records... Nope - the db is basically just a transient cache for the manifest (checkin) data and blobs (file content). The checkin data _is_ also in the db, but not in a form which the db can directly work with. (It's intended to be independent of the storage layer.) Any change to that data (e.g. adding a parent checkin post facto) invalidates 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] How to fix parallel timeline
Am 13.03.2015 um 10:59 schrieb Jan Nijtmans: If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Thats right. Switching to a newer Fossil the timeline still is split but all files (from both lines) are accessible in the reposiory. Nonetheless: I'm lost on how to join the lines again -- no chance without a common ancestor. Seems to be a repository containing two separate repositories. A tricky SQL statement could probably create the required records... Thanks to Tontyna for his excellent analysis, which made it (at least to me) fully clear what really happend here. My pleasure. BTW it's her not his ;) Regards, Tontyna ___ 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] How to fix parallel timeline
On Fri, Mar 13, 2015 at 11:53:10AM -0400, Martin Gagnon wrote: BTW, chiselapp.com still use version 1.25 release. The same problem could happens easily when using the Clone Repository option if the source repo is created without initial empty check-in. Sorry.. I just notice that it really use a recent version, it's only the front end site that seems to be served by a old fossil version. -- 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] How to fix parallel timeline
On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote: 2015-03-13 8:49 GMT+01:00 Stephan Beal sgb...@googlemail.com: Richard mentioned earlier that he will remove the no initial commit bits, which will (theoretically, at least) eliminate this problem for future versions. i would hate to see it go +1 (not enough to raise a fuss about it), but it should never have ever been made the default, to avoid compatibility problems like this one. There was a long thread related to this on May 31st, 2014: https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15871.html The source of this problem was the (past) assumption in the code that the initial commit has rowid=1 and it doesn't contain any files. This bug was fixed here (16 months ago, available since fossil 1.28): http://fossil-scm.org/index.html/info/6791ad1185f374dc If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Therefore I respecfully disagree (based on what I read in this thread) with Richard's conclusion that work has been lost due to fossil, but David Mason should have the final word on that (the DELETE's in David's original story meant that those _unchanged_ files were removed from the working copy, but they still were in the repository even though they were invisible to the students). BTW, chiselapp.com still use version 1.25 release. The same problem could happens easily when using the Clone Repository option if the source repo is created without initial empty check-in. -- 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] How to fix parallel timeline
Thus said Tontyna on Fri, 13 Mar 2015 13:12:25 +0100: A tricky SQL statement could probably create the required records... While no content was lost, the relationship appears to have been lost, which is why the timeline cannot figure out how to draw it. Specifically, the problem appears to be that the manifest for the checkin on the alternate tree has an incorrect P-card. The P-card for the checkin is actually not a checkin artifact, but rather is a file artifact. For example, in a test repository where I caused the issue (following your instructions), the first checkin after cloning generates a manifest like: C This\sis\sa\stest. D 2015-03-12T16:24:08.929 F file 914a1602b6193e4b66d78b1b8ffa7cf599dabfc8 P 79a816e5ee1e7139d7cd4326a713c16c16dbe236 R e28bf5671577b991b7edb68bd78fd78f U amb Z ee6e8bcef3bf4a9d39d755082f5c15d4 But 79a816e5ee1e7139d7cd4326a713c16c16dbe236 is actually the previous revision of the file itself and not the previous checkin. Here is the manifest of the original first-time commit when the repository was empty: C one D 2015-03-12T16:16:53.699 F file 79a816e5ee1e7139d7cd4326a713c16c16dbe236 R 2e2b846407951e4e86de07454ab860f1 T *branch * trunk T *sym-trunk * U amb Z e0783afde0ee3f78d55affc6494d3f50 Notice that the hash for the F-card and the hash for the P-card from the second checkin are the same. So while Fossil 1.27 did successfully add the content (no content was lost) it picked the wrong file to generate the P-card. I don't know of any way to repair this. Andy -- TAI64 timestamp: 400055031610 ___ 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] How to fix parallel timeline
On 3/11/15, David Mason dma...@ryerson.ca wrote: I've emailed the fossil to drh. That sequence of update and merge just toggled between timelines. I.e.: ADDED Fossils/A3.hs ADDED Fossils/a1.hs ADDED Fossils/a2-a2.hs ADDED Fossils/test DELETE .fossil-settings/allow-symlinks DELETE .fossil-settings/binary-glob DELETE .fossil-settings/clean-glob DELETE .fossil-settings/ignore-glob DELETE .fossil-settings/ignore-glob.no-warn DELETE a1/.hold DELETE a2/.hold DELETE a3/.hold DELETE a4/.hold DELETE a5/.hold DELETE a6/.hold Maybe this: fossil up 33f9 fossil merge --baseline 198f28 094b That gives: ADDED Fossils/A3.hs ADDED Fossils/a2-a2.hs As for what they did, it was a while ago that they set them up. There was a problem that the students on Linux (typically ubuntu) didn't see the stuff I had created for them (default .fossil-settings and assignment directories), which sounds a lot like this problem. I guess they were never working on trunk. Perhaps if i'd told them to fossil update trunk it would have worked. That should have been automatic when they first checked out the repo. The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: http://cps506.sarg.ryerson.ca/Resources/fossil.html 1.27 should be completely compatible. It lacks some of the newer features, but should interoperate just fine. Are you sure your students didn't shun something or try to use reconstruct? ../Dave On 11 March 2015 at 12:48, Richard Hipp d...@sqlite.org wrote: On 3/11/15, Andreas Kupries andre...@activestate.com wrote: On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote: On 3/11/15, David Mason dma...@ryerson.ca wrote: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. I was about to suggest using --baseline. What is the exact command-sequence that you used? And how do you know it didn't work - did it give an error? I wonder if merging by exact sha-hash would work ? I'm looking at the source code, and I'm thinking that --baseline ought to work. The command sequence should be: fossil update 33f9c5915f fossil merge 094b1b8a4d --baseline ce53290262 I'm still curious as to how the students managed to get the repo into this state, too. The only thing I can think of is that they had one or more check-ins in between ce53290262 and 198f28add5 that the shunned. It makes me wonder if we ought not put more safety checks and harsher warnings on the shun command? -- 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 -- 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] How to fix parallel timeline
Am 11.03.2015 um 18:48 schrieb David Mason: The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: Can't imagine how your students were able to work with 1.27 on a repository created with 1.30 without doing a fossil rebuild With 1.29 I'm not even able to open the 1.30 repo. With 1.27 I can open the cloned repo but cannot add files. Managed to reproduce your corrupted timeline: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all 4. created a new file 5. `fossil add` warned me about the wrong schema version 6. did what I was told: `fossil rebuild` 7. Now `add .` worked fine 8. `commit` warned me about autosync not working I ignored that an continued. 9. fossil ui/timeline -- see attached picture ___ 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] How to fix parallel timeline
On 3/12/15, Tontyna tont...@ultrareal.de wrote: Am 11.03.2015 um 18:48 schrieb David Mason: The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: Can't imagine how your students were able to work with 1.27 on a repository created with 1.30 without doing a fossil rebuild With 1.29 I'm not even able to open the 1.30 repo. With 1.27 I can open the cloned repo but cannot add files. Thanks Tontyna. I can repro the problem now too. I have some other unrelated issues to deal with first. But I will soon be making some important and sad announcements in connection with this whole affair. Managed to reproduce your corrupted timeline: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all 4. created a new file 5. `fossil add` warned me about the wrong schema version 6. did what I was told: `fossil rebuild` 7. Now `add .` worked fine 8. `commit` warned me about autosync not working I ignored that an continued. 9. fossil ui/timeline -- see attached picture -- 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] How to fix parallel timeline
On 3/12/15, David Mason dma...@ryerson.ca wrote: Thanks Tontyna! I was going to do what you tried, today, but I really appreciate you confirming it. It is certainly possible that the students would do a fossil rebuild if fossil told them to. The odds of 20 of them doing that if not told are very low. The fossil rebuild is not necessary. All they have to do is use Fossil 1.27 to clone a repo that was created with Fossil 1.30. -- 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] How to fix parallel timeline
On 3/12/15, Jan Nijtmans jan.nijtm...@gmail.com wrote: Much better, preventing the problem all together: create the repository with Fossil 1.27 to begin with. Fossil 1.30 had bugs which ill-treat repositories without any commits. Those were fixed in Fossil 1.30. Just to be clear: Those changes that allow one to create a repo that has no commits - they are going to be backed out just as soon as I get the opportunity. -- 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] How to fix parallel timeline
Thanks Tontyna! I was going to do what you tried, today, but I really appreciate you confirming it. It is certainly possible that the students would do a fossil rebuild if fossil told them to. The odds of 20 of them doing that if not told are very low. ../Dave On 12 March 2015 at 06:40, Tontyna tont...@ultrareal.de wrote: Am 11.03.2015 um 18:48 schrieb David Mason: The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: Can't imagine how your students were able to work with 1.27 on a repository created with 1.30 without doing a fossil rebuild With 1.29 I'm not even able to open the 1.30 repo. With 1.27 I can open the cloned repo but cannot add files. Managed to reproduce your corrupted timeline: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all 4. created a new file 5. `fossil add` warned me about the wrong schema version 6. did what I was told: `fossil rebuild` 7. Now `add .` worked fine 8. `commit` warned me about autosync not working I ignored that an continued. 9. fossil ui/timeline -- see attached picture ___ 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] How to fix parallel timeline
2015-03-12 15:22 GMT+01:00 Richard Hipp d...@sqlite.org: The fossil rebuild is not necessary. All they have to do is use Fossil 1.27 to clone a repo that was created with Fossil 1.30. Much better, preventing the problem all together: create the repository with Fossil 1.27 to begin with. Fossil 1.30 had bugs which ill-treat repositories without any commits. Those were fixed in Fossil 1.30. A workaround: If you really want to create the initial repository with Fossil 1.30, use fossil new --date-override now. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to fix parallel timeline
The repository provided to the students *did* have commits: .fossil-settings with 4+ files and 6 directories with .hold files in them. But maybe what you're saying is that something post-1.27 to support that caused other problems. ../Dave On 12 March 2015 at 10:34, Richard Hipp d...@sqlite.org wrote: On 3/12/15, Jan Nijtmans jan.nijtm...@gmail.com wrote: Much better, preventing the problem all together: create the repository with Fossil 1.27 to begin with. Fossil 1.30 had bugs which ill-treat repositories without any commits. Those were fixed in Fossil 1.30. Just to be clear: Those changes that allow one to create a repo that has no commits - they are going to be backed out just as soon as I get the opportunity. -- 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] How to fix parallel timeline
Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all According to David's instructions[1], there were files added to the repository before it was made available for cloning to the students... Does this still happen if you add files prior to cloning? I suppose it's possible that there are some missing steps from David's instructions? [1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19480.html Thanks, Andy -- TAI64 timestamp: 40005501cc3f ___ 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] How to fix parallel timeline
On 3/12/15, David Mason dma...@ryerson.ca wrote: The repository provided to the students *did* have commits: .fossil-settings with 4+ files and 6 directories with .hold files in them. But maybe what you're saying is that something post-1.27 to support that caused other problems. Version 1.29 introduced changes in the way the fossil init command constructed a repository, which violated assumptions about the repository layout that version 1.27 and earlier had made, apparently. I am currently fuzzy on the details. I have not yet freed up enough time to dig deeper into the issue. We know that if you stick to use the latest versions of Fossil everything will work fine. I don't yet know the specific cause of the confusion in version 1.27. I have important clients who are requesting expedited enhancements to SQLite right now and I need to deal with those requests first, but I will get back to a detailed analysis of this problem as quickly as I can. -- 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] How to fix parallel timeline
No I copied the script that creates the fossils directly into that email, and apart from the warning in red, the instructions to students are unchanged. The odd student might do something different, but most will have done only and exactly what the instructions say. ../Dave On 12 March 2015 at 13:25, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all According to David's instructions[1], there were files added to the repository before it was made available for cloning to the students... Does this still happen if you add files prior to cloning? I suppose it's possible that there are some missing steps from David's instructions? [1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19480.html Thanks, Andy -- TAI64 timestamp: 40005501cc3f ___ 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] How to fix parallel timeline
Am 12.03.2015 um 18:25 schrieb Andy Bradford: Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100: 1. Created a repo with Fossil 1.30 forgot to mention: added a file and committed 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all According to David's instructions[1], there were files added to the repository before it was made available for cloning to the students... Does this still happen if you add files prior to cloning? The repo I created with 1.30 contained one file but as I said: after open (seemingly successfully because I got no warnings) the local root was empty besides the _FOSSIL_ database. Don't know what `fossil rebuild` does with the repository (downgrading 1.30 to 1.27? How? What has `clone` done already?) but the parallel timeline definitely has something to do with the initial commit -- the clone contains 1 checkin, the above mentioned file (btw. Dave's 'default setup' files). Maybe when Fossil 1.27 sees the 1 it thinks: Oh, that's a repo containing nothing but the initial empty commit which we abandoned in version 1.30 but I don't know nuthin about 1.30. and gets tangled up. Because surprise! When I did the same with an EMPTY master repository or a master containing MORE THAN ONE commit -- no parallel timeline. Everything is working as expected. Except of course autosync fails when committing: Error: database schema is out-of-date on the server -- I'm wondering why your students who apparently read Fossil's output (and did a `rebuild` accordingly) didn't notify you of that. Or did you turn off autosync? Q: Is it worth investigating this issue? How could/should one make previous versions forward-compatible? Current and future versions could probably refuse to rebuild a repo with a newer schema... To reproduce Dave's timeline I was happy to still get Fossil 1.27 from the download page, but --- I think Fossil 1.30 should be removed from there or at least be tagged as don't use it with newer repos. - Tontyna ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How to fix parallel timeline
I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. Any help to merge these timeline much appreciated. ../Dave ___ 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] How to fix parallel timeline
On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote: On 3/11/15, David Mason dma...@ryerson.ca wrote: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. I was about to suggest using --baseline. What is the exact command-sequence that you used? And how do you know it didn't work - did it give an error? I wonder if merging by exact sha-hash would work ? -- 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 ___ 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] How to fix parallel timeline
On 3/11/15, Andreas Kupries andre...@activestate.com wrote: On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote: On 3/11/15, David Mason dma...@ryerson.ca wrote: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. I was about to suggest using --baseline. What is the exact command-sequence that you used? And how do you know it didn't work - did it give an error? I wonder if merging by exact sha-hash would work ? I'm looking at the source code, and I'm thinking that --baseline ought to work. The command sequence should be: fossil update 33f9c5915f fossil merge 094b1b8a4d --baseline ce53290262 I'm still curious as to how the students managed to get the repo into this state, too. The only thing I can think of is that they had one or more check-ins in between ce53290262 and 198f28add5 that the shunned. It makes me wonder if we ought not put more safety checks and harsher warnings on the shun command? -- 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] How to fix parallel timeline
On 3/11/15, David Mason dma...@ryerson.ca wrote: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) Fossil is suppose to be bullet-proof. I'd really like to know what your students did in order to get the repository into this shape. Can you recreate the problem so that we can fix it and prevent a recurrence? Can you send me the repository file (via private email to d...@sqlite.org) so that I can try to diagnose the underlying problem? I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. I was about to suggest using --baseline. What is the exact command-sequence that you used? And how do you know it didn't work - did it give an error? Any help to merge these timeline much appreciated. ../Dave -- 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] How to fix parallel timeline
Thus said Richard Hipp on Wed, 11 Mar 2015 15:56:41 -0400: That's an processing artifact of the graph generator. The 198f28add5 check-in references some parent a09a968bf05 which is not in the tree, so the graph generator just draws a line off the bottom of the page, not knowing what else to do. I see, definitely not the problem I thought it was. Is it possible that the parent that it references came from private content in the student's clone? Thanks, Andy -- TAI64 timestamp: 40005500afa7 ___ 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] How to fix parallel timeline
Thanks for all the imagining. (Sorry, I was off reading the latest
episode of Harry Potter and the Methods of Rationality hpmor.com
quite extraordinary!)
But I'm back. I could imagine one student doing some weird thing, but
not a score of them with the same outcome. The directions were as I
posted (without the bits in red). I would virtually guarantee that
*none* of the students tried shun or rebuild or copied over the
.fossil file but they all did it, and did the same thing? As
likely that they all had the same hash code! :-)
Sorry I can't reconstruct the sequence more accurately, but with 125
students coming in at random times with problems and only seeing this
split-timeline yesterday, and now trying to put it all together
Here's what I've got:
1) I have a directory with a .fossil-settings and a1/.hold a2/.hold
called Template-Checkout
2) I execute a script containing:
fossil new $f
chmod g+w $f
fossil sqlite $f INSERT INTO config VALUES
('remote_user_ok',1,strftime('%s','now'));
for ta in `cat TA-id`
do
fossil user -R $f new $ta $ta $pw
fossil user -R $f capabilities $ta v
done
fossil user -R $f new $who $who $pw
fossil user -R $f capabilities $who v
(
cd Template-Checkout
fossil open --nested ../$f
fossil add --dotfiles .
fossil commit -m 'default setup'
fossil close ||
exit 1
) || {
echo build for $who FAILED!!
exit 1
}
3) this is inside another working directory - hence the --nested, $f
is student.fossil
4) the student does a fossil clone as per the instructions in
http://cps506.sarg.ryerson.ca/Resources/fossil.html
5) when they do the fossil open they *DON'T* see any files listed.
The next line they see is 'project-name:'
6) they are apparently not in trunk - in fact there are no tags
7) they create files, add them, do ci
8) the marker (shruthi) clones them, updates them, and seeing nothing,
registers a mark of 0 in a file called a1/Marks, adds it, commits it
9a) the student does an update, sees no mark file, or
9b) the student sees the mark file, but all files look to have gone.
10) when I update/clone and do ui I see that there are 2 timelines.
Does that help at all?
Thanks!
On 11 March 2015 at 14:43, Eric Rubin-Smith eas@gmail.com wrote:
... unless the students used raw SQL to hack there project-id to make
it match the repository into which they were pushing. But I'm
thinking that is not what happened here.
Little anecdote. When I was a student we were using CVS for our big
project. One teammate couldn't understand why his check-ins were not
showing up in CVSTrac (thanks Richard:-)... investigation revealed that he
was trying to 'cp' his files onto the CVS repo tree rather than using 'cvs'
commands.
Not sure which is a better stress tester, a randomized fuzz program or an
inexperienced student with 5 volts of coffee onboard at 2am...
Eric
___
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] How to fix parallel timeline
On 3/11/15, Andy Bradford amb-fos...@bradfords.org wrote: We're just eliminating all the obvious things. So, let me ask this... in the PNG of the timeline you sent, why does your ``default setup'' commit show up *after* the other timeline's first commit? According to your own steps, this should have happened prior to any students getting it, yet the second timeline clearly has a beginning time that precedes your ``default setup.'' That's an processing artifact of the graph generator. The 198f28add5 check-in references some parent a09a968bf05 which is not in the tree, so the graph generator just draws a line off the bottom of the page, not knowing what else to do. -- 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] How to fix parallel timeline
On 3/11/15, David Mason dma...@ryerson.ca wrote: As for what they did, it was a while ago that they set them up. There was a problem that the students on Linux (typically ubuntu) didn't see the stuff I had created for them (default .fossil-settings and assignment directories), which sounds a lot like this problem. I guess they were never working on trunk. Perhaps if i'd told them to fossil update trunk it would have worked. The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: http://cps506.sarg.ryerson.ca/Resources/fossil.html The first visible student check-in is 198f28add5. The manifest for that check-in shows that its parent check-in is a09a968bf05a50058f3ad50132730b719bc39e76. But artifiact a09a968bf05a50058f3ad50132730b719bc39e76 is not a check-in, it is a content file. That means that the 198f28add5 check-in manifest is corrupt. I do not know how that came to be Brainstorming... Maybe something like this occurred: (1) Copy the original repository file into xyz.fossil (2) run fossil open xyz.fossil (3) Copy a revised version of the repository over top of xyz.fossil (4) run fossil commit Copying over a repository with a new version, as is done in step (3), should not be done while there are open check-outs. One should fossil close first, then overwrite the repo, then fossil open again. That is something we do not check right now - maybe we should. It never occurred to me that somebody might overwrite a repository that was in use with a different repository. Is the scenario above a possibility? -- 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] How to fix parallel timeline
Are you sure your students didn't shun something or try to use reconstruct? What would happen if the student tried to push a repo that they had created with 'fossil init' to the central clone? ___ 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] How to fix parallel timeline
On Wed, Mar 11, 2015 at 11:43 AM, Eric Rubin-Smith eas@gmail.com wrote: ... unless the students used raw SQL to hack there project-id to make it match the repository into which they were pushing. But I'm thinking that is not what happened here. Little anecdote. When I was a student we were using CVS for our big project. One teammate couldn't understand why his check-ins were not showing up in CVSTrac (thanks Richard:-)... investigation revealed that he was trying to 'cp' his files onto the CVS repo tree rather than using 'cvs' commands. Not sure which is a better stress tester, a randomized fuzz program Semi-recently seen on the sqlite list, and on HN today (https://news.ycombinator.com/item?id=9183225) http://lcamtuf.coredump.cx/afl/ or an inexperienced student with 5 volts of coffee onboard at 2am... Ouch -- 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 ___ 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] How to fix parallel timeline
Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400: But I'm back. I could imagine one student doing some weird thing, but not a score of them with the same outcome. The directions were as I posted (without the bits in red). I would virtually guarantee that *none* of the students tried shun or rebuild or copied over the .fossil file but they all did it, and did the same thing? As likely that they all had the same hash code! :-) We're just eliminating all the obvious things. So, let me ask this... in the PNG of the timeline you sent, why does your ``default setup'' commit show up *after* the other timeline's first commit? According to your own steps, this should have happened prior to any students getting it, yet the second timeline clearly has a beginning time that precedes your ``default setup.'' Thanks, Andy -- TAI64 timestamp: 400055009a46 ___ 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] How to fix parallel timeline
On 3/11/15, Eric Rubin-Smith eas@gmail.com wrote: Are you sure your students didn't shun something or try to use reconstruct? What would happen if the student tried to push a repo that they had created with 'fossil init' to the central clone? The push would be refused. Every fossil init creates a new random project-id string. Repos with different project-ids will not sync. The project-id exists to prevent the kind of accident you describe. ... unless the students used raw SQL to hack there project-id to make it match the repository into which they were pushing. But I'm thinking that is not what happened here. -- 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] How to fix parallel timeline
... unless the students used raw SQL to hack there project-id to make it match the repository into which they were pushing. But I'm thinking that is not what happened here. Little anecdote. When I was a student we were using CVS for our big project. One teammate couldn't understand why his check-ins were not showing up in CVSTrac (thanks Richard:-)... investigation revealed that he was trying to 'cp' his files onto the CVS repo tree rather than using 'cvs' commands. Not sure which is a better stress tester, a randomized fuzz program or an inexperienced student with 5 volts of coffee onboard at 2am... Eric ___ 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] How to fix parallel timeline
Thus said Richard Hipp on Wed, 11 Mar 2015 12:48:04 -0400: I'm still curious as to how the students managed to get the repo into this state, too. This is possible if you open a repository using the --empty command line option. Basically, what you end up with when you do this are two DAGs in the repository, each with their own independent line of development. This means that merging between the two won't really be possible, (or perhaps very difficult) because they are not at all related in their DAG. Did the students use --empty (perhaps misunderstanding what it is used for)? Andy -- TAI64 timestamp: 400055009345 ___ 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] How to fix parallel timeline
Thus said David Mason on Wed, 11 Mar 2015 11:07:11 -0400: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) Do you create the intial repository for the students? If so, do you initialize the repository without a project-code or do something else with the project code? Do your instructions for opening the repository include --empty? What version of fossil is being used to create/clone the repositories? See some discussion here for some relevant discussion: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg17644.html Andy -- TAI64 timestamp: 400055009683 ___ 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] How to fix parallel timeline
I've emailed the fossil to drh. That sequence of update and merge just toggled between timelines. I.e.: ADDED Fossils/A3.hs ADDED Fossils/a1.hs ADDED Fossils/a2-a2.hs ADDED Fossils/test DELETE .fossil-settings/allow-symlinks DELETE .fossil-settings/binary-glob DELETE .fossil-settings/clean-glob DELETE .fossil-settings/ignore-glob DELETE .fossil-settings/ignore-glob.no-warn DELETE a1/.hold DELETE a2/.hold DELETE a3/.hold DELETE a4/.hold DELETE a5/.hold DELETE a6/.hold As for what they did, it was a while ago that they set them up. There was a problem that the students on Linux (typically ubuntu) didn't see the stuff I had created for them (default .fossil-settings and assignment directories), which sounds a lot like this problem. I guess they were never working on trunk. Perhaps if i'd told them to fossil update trunk it would have worked. The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: http://cps506.sarg.ryerson.ca/Resources/fossil.html ../Dave On 11 March 2015 at 12:48, Richard Hipp d...@sqlite.org wrote: On 3/11/15, Andreas Kupries andre...@activestate.com wrote: On Wed, Mar 11, 2015 at 8:25 AM, Richard Hipp d...@sqlite.org wrote: On 3/11/15, David Mason dma...@ryerson.ca wrote: I have several students who, through some problem while cloning the fossil I created for them, created a parallel timeline. (see screenshot) I want to merge them, but fossil merge says there's no head to merge. The commits by the student are on the right and are not tagged as trunk, but tagging them as such doesn't seem to help. Using --baseline in merge didn't help either. I was about to suggest using --baseline. What is the exact command-sequence that you used? And how do you know it didn't work - did it give an error? I wonder if merging by exact sha-hash would work ? I'm looking at the source code, and I'm thinking that --baseline ought to work. The command sequence should be: fossil update 33f9c5915f fossil merge 094b1b8a4d --baseline ce53290262 I'm still curious as to how the students managed to get the repo into this state, too. The only thing I can think of is that they had one or more check-ins in between ce53290262 and 198f28add5 that the shunned. It makes me wonder if we ought not put more safety checks and harsher warnings on the shun command? -- 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] How to fix parallel timeline
I'd virtually guarantee that 20 students - and only the ones running using the apt-get fossil - did not try the --empty switch. Unfortunately. And when I added tags to the empty timeline they were still not mergable. ../Dave On 11 March 2015 at 15:10, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Richard Hipp on Wed, 11 Mar 2015 12:48:04 -0400: I'm still curious as to how the students managed to get the repo into this state, too. This is possible if you open a repository using the --empty command line option. Basically, what you end up with when you do this are two DAGs in the repository, each with their own independent line of development. This means that merging between the two won't really be possible, (or perhaps very difficult) because they are not at all related in their DAG. Did the students use --empty (perhaps misunderstanding what it is used for)? Andy -- TAI64 timestamp: 400055009345 ___ 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] How to fix parallel timeline
On 3/11/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400: But I'm back. I could imagine one student doing some weird thing, but not a score of them with the same outcome. The directions were as I posted (without the bits in red). I would virtually guarantee that *none* of the students tried shun or rebuild or copied over the .fossil file but they all did it, and did the same thing? As likely that they all had the same hash code! :-) We're just eliminating all the obvious things. So, let me ask this... in the PNG of the timeline you sent, why does your ``default setup'' commit show up *after* the other timeline's first commit? According to your own steps, this should have happened prior to any students getting it, yet the second timeline clearly has a beginning time that precedes your ``default setup.'' Thanks, Andy -- TAI64 timestamp: 400055009a46 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] How to fix parallel timeline
Thus said David Mason on Wed, 11 Mar 2015 15:17:57 -0400: Does that help at all? I tried these steps with Fossil from trunk and saw the files when I opened the Fossil. Any chance you could make up a test fossil using the above mentioned steps (and a fake student/user and TA) in the environment where you normally make them and make it available for download? Thanks, Andy -- TAI64 timestamp: 40005501105c ___ 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] How to fix parallel timeline
Thus said Richard Hipp on Wed, 11 Mar 2015 14:32:18 -0400: Brainstorming... Maybe something like this occurred: (1) Copy the original repository file into xyz.fossil (2) run fossil open xyz.fossil (3) Copy a revised version of the repository over top of xyz.fossil (4) run fossil commit This seems like a much more likely scenario than anything else I've seen and certainly within the realm of what a student unfamiliar with ``allowing the SCM to manage things'' might do, thinking they have to manage the .fossil file. Many moons ago, some fellow students blamed CVS for losing their changes everytime certain people committed. But that's because they had files outside the working area, would make changes there, and then copy them into CVS (like it was some glorified backup), not realizing that everytime they did this, they wiped out someone else's changes. How could this be prevented? Write a repo synchronization value into the config table and the vvar table in the .fslckout DB and then verify that they are the same before committing? Andy -- TAI64 timestamp: 400055010af4 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
