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
[fossil-users] please remove git import honours timezone from trunk
Hello fossil developers, I am switching from git to fossil and decided to use compiled sources from trunk (003db810a282b3ba), according to http://www2.fossil-scm.org/fossil/doc/tip/www/build.wiki (Aside: Is it really safe to use...) However, the logic that honours timezones is plain wrong and leads to a permanent error during the first hours after the checkout. The timestamps in the git exports are stored in seconds since epoch. The timezone information is purely informational. Thus it is plain wrong, to modify the timestamp using that information. Please remove or change the change. What happened: --- $ git fast-export --all | fossil import --git new-repo.fossil $ fossil open new-repo.fossil $ fossil status ... checkout: a26ddc725567348b47d558d4bfb807b60b529f31 2014-05-01 15:03:53 UTC parent: f1e6c85bdc0ce8cbdeca7a23d8393221e9bdc096 2014-04-30 16:18:44 UTC leaf: open tags: trunk $ date Thu May 1 15:44:44 CEST 2014 $ date -u Thu May 1 13:47:29 UTC 2014 $ touch foo $ fossil add foo ADDED foo $ fossil commit -m try to commit something ancestor check-in [a26ddc7255] (2014-05-01 13:52:04.031) is not older (clock skew?) Use --allow-older to override. --- The checkout is the result of a fresh import as per http://www.fossil-scm.org/fossil/doc/trunk/www/inout.wiki Any try to check in changes will lead to an error due to timestamp checking. Please comment, I would like to open a ticket against this change in trunk. In the meantime I will use release 1.28. Thanks and kind regards Ingo Struck ___ 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] please remove git import honours timezone from trunk
2014-05-01 15:56 GMT+02:00 Ingo Struck fos...@ingostruck.de: However, the logic that honours timezones is plain wrong and leads to a permanent error during the first hours after the checkout. Thanks for the report! This work was done by David Given d...@cowlark.com in the dg-timestamps branch: http://fossil-scm.org/index.html/timeline?r=dg-timestamps Maybe the idea is good, but the sign of the timezone correction was wrong, (Just a wild guess! ) I know nothing about Git, so I really cannot judge this. 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] 1st Call For Papers, 21th Annual Tcl/Tk Conference 2014
21'th Annual Tcl/Tk Conference (Tcl'2014) http://www.tcl.tk/community/tcl2014/ November 10 - 14, 2014 Embassy Suites Downtown Portland, Oregon, USA Important Dates: Abstracts and proposals due Sep 8, 2014 Notification to authors Sep 22, 2014 Author materials dueOct 20, 2014 Tutorials start Nov 10, 2014 Conference starts Nov 12, 2014 [[ Registration is open. ]] Email Contact:tclconfere...@googlegroups.com Submission of Summaries Tcl/Tk 2014 will be held in Portland, Oregon, USA from November 10 - 14, 2014. The program committee is asking for papers and presentation proposals from anyone using or developing with Tcl/Tk (and extensions). Past conferences have seen submissions covering a wide variety of topics including: * Scientific and engineering applications * Industrial controls * Distributed applications and Network Managment * Object oriented extensions to Tcl/Tk * New widgets for Tk * Simulation and application steering with Tcl/Tk * Tcl/Tk-centric operating environments * Tcl/Tk on small and embedded devices * Medical applications and visualization * Use of different programming paradigms in Tcl/Tk and proposals for new directions. * New areas of exploration for the Tcl/Tk language Submissions should consist of an abstract of about 100 words and a summary of not more than two pages, and should be sent as plain text to tclconference AT googlegroups DOT com no later than August 5, 2014. Authors of accepted abstracts will have until September 2, 2014 to submit their final paper for the inclusion in the conference proceedings. The proceedings will be made available on digital media, so extra materials such as presentation slides, code examples, code for extensions etc. are encouraged. Printed proceedings will be produced as an on-demand book at lulu.com The authors will have 25 minutes to present their paper at the conference. The program committee will review and evaluate papers according to the following criteria: * Quantity and quality of novel content * Relevance and interest to the Tcl/Tk community * Suitability of content for presentation at the conference Proposals may report on commercial or non-commercial systems, but those with only blatant marketing content will not be accepted. Application and experience papers need to strike a balance between background on the application domain and the relevance of Tcl/Tk to the application. Application and experience papers should clearly explain how the application or experience illustrates a novel use of Tcl/Tk, and what lessons the Tcl/Tk community can derive from the application or experience to apply to their own development efforts. Papers accompanied by non-disclosure agreements will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U. S. Copyright Act of 1976. The primary author for each accepted paper will receive registration to the Technical Sessions portion of the conference at a reduced rate. Other Forms of Participation The program committee also welcomes proposals for panel discussions of up to 90 minutes. Proposals should include a list of confirmed panelists, a title and format, and a panel description with position statements from each panelist. Panels should have no more than four speakers, including the panel moderator, and should allow time for substantial interaction with attendees. Panels are not presentations of related research papers. Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather sessions (BOFs) are available on a first-come, first-served basis. WIP slots can be reserved like any paper proposal. BOF slots will be managed on-site. All attendees with an interesting work in progress should consider reserving a WIP slot. Registration Information More information on the conference is available the conference Web site (http://www.tcl.tk/community/tcl2014/) and will be published on various Tcl/Tk-related information channels. Registration is open. To keep in touch with news regarding the conference and Tcl events in general, subscribe to the tcl-announce list. See: http://code.activestate.com/lists/tcl-announce to subscribe to the tcl-announce mailing list. Conference Committee Clif Flynt Noumena Corp General Chair, Website Admin Andreas Kupries ActiveState Software Inc. Program Chair Brian Griffin Mentor GraphicsSite/Facilities Chair Arjen MarkusDeltares Cyndy Lilagan Nat. Museum of Health Medicine, Chicago Donal Fellows University of Manchester Gerald Lester KnG Consulting, LLC Jeffrey Hobbs ActiveState Software Inc. Kevin Kenny GE Global Research Center Larry Virden Mike Doyle National Museum of Health Medicine,
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] please remove git import honours timezone from trunk
Hello Jan, On Thu, May 01, 2014 at 04:25:18PM +0200, Jan Nijtmans wrote: 2014-05-01 15:56 GMT+02:00 Ingo Struck fos...@ingostruck.de: However, the logic that honours timezones is plain wrong and leads to a permanent error during the first hours after the checkout. Thanks for the report! This work was done by David Given d...@cowlark.com in the dg-timestamps branch: http://fossil-scm.org/index.html/timeline?r=dg-timestamps Maybe the idea is good, but the sign of the timezone correction was wrong, (Just a wild guess! ) No, the idea was wrong. The calculation (sign) is correct, it yields the correct local time, but uses that value as if it was UTC. A git export line with a commit time stamp looks like this: author Foo Bar f...@example.com 1398953212 +0200 The timestamp is given in seconds since the Unix epoch, (unix time) which is a value already in UTC. The timezone information is informative. It may be used to change fossil's timezone information during import, but it must not be used to apply changes to the timestamp that is already given in UTC. Kind regards Ingo Struck ___ 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
Re: [fossil-users] please remove git import honours timezone from trunk
On 1 May 2014 15:25, Jan Nijtmans jan.nijtm...@gmail.com wrote: [...] This work was done by David Given d...@cowlark.com in the dg-timestamps branch: Are you sure that get merged? I remember asking for a sign-off a couple of times, but never got a response, and eventually abandoned it. --David (away from computer) ___ 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] please remove git import honours timezone from trunk
On 1 May 2014 21:13, Ingo Struck fos...@ingostruck.de wrote: [...] author Foo Bar f...@example.com 1398953212 +0200 The timestamp is given in seconds since the Unix epoch, (unix time) which is a value already in UTC. The timezone information is informative. It may be used to change fossil's timezone information during import, but it must not be used to apply changes to the timestamp that is already given in UTC. I originally started hacking this because I was exporting into Fossil and the timestamps weren't matching the original, so *something* is wrong somewhere. Unfortunately I'm currently camping away from my computer and can't go look up exactly what. It's possible that I was exporting from hg; in which case the bug might be on the export end. I'll try to find out more when I get back next week. --David (away from computer) ___ 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] please remove git import honours timezone from trunk
Thus said Jan Nijtmans on Thu, 01 May 2014 16:25:18 +0200: Maybe the idea is good, but the sign of the timezone correction was wrong, (Just a wild guess! ) I just tested and it's not the sign of the timezone. I created a simple git repository and then ran through fossil import --git and the resulting timestamps in the timeline were displayed with localtime, not UTC. I checked and the option to display timestamps in localtime is not enabled, so the timestamps are being stored incorrectly from the import. If I backout [1aef260f4c0] it works correctly. Andy -- TAI64 timestamp: 40005362ff7b ___ 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] please remove git import honours timezone from trunk
Thus said David Given on Thu, 01 May 2014 23:01:50 +0100: Are you sure that get merged? I remember asking for a sign-off a couple of times, but never got a response, and eventually abandoned it. It actually did get merged: http://fossil-scm.org/index.html/timeline?dp=1aef260f4c0a0fc74f45f624eb0cbe92b98bf6e8 I did some testing and it looks like fossil already had the correct timestamps. Perhaps whatever method you were using to get the data out of git was providing fossil incorrect timestamps? Andy -- TAI64 timestamp: 4000536302c3 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
