Re: [fossil-users] Merging two leaves not on the same graph?
2014-05-15 6:46 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: I did some minimal testing to confirm that the previously identified problems no longer exist. I also tried cloning the empty repository and that worked both with old and the no-initial-commit version. Of course I was unable to commit with old versions (unless the particular bug fixed by [f7d9413ccf] was triggered). I don't imagine that a newly created fossil will have 0 checkins for long. Anything else need looking at? Thank you very much for your testing! Older fossil versions cannot check-out a repository with 0 check-ins, but as soon as a single check-in is done (using a newer fossil), older fossil versions can access the repository just fine. I think that's expected. 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] Merging two leaves not on the same graph?
On Thu, May 15, 2014 at 6:46 AM, Andy Bradford amb-fos...@bradfords.orgwrote: ...that worked both with old and the no-initial-commit version. Of course I was unable to commit with old versions (unless the particular bug fixed by [f7d9413ccf] was triggered). I don't imagine that a newly created fossil will have 0 checkins for long. Anything else need looking at? In my experience there are actually lots of small corner cases (most or all of which i'm quite certain Jan has already come across and fixed). In libfossil it took me several months to trip over all the various cases where i had asserted that rid!=0. The main problem was that some of them are in routines which simply aren't used all that often. Often times the fix is simply to remove the (now faulty) assertion, but in libfossil i ended up using different semantics for rid 0 in some cases (it means current checkout in some cases where 0 otherwise doesn't make sense). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
2014-05-08 19:26 GMT+02:00 Stephan Beal sgb...@googlemail.com: It's funny you say that because in libfossil i've had to go back and reexamine my 0 semantics, and let them be legal (empty repo) in some cases, but stand for the current checkout in others (where 0 otherwise makes no sense). Negatives are always invalid, but 0 has a few uses. In some cases, there's a small bit of extra handling for rid 0, but nothing tragic. Well, I did some more tests, creating an empty repository and one with a single non-empty initial commit: http://fosclipse.sourceforge.net/cgi-bin/empty/stat http://fosclipse.sourceforge.net/cgi-bin/one/stat Everything works just fine. Even fossil export --git works: $ fossil export --git one.fossil blob mark :4 data 6 hallo commit refs/heads/trunk mark :3 committer jan.nijtmans jan.nijtmans 1400010155 + data 9 hallo.txt deleteall M 100644 :4 hallo.txt And I can succesfully import it back into fossil, getting back the same single-non-empty-initial-commit repository. Sounds like a plan :) The plan worked! After Andy managed to trigger a bug in unsaved_changes() it was successfully reverted. Bug was later fixed in trunk. [http://fossil-scm.org/index.html/info/f7d9413ccf] Since GIT can handle non-empty initial check-in's just fine, is that enough reason for fossil to allow it as well? ;-) Anyway, I would like to execute the same plan (merge branch no-initial-commit to trunk) once more. If anyone thinks this is a bad idea (maybe because another bug prevents us to do that), I'm all ears. 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] Merging two leaves not on the same graph?
Thus said Jan Nijtmans on Wed, 14 May 2014 12:11:42 +0200: Anyway, I would like to execute the same plan (merge branch no-initial-commit to trunk) once more. If anyone thinks this is a bad idea (maybe because another bug prevents us to do that), I'm all ears. I did some minimal testing to confirm that the previously identified problems no longer exist. I also tried cloning the empty repository and that worked both with old and the no-initial-commit version. Of course I was unable to commit with old versions (unless the particular bug fixed by [f7d9413ccf] was triggered). I don't imagine that a newly created fossil will have 0 checkins for long. Anything else need looking at? Andy -- TAI64 timestamp: 4000537446d7 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
2014-05-01 12:28 GMT+02:00 Stephan Beal sgb...@googlemail.com: No objections, but some comments... - libfossil has been using repos without an initial commit since last summer. AFAIK there are no more open assertions related to that, but every now and then i'll run into a case which expects an RID0 and might (until the first commit) see a 0. It can always be repaired when this happens, but triggering it can be cumbersome to do (i.e. there might eventually be some (now-invalid) assertions which eventually need to be patched for this). In fossil, all of those (now-invalid) assertions have been fixed, I did extensive tests to assure that. Actually, fossil cannot do very much when dealing with an empty repository. Merging??? against what branch - Whether or not it should default to having no initial empty commit is debatable, but i can't argue strongly either way. i tend to think it should do one by default, solely for historical compatibility, but OTOH it's not a critical functionality (just an immediately-visible change for long-time users). I did additional tests to assure that historical compatibility is not affected. Three scenario's: - When people use an already exisiting repository, the initial empty commit is already there. Nothing to worry about. - When creating a new repository, no initial commit is there. But as soon as the first commit goes in, everything is exactly as before. Basic operations like add/remove/addremove/commit work fine even without the initial commit, other operations make no sense yet. 2014-05-01 21:42 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Well, I went ahead, and merged the proposed change to trunk. This means that the initial empty commit is no longer created by surprise, but it's only a change of the default behavior: When specifying --date-override, everything works as before. So I don't think existing behavior of importing and/or using already existing repositories will be affected in any way. Thanks for all remarks. But if anything unexpected happens which I didn't foresee, please report. 2014-05-01 22:21 GMT+02:00 B Harder brad.har...@gmail.com: I think that initial empty commits went in at my request. Iirc, so I could have related (but not inheriting from trunk) vendor branches. Can we review/discuss before axing? I didn't need an axe for this work, the possibility to create an initial empty commit is still there. But if during the timeline towards fossil 1.29 something unexpected is discovered: It's only a one-line code change easy to revert! Happy testing. Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
Thus said Jan Nijtmans on Thu, 08 May 2014 12:29:27 +0200: Well, I went ahead, and merged the proposed change to trunk. This means that the initial empty commit is no longer created by surprise, but it's only a change of the default behavior: When specifying --date-override, everything works as before. So I don't think existing behavior of importing and/or using already existing repositories will be affected in any way. Seems like a reasonable thing to do. I wanted to test it before you actually merged, but I've been busy on the per-round-trip-commit branch and haven't had any spare time. I think having an empty repository makes sense. Andy -- TAI64 timestamp: 4000536b9840 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
On Thu, May 8, 2014 at 12:29 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: tests to assure that. Actually, fossil cannot do very much when dealing with an empty repository. Merging??? against what branch It's funny you say that because in libfossil i've had to go back and reexamine my 0 semantics, and let them be legal (empty repo) in some cases, but stand for the current checkout in others (where 0 otherwise makes no sense). Negatives are always invalid, but 0 has a few uses. In some cases, there's a small bit of extra handling for rid 0, but nothing tragic. I did additional tests to assure that historical compatibility is not affected. Three scenario's: - When people use an already exisiting repository, the initial empty commit is already there. Nothing to worry about. - When creating a new repository, no initial commit is there. But as soon as the first commit goes in, everything is exactly as before. Basic operations like add/remove/addremove/commit work fine even without the initial commit, other operations make no sense yet. i agree: i also don't expect any problems if this is made the default (other than potential initial long-time user confusion, which they will quickly get over when they realize they can finally write the first commit message in their native language ;). I didn't need an axe for this work, the possibility to create an initial empty commit is still there. But if during the timeline towards fossil 1.29 something unexpected is discovered: It's only a one-line code change easy to revert! Sounds like a plan :) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
On Thu, May 01, 2014 at 02:42:58PM -0500, Andy Goth wrote: That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Wow. Where was this information/advice when I was asking about importing from Git to an existing empty/new Fossil repository a while back? Thank you! I'm going back to trying to use Fossil for those projects, instead of sticking with Git, now. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Merging two leaves not on the same graph?
On 5/1/2014 12:24 AM, Gerald Gutierrez wrote: I've got a fossil repository that has had two years' worth of history. Recently, I decided to host it on chiselapp, so I created a repository on chiselapp with the same project-id as my repository. Did you use the Upload Repository feature? -- 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] Merging two leaves not on the same graph?
Too big. Chiselapp has an 8MB upload size limit. On Wed, Apr 30, 2014 at 11:44 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 5/1/2014 12:24 AM, Gerald Gutierrez wrote: I've got a fossil repository that has had two years' worth of history. Recently, I decided to host it on chiselapp, so I created a repository on chiselapp with the same project-id as my repository. Did you use the Upload Repository feature? -- 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] Merging two leaves not on the same graph?
2014-05-01 7:24 GMT+02:00 Gerald Gutierrez gerald.gutier...@gmail.com: So now I'm confused. Should/can I merge these two leaves, or just leave it alone, or is the repository now in an inconsistent state? The only way I see to get rid of the second 'initial empty commit' is by logging in as admin and 'shun' the artifact directly. (dangerous!!!). The repository is not in an inconsistent state, it's just confusing. I think it would be better if fossil didn't create the initial empty commit any more: http://fossil-scm.org/index.html/info/f2c8b4f375 That would avoid the confusion, and it works fine! Any objections merging this to trunk? 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] Merging two leaves not on the same graph?
On Thu, May 1, 2014 at 10:05 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: I think it would be better if fossil didn't create the initial empty commit any more: http://fossil-scm.org/index.html/info/f2c8b4f375 That would avoid the confusion, and it works fine! Any objections merging this to trunk? No objections, but some comments... - libfossil has been using repos without an initial commit since last summer. AFAIK there are no more open assertions related to that, but every now and then i'll run into a case which expects an RID0 and might (until the first commit) see a 0. It can always be repaired when this happens, but triggering it can be cumbersome to do (i.e. there might eventually be some (now-invalid) assertions which eventually need to be patched for this). - Whether or not it should default to having no initial empty commit is debatable, but i can't argue strongly either way. i tend to think it should do one by default, solely for historical compatibility, but OTOH it's not a critical functionality (just an immediately-visible change for long-time users). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merging two leaves not on the same graph?
On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Chiselapp doesn't directly have this feature, but that doesn't mean it's out of reach. You can make a new, empty repository on your own computer with the initial commit date set to whenever, upload that, then push to it. -- 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] Merging two leaves not on the same graph?
Note also that chiselapp has a Clone Repo option under the Create Repo page. IOW if you are able to expose your repo via 'fossil server' on some http(s) url you can then clone it into the new chiselapp. Not sure however what limits apply there (size-, or time-wise). Might be useful to ask Roy (chiselapp host maintainer) On Thu, May 1, 2014 at 12:42 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Chiselapp doesn't directly have this feature, but that doesn't mean it's out of reach. You can make a new, empty repository on your own computer with the initial commit date set to whenever, upload that, then push to it. -- 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 -- 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 EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 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] Merging two leaves not on the same graph?
Talked with Roy on the Tcler's chat. [12:54]rkeeneaku, The 8MB limit is incorrect -- it's really 2GB (IIRC) but the page doesn't say that [12:55]rkeeneThere might be a timeout for Clone Repo in terms of the CGI wait -- I can fix that if there is so that the clone happens async. if it doesn't already [12:55]akuAre you subscribed to fossil-user mailing list ? we just have a thread where an 8MB limit was mentioned [12:56]rkeeneNo, but maybe I can reply somehow ? [12:57]rkeeneupload_max_filesize = 200M [12:57]akuLet me see, I will send a mial with you cc'd [12:57]rkeeneSo 200MB is the real limit [12:57]akuto bring you into the thread On Thu, May 1, 2014 at 12:50 PM, Andreas Kupries andre...@activestate.com wrote: Note also that chiselapp has a Clone Repo option under the Create Repo page. IOW if you are able to expose your repo via 'fossil server' on some http(s) url you can then clone it into the new chiselapp. Not sure however what limits apply there (size-, or time-wise). Might be useful to ask Roy (chiselapp host maintainer) On Thu, May 1, 2014 at 12:42 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 5/1/2014 2:11 AM, Gerald Gutierrez wrote: Too big. Chiselapp has an 8MB upload size limit. That explains it. You created a new repository and pushed to it, but that new repository had that unwanted empty commit, set to the current date and time. Whenever I convert an existing project to Fossil, I have to do [fossil new -date-override] to specify the date of the initial commit, putting it before the oldest commit I'm going to be putting into it. Chiselapp doesn't directly have this feature, but that doesn't mean it's out of reach. You can make a new, empty repository on your own computer with the initial commit date set to whenever, upload that, then push to it. -- 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 -- 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 EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 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. -- 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 EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 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] Merging two leaves not on the same graph?
I think that initial empty commits went in at my request. Iirc, so I could have related (but not inheriting from trunk) vendor branches. Can we review/discuss before axing? On May 1, 2014 1:06 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-05-01 7:24 GMT+02:00 Gerald Gutierrez gerald.gutier...@gmail.com: So now I'm confused. Should/can I merge these two leaves, or just leave it alone, or is the repository now in an inconsistent state? The only way I see to get rid of the second 'initial empty commit' is by logging in as admin and 'shun' the artifact directly. (dangerous!!!). The repository is not in an inconsistent state, it's just confusing. I think it would be better if fossil didn't create the initial empty commit any more: http://fossil-scm.org/index.html/info/f2c8b4f375 That would avoid the confusion, and it works fine! Any objections merging this to trunk? 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Merging two leaves not on the same graph?
I've got a fossil repository that has had two years' worth of history. Recently, I decided to host it on chiselapp, so I created a repository on chiselapp with the same project-id as my repository. I then pushed my local repository to the chiselapp repository and then looked at the timeline and realized that I have two leaves now but they are not on the same directed graph (http://imgur.com/eMlgTgk). Then I read at the fossil web site ( http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki) that fossil keeps all check-ins in a single DAG, but the two leaves I have are clearly on different DAGs. When I try to merge them, fossil complains: Merging fork [040afa12232413ae] at 2014-05-01 02:08:30 by xxx: initial empty check-in cannot find a common ancestor between the current checkout and Note that after the and it doesn't say anything. So now I'm confused. Should/can I merge these two leaves, or just leave it alone, or is the repository now in an inconsistent state? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
