Re: [fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
While I know very little about databases, this sounds a lot like any records not found in the local database would be read from a remote database. And any writes would be to the local database with updates to the remote being managed by an explicit update procedure. And this would happen at the database level. I have no idea whether SQLite, which Fossil is built on, supports this. Also, Richard has stated that porting Fossil to use another database back end would be very difficult as Fossil relies on features specific to SQLite. I suppose that an abstraction layer could be added on top of SQLite. Such layer would attempt reads on the local database, failing over to the upstream database. But this would really be a question for Richard and the SQLite team. SQLite3 can work with multiple databases using ATTACH DATABASE. But my impression from Richard's 2.1: Scaling article is that his ideas on communicating with remote repository are mostly database-implementation independent. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
This may be related to the scaling issue, see the discussion started by Richard Hipp, entitled Fossil 2.1: Scaling. Some great ideas by Richard and very useful feature for large repositories (like Matt and Andy have). Though I think his intended goals are slightly different than what I was envisioning with cheap clone. But I don't see why I can't build on top of that. Anyway it's too early to say anything concrete as release 2.1 is in far future. I have been thinking about a project/service similar to Lagerstatte. My prototype is based on the MEAN stack and is named ammonite but the dev is on stand-by. Is the project FOSS? I'd like to see the implementation. :-) IMHO what would be a strong selling point would be to have a decentralized and distributed architecture. Think Diaspora* (https://joindiaspora.com/) but for developers. Nice idea but requires a bit more definition. Top priority atm is to get Lagerstätte in a usable state as a front-end to Fossil repositories. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Fri, 3 Apr 2015 16:15:51 +0530, Vikrant Chaudhary vikr...@webstream.io wrote: On Wed, Apr 1, 2015 at 4:21 AM, Vikrant Chaudhary vikr...@webstream.io wrote: While I know very little about databases, this sounds a lot like any records not found in the local database would be read from a remote database. And any writes would be to the local database with updates to the remote being managed by an explicit update procedure. And this would happen at the database level. I have no idea whether SQLite, which Fossil is built on, supports this. Also, Richard has stated that porting Fossil to use another database back end would be very difficult as Fossil relies on features specific to SQLite. I suppose that an abstraction layer could be added on top of SQLite. Such layer would attempt reads on the local database, failing over to the upstream database. But this would really be a question for Richard and the SQLite team. SQLite3 can work with multiple databases using ATTACH DATABASE. But my impression from Richard's 2.1: Scaling article is that his ideas on communicating with remote repository are mostly database-implementation independent. Indeed, the solution would probably be more like partial clone (full branch graph plus partial contents), followed by partial pull of contents on demand. -- Regards, Cordialement, Groet, Kees Nuyt ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
You are probably thinking about a shallow clone. You'll have to tell me what you mean by those words. Here is the concept in Git: http://stackoverflow.com/q/6941889 The impression I get is that we're both talking about the local repository containing things not sync'ed upstream, for example private branches. A bit different. In Git, this would be shallow clones vs. alternate object stores. For more information look for objects/info/alternates at http://git-scm.com/docs/gitrepository-layout ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. AFAIU what you are after is a way to optimize server side cloning (aka Github forking), that is without actually cloning the whole repository ? That would be an interesting feature indeed. This may be related to the scaling issue, see the discussion started by Richard Hipp, entitled Fossil 2.1: Scaling. I have been thinking about a project/service similar to Lagerstatte. My prototype is based on the MEAN stack and is named ammonite but the dev is on stand-by. IMHO what would be a strong selling point would be to have a decentralized and distributed architecture. Think Diaspora* (https://joindiaspora.com/) but for developers. It may be worth to try to fund your project on some crowd-funding platform (e.g. kickstarter), no ? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Wed, Apr 1, 2015 at 4:21 AM, Vikrant Chaudhary vikr...@webstream.io wrote: If users could somehow share repositories without copying them in full, that would help a lot. You are probably thinking about a shallow clone. By clone --cheap, I was thinking more along the lines of ATTACH DATABASE. I.e., collecting missing deltas from upstream db which is attached to main db. Which also means that upstream repository must exist on file-system (no http). While I know very little about databases, this sounds a lot like any records not found in the local database would be read from a remote database. And any writes would be to the local database with updates to the remote being managed by an explicit update procedure. And this would happen at the database level. I have no idea whether SQLite, which Fossil is built on, supports this. Also, Richard has stated that porting Fossil to use another database back end would be very difficult as Fossil relies on features specific to SQLite. I suppose that an abstraction layer could be added on top of SQLite. Such layer would attempt reads on the local database, failing over to the upstream database. But this would really be a question for Richard and the SQLite team. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. If users could somehow share repositories without copying them in full, that would help a lot. You are probably thinking about a shallow clone. By clone --cheap, I was thinking more along the lines of ATTACH DATABASE. I.e., collecting missing deltas from upstream db which is attached to main db. Which also means that upstream repository must exist on file-system (no http). This may or may not be very useful for end users, but is tremendously important for a service like Lagerstätte. Consider this repository https://github.com/torvalds/linux It has ~8000 forks on Github. Assuming the original repository size is 100MiB (a guess). Without cheap forks, ~8000 forks would require ~800GiB of space. With cheap forks, probably 200MiB. Truth is, I need to understand more about Fossil internals to make any assertions on what is possible and what is not. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
I'm not a German speaker, and I don't know if you care, but I would vote with Joerg to use ae rather than just a. (Simply ignoring the umlaut seem just wrong - regardless of Google.) FWIW, the two dots in ä and ö derive historically from a small e placed above the letters a and o. Also, German proper names that contained an umlaut are regularly spelled with the e (at least in the mid-western US). I do care. I've been thinking about this, and have decided to add the missing e. Effective immediately, name of the project is Lagerstätte, with official ASCII normalisation being Lagerstaette. Updated links: Web/Fossil: https://codeflow.io/lagerstaette/lagerstaette Git: https://git.codeflow.io/lagerstaette/lagerstaette Mailing list: https://groups.google.com/forum/#!forum/lagerstaette (name change in the code is pending, I'll get to it later). ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
In the actual code or in string constants? If in string constants, why not use the ISO-8859-1 encoding? Or even Unicode? As long as your software sets the character set parameter in the HTTP header, this should display correctly. Example: Content-Type: text/html; charset=iso-8859-1 or: Content-Type: text/html; charset=utf-8 An ASCII approximation is still needed. Sometimes, character restriction is not under your control. E.g., registering an email address (at a third-party provider) for the project. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote: I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. If users could somehow share repositories without copying them in full, that would help a lot. You are probably thinking about a shallow clone. You'll have to tell me what you mean by those words. By clone --cheap, I was thinking more along the lines of ATTACH DATABASE. I.e., collecting missing deltas from upstream db which is attached to main db. Which also means that upstream repository must exist on file-system (no http). The impression I get is that we're both talking about the local repository containing things not sync'ed upstream, for example private branches. Truth is, I need to understand more about Fossil internals to make any assertions on what is possible and what is not. This is a dramatic departure from the current design of Fossil which directly opens the repository file, which is an SQLite database. What you suggest would require frequent communication with the repository at the remote-url for doing many kinds of read operations. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Wed, Apr 1, 2015 at 6:55 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote: I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. I'm supporting a group with over 500 fossils, hundreds of checkins per day. All on NFS. There have been issues but few due to NFS locking. The central files are accessed via ssh. I do wish fossil supported a model where multiple users could do fossil open off of a single fossil db. The distributed quality of fossil is the feature we leverage least and the feature that causes the most issues (forks are very confusing for casual users of fossil). If users could somehow share repositories without copying them in full, that would help a lot. You are probably thinking about a shallow clone. You'll have to tell me what you mean by those words. By clone --cheap, I was thinking more along the lines of ATTACH DATABASE. I.e., collecting missing deltas from upstream db which is attached to main db. Which also means that upstream repository must exist on file-system (no http). The impression I get is that we're both talking about the local repository containing things not sync'ed upstream, for example private branches. I see clone --cheap as being about keeping most of the blobs in a central fossil and having a side sqlite db that contains only the extra blobs as committed to the cheap clone. You see the entire clone by ATTACHING the two dbs. I'm not saying this implementation idea would work (although I suspect it might) - only that it illustrates the principle being sought after. Truth is, I need to understand more about Fossil internals to make any assertions on what is possible and what is not. This is a dramatic departure from the current design of Fossil which directly opens the repository file, which is an SQLite database. What you suggest would require frequent communication with the repository at the remote-url for doing many kinds of read operations. -- 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On 30 March 2015 at 17:39, j. van den hoff veedeeh...@googlemail.com wrote: a marginal point, but in case you care: the german word for repository/deposit actually is Lagerstätte where the diacritical mark over the `a' really matters. but Lagerstatte sounds really awful (since the a is pronounced like the u in the English word `up', while the ä is similarly pronounced to English a in action). and it simply looks misspelled ;-). it also seems not to belong to the words having been assimilated into english after spelling changes (such as iceberg) as far as I know. to make german users a bit more happy you might call it lagerstaette where the `ae' is a widely used ASCII approximation of the ä (in germany, anyway). also note, that Lagerstatt (the singular form of Lagerstätten (with final n)) is an exalted way of denoting a bed (and not a place were to store fossils (or beer ;-)). overall, I'm not sure whether the name choice was a lucky one... Regarding name: What we have considered so far: * Germans prefer to transliterate ä to ae. * Google tries to correct lagerstaette to lagerstatte. * Google includes results for lagerstätte when searching for lagerstatte (but not with lagerstaette). * https://ssl.icu-project.org/icu-bin/translit transliterates ä to a (use Latin - ASCII settings). * This Rails method does the same - ä to a- http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html#method-i-transliterate * German borrowed words in English usually do not use the e form. Like Über to Uber, Flügelhorn to Flugelhorn, Lämmergeier to Lammergeier, https://en.wiktionary.org/wiki/Frau from Fräulein, Grossencharakter from Größencharakter. * There are a few counter examples though - Fuehrer from Führer, Muesli from Müsli, Loess from Löß, Foehn from Föhn. * 29,400 Google search results for lagerstatte (with quotes) vs 8990 for lagerstaette (with quotes). (for completeness, 3,89,000 results for lagerstätte (with quotes)). * Almost all search results for lagerstaette are in German, and in English for lagerstatte. * Our conclusion: lagerstaette when transliterating in German, lagerstatte when transliterating in English. * I'm still not 100% sure. Maybe I should roll with Lagerstätte as project's name, but we still need the ASCII approximation to use in code. regards/joerg On Mon, 30 Mar 2015 12:50:54 +0200, Vikrant Chaudhary vikr...@webstream.io wrote: Hello everyone, I've been working on a project named Lagerstatte, a front-end for Fossil repositories. The browser facing part is written in Ember.js, while server runs a Ruby on Rails application which acts as a JSON endpoint. Access to Fossil database is provided by Stephan's excellent libfossil library. I'd also like to emphasise that this a very early announcement. The project is far from even a beta stage. With this email, my sole intention is to make Fossil community aware of the project. Lagerstatte is a work-in-progress and may do anything it likes up to and including eating your laundry. Features that you can evaluate today: * Navigating through files. * Viewing latest revision of wiki pages. * Access the Fossil repositories through Git protocol (readonly). Planned features: * Installation instructions documentations. * on-premise behind-firewall installations. * Fully featured code, wiki, and issues management. * Email notifications. * LDAP / OpenID Connect authentication. * Searching across multiple repositories. * Basic elements of social networking project discovery. * Unified login across all repositories. * One-click repository setup. * Fault-tolerant and high-availability storage of Fossil repositories. * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). * Cross-fork merge-requests. * API, Notifications, Webhooks, OAuth for integration with third-parties. * Graphs Statistics. A preview of Lagerstatte-in-action is available at https://codeflow.io/ Lagerstatte: Web/Fossil: https://codeflow.io/lagerstatte/lagerstatte Git: http://git.codeflow.io/lagerstatte/lagerstatte fossil_ruby: (a Ruby wrapper for libfossil) Web/Fossil: https://codeflow.io/lagerstatte/fossil_ruby Git: http://git.codeflow.io/lagerstatte/fossil_ruby libfossil: Web/Fossil: https://codeflow.io/libfossil/libfossil Git: http://git.codeflow.io/libfossil/libfossil Fossil: Web: https://codeflow.io/fossil/fossil Git/Fossil: Too awesome to handle by currently inefficient git conversion code. I've some ideas on improving this, which I'm working on. I'll be adding more repositories soon to the list (SQLite3, SQLite4, Tcl, Tk, and more). If you'd like to see your repository at Codeflow, let me know. Subscribe to mailing-list for discussions and development updates! https://groups.google.com/forum/#!forum/lagerstatte Feedback, suggestions, and contributions are welcome. About name: A Lagerstätte is a sedimentary deposit that exhibits extraordinary fossils with exceptional
Re: [fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Mon, Mar 30, 2015 at 10:57 PM, Vikrant Chaudhary vikr...@webstream.io wrote: fossil clone --cheap file:///path/to/upstream.fossil new-project.fossil +1 I think I would use this feature should it ever come available. I have 500M+ repos where a cheap clone would be quite nice to have. I assume the feature would work whether the upstream fossil was read only or not. The benefit would be a clone that takes a few seconds rather than several minutes. ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On 3/31/2015 11:18 PM, Matt Welland wrote: On Mon, Mar 30, 2015 at 10:57 PM, Vikrant Chaudhary vikr...@webstream.io wrote: fossil clone --cheap file:///path/to/upstream.fossil new-project.fossil +1 I think I would use this feature should it ever come available. I have 500M+ repos where a cheap clone would be quite nice to have. I assume the feature would work whether the upstream fossil was read only or not. The benefit would be a clone that takes a few seconds rather than several minutes. I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. If users could somehow share repositories without copying them in full, that would help a lot. A simple test showing how Fossil repositories cannot be shared is to attempt running two [fossil open] commands simultaneously. With small projects this is hard to do, but you can just hit Ctrl-Z during the first to make it take as long as you want. With projects such as those I work on, [fossil open] takes a few minutes because (1) there's gigabytes of stuff being written out, and (2) we're always stuck with obsolete computers. So sharing any given repository file is clearly out of the question. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
Vikrant Chaudhary wrote: On 30 March 2015 at 17:39, j. van den hoff veedeeh...@googlemail.com wrote: a marginal point, but in case you care: the german word for repository/deposit actually is Lagerstätte where the diacritical mark over the `a' really matters. but Lagerstatte sounds really awful (since the a is pronounced like the u in the English word `up', while the ä is similarly pronounced to English a in action). and it simply looks misspelled ;-). it also seems not to belong to the words having been assimilated into english after spelling changes (such as iceberg) as far as I know. to make german users a bit more happy you might call it lagerstaette where the `ae' is a widely used ASCII approximation of the ä (in germany, anyway). also note, that Lagerstatt (the singular form of Lagerstätten (with final n)) is an exalted way of denoting a bed (and not a place were to store fossils (or beer ;-)). overall, I'm not sure whether the name choice was a lucky one... Regarding name: What we have considered so far: * Germans prefer to transliterate ä to ae. * Google tries to correct lagerstaette to lagerstatte. * Google includes results for lagerstätte when searching for lagerstatte (but not with lagerstaette). * https://ssl.icu-project.org/icu-bin/translit transliterates ä to a (use Latin - ASCII settings). * This Rails method does the same - ä to a- http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html#method-i-transliterate * German borrowed words in English usually do not use the e form. Like Über to Uber, Flügelhorn to Flugelhorn, Lämmergeier to Lammergeier, https://en.wiktionary.org/wiki/Frau from Fräulein, Grossencharakter from Größencharakter. * There are a few counter examples though - Fuehrer from Führer, Muesli from Müsli, Loess from Löß, Foehn from Föhn. * 29,400 Google search results for lagerstatte (with quotes) vs 8990 for lagerstaette (with quotes). (for completeness, 3,89,000 results for lagerstätte (with quotes)). * Almost all search results for lagerstaette are in German, and in English for lagerstatte. * Our conclusion: lagerstaette when transliterating in German, lagerstatte when transliterating in English. * I'm still not 100% sure. Maybe I should roll with Lagerstätte as project's name, but we still need the ASCII approximation to use in code. I'm not a German speaker, and I don't know if you care, but I would vote with Joerg to use ae rather than just a. (Simply ignoring the umlaut seem just wrong - regardless of Google.) FWIW, the two dots in ä and ö derive historically from a small e placed above the letters a and o. Also, German proper names that contained an umlaut are regularly spelled with the e (at least in the mid-western US). -- Will ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Tue, Mar 31, 2015 at 2:16 AM, Vikrant Chaudhary vikr...@webstream.io wrote: Maybe I should roll with Lagerstätte as project's name, but we still need the ASCII approximation to use in code. In the actual code or in string constants? If in string constants, why not use the ISO-8859-1 encoding? Or even Unicode? As long as your software sets the character set parameter in the HTTP header, this should display correctly. Example: Content-Type: text/html; charset=iso-8859-1 or: Content-Type: text/html; charset=utf-8 ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
a marginal point, but in case you care: the german word for repository/deposit actually is Lagerstätte where the diacritical mark over the `a' really matters. but Lagerstatte sounds really awful (since the a is pronounced like the u in the English word `up', while the ä is similarly pronounced to English a in action). and it simply looks misspelled ;-). it also seems not to belong to the words having been assimilated into english after spelling changes (such as iceberg) as far as I know. to make german users a bit more happy you might call it lagerstaette where the `ae' is a widely used ASCII approximation of the ä (in germany, anyway). also note, that Lagerstatt (the singular form of Lagerstätten (with final n)) is an exalted way of denoting a bed (and not a place were to store fossils (or beer ;-)). overall, I'm not sure whether the name choice was a lucky one... regards/joerg On Mon, 30 Mar 2015 12:50:54 +0200, Vikrant Chaudhary vikr...@webstream.io wrote: Hello everyone, I've been working on a project named Lagerstatte, a front-end for Fossil repositories. The browser facing part is written in Ember.js, while server runs a Ruby on Rails application which acts as a JSON endpoint. Access to Fossil database is provided by Stephan's excellent libfossil library. I'd also like to emphasise that this a very early announcement. The project is far from even a beta stage. With this email, my sole intention is to make Fossil community aware of the project. Lagerstatte is a work-in-progress and may do anything it likes up to and including eating your laundry. Features that you can evaluate today: * Navigating through files. * Viewing latest revision of wiki pages. * Access the Fossil repositories through Git protocol (readonly). Planned features: * Installation instructions documentations. * on-premise behind-firewall installations. * Fully featured code, wiki, and issues management. * Email notifications. * LDAP / OpenID Connect authentication. * Searching across multiple repositories. * Basic elements of social networking project discovery. * Unified login across all repositories. * One-click repository setup. * Fault-tolerant and high-availability storage of Fossil repositories. * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). * Cross-fork merge-requests. * API, Notifications, Webhooks, OAuth for integration with third-parties. * Graphs Statistics. A preview of Lagerstatte-in-action is available at https://codeflow.io/ Lagerstatte: Web/Fossil: https://codeflow.io/lagerstatte/lagerstatte Git: http://git.codeflow.io/lagerstatte/lagerstatte fossil_ruby: (a Ruby wrapper for libfossil) Web/Fossil: https://codeflow.io/lagerstatte/fossil_ruby Git: http://git.codeflow.io/lagerstatte/fossil_ruby libfossil: Web/Fossil: https://codeflow.io/libfossil/libfossil Git: http://git.codeflow.io/libfossil/libfossil Fossil: Web: https://codeflow.io/fossil/fossil Git/Fossil: Too awesome to handle by currently inefficient git conversion code. I've some ideas on improving this, which I'm working on. I'll be adding more repositories soon to the list (SQLite3, SQLite4, Tcl, Tk, and more). If you'd like to see your repository at Codeflow, let me know. Subscribe to mailing-list for discussions and development updates! https://groups.google.com/forum/#!forum/lagerstatte Feedback, suggestions, and contributions are welcome. About name: A Lagerstätte is a sedimentary deposit that exhibits extraordinary fossils with exceptional preservation. - https://en.wikipedia.org/wiki/Lagerstätte Stephan and me had a lengthy discussion on transliteration of Lagerstätte to ASCII. Candidates were Lagerstaette and Lagerstatte. (more context: http://german.stackexchange.com/q/4992). Following up on the trend of several previous German loanwords in English, we decided to go with Lagerstatte. Cheers. - Vikrant ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
Minor grammatical correction in last email: s/Stephan and me/Stephan and I/ On 30 March 2015 at 16:20, Vikrant Chaudhary vikr...@webstream.io wrote: Hello everyone, I've been working on a project named Lagerstatte, a front-end for Fossil repositories. The browser facing part is written in Ember.js, while server runs a Ruby on Rails application which acts as a JSON endpoint. Access to Fossil database is provided by Stephan's excellent libfossil library. I'd also like to emphasise that this a very early announcement. The project is far from even a beta stage. With this email, my sole intention is to make Fossil community aware of the project. Lagerstatte is a work-in-progress and may do anything it likes up to and including eating your laundry. Features that you can evaluate today: * Navigating through files. * Viewing latest revision of wiki pages. * Access the Fossil repositories through Git protocol (readonly). Planned features: * Installation instructions documentations. * on-premise behind-firewall installations. * Fully featured code, wiki, and issues management. * Email notifications. * LDAP / OpenID Connect authentication. * Searching across multiple repositories. * Basic elements of social networking project discovery. * Unified login across all repositories. * One-click repository setup. * Fault-tolerant and high-availability storage of Fossil repositories. * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). * Cross-fork merge-requests. * API, Notifications, Webhooks, OAuth for integration with third-parties. * Graphs Statistics. A preview of Lagerstatte-in-action is available at https://codeflow.io/ Lagerstatte: Web/Fossil: https://codeflow.io/lagerstatte/lagerstatte Git: http://git.codeflow.io/lagerstatte/lagerstatte fossil_ruby: (a Ruby wrapper for libfossil) Web/Fossil: https://codeflow.io/lagerstatte/fossil_ruby Git: http://git.codeflow.io/lagerstatte/fossil_ruby libfossil: Web/Fossil: https://codeflow.io/libfossil/libfossil Git: http://git.codeflow.io/libfossil/libfossil Fossil: Web: https://codeflow.io/fossil/fossil Git/Fossil: Too awesome to handle by currently inefficient git conversion code. I've some ideas on improving this, which I'm working on. I'll be adding more repositories soon to the list (SQLite3, SQLite4, Tcl, Tk, and more). If you'd like to see your repository at Codeflow, let me know. Subscribe to mailing-list for discussions and development updates! https://groups.google.com/forum/#!forum/lagerstatte Feedback, suggestions, and contributions are welcome. About name: A Lagerstätte is a sedimentary deposit that exhibits extraordinary fossils with exceptional preservation. - https://en.wikipedia.org/wiki/Lagerstätte Stephan and me had a lengthy discussion on transliteration of Lagerstätte to ASCII. Candidates were Lagerstaette and Lagerstatte. (more context: http://german.stackexchange.com/q/4992). Following up on the trend of several previous German loanwords in English, we decided to go with Lagerstatte. Cheers. - Vikrant ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
Hello everyone, I've been working on a project named Lagerstatte, a front-end for Fossil repositories. The browser facing part is written in Ember.js, while server runs a Ruby on Rails application which acts as a JSON endpoint. Access to Fossil database is provided by Stephan's excellent libfossil library. I'd also like to emphasise that this a very early announcement. The project is far from even a beta stage. With this email, my sole intention is to make Fossil community aware of the project. Lagerstatte is a work-in-progress and may do anything it likes up to and including eating your laundry. Features that you can evaluate today: * Navigating through files. * Viewing latest revision of wiki pages. * Access the Fossil repositories through Git protocol (readonly). Planned features: * Installation instructions documentations. * on-premise behind-firewall installations. * Fully featured code, wiki, and issues management. * Email notifications. * LDAP / OpenID Connect authentication. * Searching across multiple repositories. * Basic elements of social networking project discovery. * Unified login across all repositories. * One-click repository setup. * Fault-tolerant and high-availability storage of Fossil repositories. * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). * Cross-fork merge-requests. * API, Notifications, Webhooks, OAuth for integration with third-parties. * Graphs Statistics. A preview of Lagerstatte-in-action is available at https://codeflow.io/ Lagerstatte: Web/Fossil: https://codeflow.io/lagerstatte/lagerstatte Git: http://git.codeflow.io/lagerstatte/lagerstatte fossil_ruby: (a Ruby wrapper for libfossil) Web/Fossil: https://codeflow.io/lagerstatte/fossil_ruby Git: http://git.codeflow.io/lagerstatte/fossil_ruby libfossil: Web/Fossil: https://codeflow.io/libfossil/libfossil Git: http://git.codeflow.io/libfossil/libfossil Fossil: Web: https://codeflow.io/fossil/fossil Git/Fossil: Too awesome to handle by currently inefficient git conversion code. I've some ideas on improving this, which I'm working on. I'll be adding more repositories soon to the list (SQLite3, SQLite4, Tcl, Tk, and more). If you'd like to see your repository at Codeflow, let me know. Subscribe to mailing-list for discussions and development updates! https://groups.google.com/forum/#!forum/lagerstatte Feedback, suggestions, and contributions are welcome. About name: A Lagerstätte is a sedimentary deposit that exhibits extraordinary fossils with exceptional preservation. - https://en.wikipedia.org/wiki/Lagerstätte Stephan and me had a lengthy discussion on transliteration of Lagerstätte to ASCII. Candidates were Lagerstaette and Lagerstatte. (more context: http://german.stackexchange.com/q/4992). Following up on the trend of several previous German loanwords in English, we decided to go with Lagerstatte. Cheers. - Vikrant ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On Mon, Mar 30, 2015 at 6:50 AM, Vikrant Chaudhary vikr...@webstream.io wrote: Hello everyone, I've been working on a project named Lagerstatte, a front-end for Fossil repositories. Looks interesting. Features that you can evaluate today: * Navigating through files. * Viewing latest revision of wiki pages. * Access the Fossil repositories through Git protocol (readonly). Intellectually interesting, but, for me, not a selling point as I only use Git when I have to. Planned features: ... * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). Do you mean cheep cloning? (In Fossil, the term fork is used to describe an accidental branch created when multiple commits are made against the same parent. I don't know what other DVCSs call them.) * Cross-fork merge-requests. Do you mean pull requests? ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
* Access the Fossil repositories through Git protocol (readonly). Intellectually interesting, but, for me, not a selling point as I only use Git when I have to. There are lots of software and services that support Git out of the box (e.g., CI services, Go's packages, Rust's crates, Ruby's bundler etc.). And I think this eventually becomes a reason to _not_ use Fossil for projects that need to integrate with these software/services. With a git-protocol layer, I hope to lower down that obstacle. * Cheap forking (I have some ideas on how to achieve this in Fossil/libfossil). Do you mean cheep cloning? (In Fossil, the term fork is used to describe an accidental branch created when multiple commits are made against the same parent. I don't know what other DVCSs call them.) I meant forking in the traditional FOSS sense. Like Ubuntu is a fork of Debian. This one: https://en.wikipedia.org/wiki/Fork_%28software_development%29 By cheap, I mean, Given upstream.fossil which is 1GiB in size fossil clone --cheap file:///path/to/upstream.fossil new-project.fossil results in new-project.fossil which is just a few MiB or less, and it uses upstream.fossil to lookup missing deltas (of course path of upstream.fossil must not change). Git has same concept of alternate object stores. * Cross-fork merge-requests. Do you mean pull requests? Yes. ___ 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
