Re: [fossil-users] missing initial empty check-in repository from import
Thus said Jan Nijtmans on Fri, 13 Mar 2015 16:28:47 +0100: Another way to trigger the 'problem' is using fossil reconstruct. This function reconstructs the repository from artifacts on disk, it is very unlikely that the initial empty checkin is encountered as first artifact and given rid=1. I couldn't cause this problem with 1.27 using fossil reconstruct. Perhaps I'm missing something? With Fossil 1.27 I created a new fossil, opened it, added a file, then deconstructed it, reconstructed it, opened the reconstructed fossil and I see everything as I should. I then cloned the reconstructed fossil with Fossil 1.27 and it also had everything as it should. You are correct that rid=1 is not the initial empty checkin after reconstruction, but that doesn't seem to have made a difference. So what exactly is it about Fossil 1.27 that chokes on a repository that doesn't have the ``initial empty check-in'', but which, nevertheless, does have checkins? Here is the original: $ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid ORDER BY rid; | ./fossil sql -R new.fossil 1|5c404e9b8a1f0f522d35311520e1898b45595933|ci|initial empty check-in 3|cb04d5b9c26790dcc4bbdc90d8cd11011756b04f|ci|one Here is the reconstructed: $ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid ORDER BY rid; | ./fossil sql -R recon.fossil 1|cb04d5b9c26790dcc4bbdc90d8cd11011756b04f|ci|one 3|5c404e9b8a1f0f522d35311520e1898b45595933|ci|initial empty check-in Thanks, Andy -- TAI64 timestamp: 400055033a31 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New skin: Blitz
Hello Fossil community, My name is James and I am not a Fossil user, I'm a git user. I also happen to run a moderately successful on-premise Git server project not unlike Fossil, http://gitblit.com. But that is not why I am writing you. I've long been an admirer of Fossil's integrated approach and I periodically check-in to see how things are moving along in this project. I see that in the last few releases Fossil has been getting a lot more competent and that is great. I decided to make some time to play with your DVCS (being a fan of SCM) and to whip-up a new skin accompanying resources to contribute to your effort. This theme, Blitz, is demonstrated here: http://dev.gitblit.com:8080/cgi-bin/repo/fossil http://dev.gitblit.com:8080/cgi-bin/repo/sqlite If you've ever seen Gitblit, then this theme will feel comfortable, although it is specialized for Fossil and shares little of the same CSS code. Blitz has two variants (with logo without logo). It includes an alternative Ticket page layout and several image resources which may be of use to other skins. @Richard: I've emailed a signed CLA and a bundle for your review and integration consideration. I hope to contribute more in the future. -J ___ 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] Google code shutting down
On 3/13/15, bch brad.har...@gmail.com wrote: I am sure that Git has massive advantages for some people, particularly for large projects with huge numbers of collaborators. As Stephan Beal has previously pointed out, Git is *designed* to forget things. This is a feature of Git, not a bug. Linus does not want to see every edit made by every Linux contributor. Git is designed so that extraneous branches can be filtered from the permanent record, retaining only the main line of development. Git features rebase to help with this filtering task. In a project with as many contributors of varying skill levels as Linux, you really have to do it that way, otherwise the complexity becomes disabling. Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs. So Git and Fossil are somewhat at cross-purposes. Fossil is inappropriate for use on Linux and Git is inappropriate for use on SQLite. (Please note that while Linux is a larger project with more developers and more prestige, there are in fact more instances of SQLite running in the wild than there are of Linux.) So, yes, nobody is suggesting that projects like Linux should use Fossil. But on the other hand, not many projects have as big a developer base as does Linux. I content that Fossil is a better choice for the vast majority of FOSS projects. Fossil is easier to use. (Even Git advocates admit as much!) Fossil does not forget. With Fossil it is impossible to get into detached head state. -- 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] Google code shutting down
That above quote looks to be attributed to me, but is in fact me quoting http://pietersz.co.uk/2015/03/fossil-vs-git :) , -bch On 3/13/15, Richard Hipp d...@sqlite.org wrote: On 3/13/15, bch brad.har...@gmail.com wrote: I am sure that Git has massive advantages for some people, particularly for large projects with huge numbers of collaborators. As Stephan Beal has previously pointed out, Git is *designed* to forget things. This is a feature of Git, not a bug. Linus does not want to see every edit made by every Linux contributor. Git is designed so that extraneous branches can be filtered from the permanent record, retaining only the main line of development. Git features rebase to help with this filtering task. In a project with as many contributors of varying skill levels as Linux, you really have to do it that way, otherwise the complexity becomes disabling. Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs. So Git and Fossil are somewhat at cross-purposes. Fossil is inappropriate for use on Linux and Git is inappropriate for use on SQLite. (Please note that while Linux is a larger project with more developers and more prestige, there are in fact more instances of SQLite running in the wild than there are of Linux.) So, yes, nobody is suggesting that projects like Linux should use Fossil. But on the other hand, not many projects have as big a developer base as does Linux. I content that Fossil is a better choice for the vast majority of FOSS projects. Fossil is easier to use. (Even Git advocates admit as much!) Fossil does not forget. With Fossil it is impossible to get into detached head state. -- 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] Google code shutting down
On Mar 13, 2015, at 11:38 AM, Richard Hipp d...@sqlite.org wrote: not many projects have as big a developer base as does Linux. The key thing about Linux’s contributor base isn’t so much its size as its distributedness and hierarchical contribution paths. I’m sure other projects have as many or more lines of code per year going into them. The Windows kernel must, for example, as must the BSDs, since those repos hold more than just a kernel. The thing about most other large projects is that they do not have this highly-distributed hierarchical contribution model. You’re either one of the trusted few with a commit bit, or you are not. Few organizations have the problem that the full power of Git solves. ___ 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] Google code shutting down
On Fri, Mar 13, 2015 at 01:50:19PM -0600, Warren Young wrote: The thing about most other large projects is that they do not have this highly-distributed hierarchical contribution model. You’re either one of the trusted few with a commit bit, or you are not. Actually, I think it is the other way around. Few large projects have such large trust issues, that so few people are effectively allowed to commit. Few organizations have the problem that the full power of Git solves. ...or create ;) Joerg ___ 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] Google code shutting down
On 14/03/15 01:34, Warren Young wrote: On Mar 13, 2015, at 1:59 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Fri, Mar 13, 2015 at 01:50:19PM -0600, Warren Young wrote: The thing about most other large projects is that they do not have this highly-distributed hierarchical contribution model. You’re either one of the trusted few with a commit bit, or you are not. Actually, I think it is the other way around. Few large projects have such large trust issues, that so few people are effectively allowed to commit. Yes, Git is uncommon in supporting a federated development style, which is what allows “Fork me on Github” to work. Fossil now partly solves that with bundles, but there is still a stark inside/outside dividing line. So, here’s my new overly simplified categorical statement: Few organizations require federated development. :) Lots of organisations have open source projects and want outside collaborators. Fork me on Github makes it easy for potential collaborators. ___ 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] missing initial empty check-in repository from import
On Fri, Mar 13, 2015 at 4:28 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2015-03-13 15:56 GMT+01:00 Marcel Graf graf.m.ml+sbf...@gmail.com: Well, to kind of answer my own question: I tried it, and yes, it happens too. Only using fossil version 1.27! Interesting. Thanks! Another way to trigger the 'problem' is using fossil reconstruct. This function reconstructs the repository from artifacts on disk, it is very unlikely that the initial empty checkin is encountered as first artifact and given rid=1. So, if the requirement is that rid=1 must contain the manifest of the initial empty check-in, the fossil reconstruct command builds an incompatible repository by design :-) Talking about reconstruct: I tried it on my little test-case (git fast-export dump). It results in only 2 blobs, the one-and-only check-in manifest and one file. It happens to be that the sha1 of the file is lexicographically after the one of the manifest, so doing a deconstruct/reconstruct cycle should swap rid=1 and rid=2. Let's see: $ fossil-1.27 import git-one.fossil git-one.dump $ mkdir bag-of-blobs $ fossil-1.27 deconstruct -R git-one.fossil bag-of-blobs/ $ fossil-1.27 reconstruct git-one-reconstructed.fossil bag-of-blobs/ $ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid ORDER BY rid; | fossil-1.27 sql -R git-one.fossil 2|5f10a7565281c4990391d84cfd2041d110e7ebda|ci|One-and-only checkin $ echo SELECT rid,uuid,type,comment FROM blob, event WHERE rid = objid ORDER BY rid; | fossil-1.27 sql -R git-one-reconstructed.fossil 1|5f10a7565281c4990391d84cfd2041d110e7ebda|ci|One-and-only checkin Ok, swapped. Try the original $ mkdir wd cd wd $ fossil-1.27 open ../git-one.fossil $ ls -- nothing $ fossil-1.27 up --- checkout: d6f7066dea999212dc6834e6eebab22b50965f8e changes: None. Already up-to-date $ ls -- still nothing, but d6f7066dea999212dc6834e6eebab22b50965f8e is the hash of the file content $ echo foo bar.txt $ fossil-1.27 add bar.txt ADDED bar.txt $ fossil-1.27 ci -m some commit -nC some\scommit D 2015-03-13T20:45:49.329 F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 P d6f7066dea999212dc6834e6eebab22b50965f8e R db8001820cefce732098cd62df1a5d76 U marcel Z e41d91f888e731e0a23a829571f2fbe8 New_Version: 61bc5e03e1322f0c24d21f997abc0dd1627ca88b -- BAD: the file is the parent of this commit. And creates the disconnected check-in Now try the reconstructed $ mkdir wdr cd wdr $ fossil-1.27 open ../git-one-reconstructed.fossil $ ls -- nothing $ fossil-1.27 upUPDATE a-file.txt --- updated-to: 5f10a7565281c4990391d84cfd2041d110e7ebda 2015-03-13 14:12:38 UTC tags: trunk comment: One-and-only checkin (user: mys...@me.com) changes: 1 file modified. fossil undo is available to undo changes to the working checkout. -- ok, needed an update, but file is there, parent hash is good $ echo foo bar.txt $ fossil-1.27 add bar.txt ADDED bar.txt $ fossil-1.27 ci -m some commit -nC some\scommit D 2015-03-13T20:48:03.205 F a-file.txt d6f7066dea999212dc6834e6eebab22b50965f8e F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 P 5f10a7565281c4990391d84cfd2041d110e7ebda R a77ec06fd6931041eab215d2061054ac U marcel Z 5b900413bded470209bd9c1243ce8687 New_Version: 02667c37bc607d0247726ff00475ace69555c52d -- GOOD, parent is right So having a valid check-in manifest on rid=1 and an update helped. The same without the update: $ mkdir wdr cd wdr $ fossil-1.27 open ../git-one-reconstructed.fossil $ ls -- nothing, lets add and commit anyway $ echo foo bar.txt $ fossil-1.27 add bar.txt ADDED bar.txt $ fossil-1.27 ci -m some commit -nC some\scommit C some\scommit D 2015-03-13T20:51:04.185 F bar.txt f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 P 5f10a7565281c4990391d84cfd2041d110e7ebda R db8001820cefce732098cd62df1a5d76 U marcel Z d73b87e120a06d518c48605427deeef3 New_Version: 10450abbbd09b4b9e1dafb15c696a20a140fba6e -- got the parent right, but is missing the first file (shows up as deleted) [image: Inline image 1] which seems to match the entry in the release notes for 1.32: ... by having a valid manifest as RID 1. Or, if you happen to get a non-manifest blob on rid=1 with reconstruct, it might go bad. Although, doing the import with two git-commits, I got the check-in manifest on rid=2 and rid=4 (1 and 3 being files) but everything is ok there. So it seems to be something like having only one check-in _and_ its manifest not on rid=1 is not handled right by fossil 1.27. And you can't get into that with an initial empty checkin: As there you have either only exactly on blob (the initial checkin) and reconstruct will still put in on rid=1 (no other choice), or you have more check-ins (and files), but then it does no longer matter ... Which also explains why nobody noticed the problem by using import (other than nobody using it at all?), as
Re: [fossil-users] Google code shutting down
On Mar 13, 2015, at 6:40 AM, Graeme Pietersz gra...@pietersz.net wrote: My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. Some critiques: 1. The post is visually divided into two sections, pro-Fossil and pro-Git, but the actual prose frequently intermixes positives of both. You should separate the two. Cover all the things that are great about Fossil in the first section, then explain in the second why you choose to use Git despite Fossil’s advantages. The biggest example of this is your 2-point numbered list in the first section. If it were my post, I’d just fold these two points into the “one big advantage” section following the pro-Fossil section. If you’d rather discuss tools and services in a separate section, that’s fine, but as it is, your post feels more like a brain dump than reasoned exposition. 2. Linux is not “the largest software project ever.” Not even close. Windows’ code base is ~3 times larger. Visual Studio and MS Office are each about twice as large as Linux. The highly-successful Alcatel-Lucent 5ESS telephone switching system was last reported to clock in at over 100 MSLOC. [1] Healthcare.gov was reported at 500 MSLOC, making it about 28x bigger! [2] 3. I rarely use Git, and never speak more than pidgin Git to it, so perhaps I am just ignorant about some fact about the Git GUI situation, but I can’t see why you ding Gitk but then later in the post praise Gitg. It feels like you’re going out of your way to find bad things about Git which have been fixed elsewhere. Is there a good reason not to just ignore the existence of Gitk? I’m all for Fossil boosting, but I don’t see a reason to manufacture negatives for Git. It already has enough genuine negatives to sink it, in my book. :) 4. Regarding email integration, I don’t blame Fossil for not tackling this one. The hosted VCS services have an advantage in that their sysadmins work out how to connect up to the public email system. Even at its best — as seen in popular GUI email programs — an email server connection can be difficult to set up. To even get that far, you have to write a whole lot of automated probing code to work out which security features some particular email server has, whether the username has an @ sign in it or not, whether it wants incoming email on port 25, 587, 465, 475, or 2525, etc. Email is a hot mess. My point is that you’re kind of mixing apples and oranges here, as well as in other areas. Your comparison should separate Git vs Fossil from ChiselApp/self-hosting vs Github. Yes, I know, ChiselApp still doesn’t compare to Github, so Git will continue to come out on top in that comparison. However, this is still the only fair comparison. Also, I believe that once you extract the hosting services from the comparison, Fossil comes out quite a bit ahead of Git. 5. You’re missing one of Fossil’s advantages: truly private project hosting, as opposed to “We think it’s private, but there hasn’t been a publicized hack on Github yet” semi-private hosting. A lot of organizations are going to be unwilling to pay for “private” hosting at Github or BitBucket for that reason alone. That’s true here, for one. What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? 6. There are cases where Fossil’s single-executable philosophy really matters. The ones I’ve run into amounted to cross-compiling: it’s easier to build an ARM executable for a Chromebook or Raspberry Pi and copy just that across than to set up a whole cross-compilation toolchain complete with shared libraries, package managers, etc., then ship some massive bolus-of-code over to the other platform and unpack it there. You don’t always get the luxury of building on the target platform. ChromeOS doesn’t even come with compilers. [1] That’s probably significantly outdated by now. [2] Of course, it probably collapsed under its own weight, but still... ___ 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] Google code shutting down
On Mar 13, 2015, at 3:37 PM, James Moger james.mo...@gmail.com wrote: What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? Feature-for-feature: GitLab If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash…. Good, thank you. Graeme, compare Fossil to those, not to Github. ___ 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] Google code shutting down
On 13/03/15 20:55, Richard Hipp wrote: Few organizations have the problem that the full power of Git solves. And yet many organizations voluntarily take on the problems that come with using Git. Weird. One shouldn't underestimate the power of because everyone else does it. -- Kind Regards, Jan ___ 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] Google code shutting down
On 3/13/15, Ron W ronw.m...@gmail.com wrote: On Fri, Mar 13, 2015 at 4:08 PM, Graeme Pietersz gra...@pietersz.net wrote: I am rather stunned (and a tad concerned) that cars need 100m lines of code. Cars don't really need that much code. The version controlled codebase might be ~5% running code and ~95% tests and documentation though, which would explain a large repo. A luxury car could have electronic control modules in a lot of places you might not think of. I know I was surprised years ago when I happened to be in Detroit during the North American International Auto Show. One of the exhibits was a full sized, clear plastic model of a car with the wiring harnesses and control modules. Front to back, there was a front end lighting controller, front end suspension controller, engine, ignition and transmission controllers, ABS controller, instrument cluster, Heat/ventilation/AC, interior lighting and entertainment system controllers, a memory-power-mirror controller in the 2 side mirrors, a memory-power-seat controller in the 2 front seats, a power window and lock controller in the 4 doors, an overhead (sunroof and redundant controls for HVAC and entertainment systems) controller, back end lighting controller and back end suspension controller. All those modules have tiny computers each needing it's own software. Probably the entertainment system controller has the most software, then the engine controller. By comparison, my grunt car has engine, ignition, transmission and ABS controllers, an instrument cluster, a remote keyless entry controller and a radio/CD player unit. A lot less code. Probably the engine controller has the most software, then the radio/CD unit. ___ 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] Google code shutting down
Obviously positing a link to fossil-users is a good way to have mistakes spotted! On 13/03/15 22:24, bch wrote: I am sure that Git has massive advantages for some people, particularly for large projects with huge numbers of collaborators. It was, after all, designed for the Linux kernel: the largest software project ever (it is approaching 18 million lines of code!) This[1] suggests otherwise. I have corrected it to read as far as I know, the largest single computer program (in the sense of a single executable and excluding linked libraries). From what I have read recently I am fairly sure it is larger than the kernels of other major OSes, and everything on the linked page that is bigger is a collection of executables, and most of them are assemblies of separately developed components. I am rather stunned (and a tad concerned) that cars need 100m lines of code. Additionally, (apparently) at Microsoft they use Perforce internally[2]. I can appreciate that people are passionate about tooling, politics, philosophy of design, etc. but we all have to be careful about putting up cargo cult[3] arguments as reasoning for anything... I am not actually particularly passionate about DVCSs, and even if I have got my numbers wrong. Also, getting a number wrong is not cargo cult science. In any case, the point I was trying to make is that I am sure Git is a good choice for a certain type of project, but I prefer Fossil for what *I* do. [1] http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ [2] http://www.quora.com/What-version-control-system-does-microsoft-use-internally [3] http://en.wikipedia.org/wiki/Cargo_cult On 3/13/15, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 19:50, David Mason wrote: You have a typo in your post: Thanks, corrected. only projects I use Git on are my own pretty sure you meant Fossil in that phrase. Thanks, yes. I prefer to use Fossil, but when I take over something that is already version controlled it invariably uses Git, and usually Github. On 13 March 2015 at 08:40, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 08:17, jungle Boogie wrote: Yes, I'm being optimistic about the userbase but we must agree Fossil to much easier and friendlier to use. Not always. My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. I hope its not spammy to post a link here rather than paste it into an email: http://pietersz.co.uk/2015/03/fossil-vs-git The short version is, Fossil is easier to use than Git, but it is not easier to use than Github. ___ 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 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Git-v-Fossil. Was: Google code shutting down
On 3/13/15, James Moger james.mo...@gmail.com wrote: What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? Feature-for-feature: GitLab If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash Which if these (if any) is used by http://repo.or.cz/git-browser/by-commit.html?r=sqlite.git to mirror the SQLite repo (compare: https://www.sqlite.org/src/timeline?y=ci) and are some of the others any better? -- 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] Google code shutting down
On Fri, Mar 13, 2015 at 4:08 PM, Graeme Pietersz gra...@pietersz.net wrote: I am rather stunned (and a tad concerned) that cars need 100m lines of code. Cars don't really need that much code. A luxury car could have electronic control modules in a lot of places you might not think of. I know I was surprised years ago when I happened to be in Detroit during the North American International Auto Show. One of the exhibits was a full sized, clear plastic model of a car with the wiring harnesses and control modules. Front to back, there was a front end lighting controller, front end suspension controller, engine, ignition and transmission controllers, ABS controller, instrument cluster, Heat/ventilation/AC, interior lighting and entertainment system controllers, a memory-power-mirror controller in the 2 side mirrors, a memory-power-seat controller in the 2 front seats, a power window and lock controller in the 4 doors, an overhead (sunroof and redundant controls for HVAC and entertainment systems) controller, back end lighting controller and back end suspension controller. All those modules have tiny computers each needing it's own software. Probably the entertainment system controller has the most software, then the engine controller. By comparison, my grunt car has engine, ignition, transmission and ABS controllers, an instrument cluster, a remote keyless entry controller and a radio/CD player unit. A lot less code. Probably the engine controller has the most software, then the radio/CD unit. ___ 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] missing initial empty check-in repository from import
Thus said Jan Nijtmans on Fri, 13 Mar 2015 16:28:47 +0100: Another way to trigger the 'problem' is using fossil reconstruct. This function reconstructs the repository from artifacts on disk, it is very unlikely that the initial empty checkin is encountered as first artifact and given rid=1. First, I don't think it has to be the ``initial empty check-in'', but it does have to be of type=ci. This, I think, is the reason why 1.27 chokes on Fossils that don't guarantee rid=1 is of type=ci. Does fossil reconstruct guarantee that rid=1 will type=ci? It certainly doesn't guarantee that it is the ``initial empty check-in'' as my last email demonstrated, but it would seem that this is irrelevant. All that matters for Fossil 1.27 and older is that rid=1 is also type=ci. In addition, depending on what order sync decides to send the data, it may be possible for any Fossil that sends the data where the first artifact received is not a checkin will cause Fossil 1.27 to choke (unless Fossil 1.27 itself guarantees that rid=1 is also type=ci, which it doesn't or we wouldn't have this problem to begin with). So it seems to me that all Fossil really needs to do for backwards compatibility is guarantee that it always has rid=1 is also type=ci; any checkin will suffice. This means that for clones, the first artifact the server sends has to be a checkin, or Fossil 1.27 will choke. So, why when using --empty, does the file artifact become rid=1 instead of the checkin manifest artifact? Can this be changed to make sure that the checkin manifest artifact is actually rid=1 and not the file itself? Anyway, just some things to think on, or be aware of. Thanks, Andy -- TAI64 timestamp: 40005503509c ___ 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] New skin: Blitz
On 3/13/15, James Moger james.mo...@gmail.com wrote: Hello Fossil community, My name is James and I am not a Fossil user, I'm a git user. Thanks for sending in the CLA and the new skin. I announced just this morning plans to cut a release (1.32) tomorrow morning. Even though adding a skin is a very low-risk undertaking, I'm going to wait until after I cut the release to fold in your bundle. Sorry for the delay. So are you connected to the Git community? Can you be our bridge? There are number of ideas in Fossil that could be ported to Git to make Git better. The fossil all command, is one example that seems like it would be very easy to port and would provide a lot of benefit. I have a longer list, but I'll wait on your reply before typing them all. I also happen to run a moderately successful on-premise Git server project not unlike Fossil, http://gitblit.com. But that is not why I am writing you. I've long been an admirer of Fossil's integrated approach and I periodically check-in to see how things are moving along in this project. I see that in the last few releases Fossil has been getting a lot more competent and that is great. I decided to make some time to play with your DVCS (being a fan of SCM) and to whip-up a new skin accompanying resources to contribute to your effort. This theme, Blitz, is demonstrated here: http://dev.gitblit.com:8080/cgi-bin/repo/fossil http://dev.gitblit.com:8080/cgi-bin/repo/sqlite If you've ever seen Gitblit, then this theme will feel comfortable, although it is specialized for Fossil and shares little of the same CSS code. Blitz has two variants (with logo without logo). It includes an alternative Ticket page layout and several image resources which may be of use to other skins. @Richard: I've emailed a signed CLA and a bundle for your review and integration consideration. I hope to contribute more in the future. -J -- 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] missing initial empty check-in repository from import
On Mar 13, 2015 10:02 PM, Andy Bradford amb-fos...@bradfords.org wrote: , but it would seem that this is irrelevant. All that matters for Fossil 1.27 and older is that rid=1 is also type=ci. The ONLY ways to get a checkin with rid 1 is for it to be the magic initial checkin OR for it to be the first change in the repo and be empty (no files). A checkin which includes any files will give rid 1 to one of those files, as they land in the blob table first. A wiki or ticket change before that will give #1 to that entry. (tablet... Brevity... Typos...) ___ 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] New skin: Blitz
On 13/03/15 19:11, James Moger wrote: Hello Fossil community, [---] This just became my new favorite skin. Thank you for submitting this. -- Kind Regards, Jan ___ 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] missing initial empty check-in repository from import
sorry, forgot to say what the image is about: its the timeline after the swapped the check-in on rid=1 by reconstruct, but did not do update before commit. if anybody is interested, here is the git fast-export dump for a simple one check-in: git-one.dump Description: Binary data ___ 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] Google code shutting down
On 3/13/15, Warren Young w...@etr-usa.com wrote: Few organizations have the problem that the full power of Git solves. And yet many organizations voluntarily take on the problems that come with using Git. Weird. -- 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] just a bug report
Hello,
here some testing result output's from tester.tcl...
I'm sorry, I could find no wiki page with instructions on how to submit bug
reports.
Thanks for your time,
Kain
DL-Version:
https://www.fossil-scm.org/download/fossil-w32-20150223162734.zip
--8--
* Final result: 18 errors out of 22987 tests
* Failures: merge-utf-27-23 merge-utf-27-32 merge_multi-4
merge_renames-5 th1-setting-5 th1-setting-6 th1-checkout-1 th1-checkout-2
th1-header-2 th1-footer-2 th1-footer-3 th1-artifact-3 th1-artifact-5
th1-artifact-7 th1-artifact-9 th1-globalState-1 th1-globalState-5
th1-globalState-8
This is fossil version 1.31 [2e7c40dbdd] 2015-02-23 16:27:34 UTC
Compiled on Feb 23 2015 11:56:06 using mingw32-3.20-gcc-4.7.0 (32-bit)
SQLite 3.8.8.2 2015-01-30 14:30:45 7757fc7212
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.1l 15 Jan 2015)
--8--
VS2013 Express x86:
with TH1 an TCL options disabled:
--8--
This is fossil version 1.32 [620783cae2] 2015-03-13 14:01:22 UTC
Compiled on Mar 13 2015 21:13:20 using msc-18.00 (32-bit)
SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2 22 Jan 2015)
JSON (API 20120713)
UNICODE_COMMAND_LINE
* Final result: 17 errors out of 22987 tests
* Failures: merge-utf-27-23 merge-utf-27-32 merge_multi-4
merge_renames-5 th1-setting-5 th1-setting-6 th1-checkout-1 th1-checkout-2
th1-header-2 th1-footer-2 th1-footer-3 th1-artifact-3 th1-artifact-5
th1-artifact-7 th1-artifact-9 th1-globalState-1 th1-globalState-8
--8--
with TH1 an TCL options enabled:
--8--
This is fossil version 1.32 [18bfcfcf3b] 2015-03-13 01:28:33 UTC
Compiled on Mar 13 2015 22:13:11 using msc-18.00 (32-bit)
SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2 22 Jan 2015)
TH1_DOCS
TH1_HOOKS
TCL (Tcl 8.6.3, loaded TH_OK: 8.6.3)
USE_TCL_STUBS
TCL_STUBS
TCL_PRIVATE_STUBS
JSON (API 20120713)
UNICODE_COMMAND_LINE
test merge-utf-27-23 FAILED!
test merge-utf-27-32 FAILED!
test merge_multi-4 FAILED!
test merge_renames-5 FAILED!
...
The tester.tcl script (with latest ActiveTcl) will break near:
D:/src/Fossil-18bfcfcf/win/fossil.exe changes
test revert-2-1-changes OK
D:/src/Fossil-18bfcfcf/win/fossil.exe addremove -n
test revert-2-1-addremove OK
test revert-2-1-exists OK
test revert-2-1-notexists OK
D:/src/Fossil-18bfcfcf/win/fossil.exe undo
* End of revert: 4 errors so far **
* th1-hooks **
D:/src/Fossil-18bfcfcf/win/fossil.exe test-th-eval {hasfeature th1Hooks}
D:/src/Fossil-18bfcfcf/win/fossil.exe info
ERROR: use --repository or -R to specify the repository database
can't read repository: no such variable
while executing
string length $repository
(file D:/src/Fossil-18bfcfcf/test/th1-hooks.test line 141)
invoked from within
source $testdir/$testfile.test
(foreach body line 8)
invoked from within
foreach testfile $argv {
set dir [file root [file tail $testfile]]
file delete -force $dir
file mkdir $dir
set origwd [pwd]
cd $dir
protOu...
(file test\tester.tcl line 335)
--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] Google code shutting down
On Mar 13, 2015, at 1:59 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Fri, Mar 13, 2015 at 01:50:19PM -0600, Warren Young wrote: The thing about most other large projects is that they do not have this highly-distributed hierarchical contribution model. You’re either one of the trusted few with a commit bit, or you are not. Actually, I think it is the other way around. Few large projects have such large trust issues, that so few people are effectively allowed to commit. Yes, Git is uncommon in supporting a federated development style, which is what allows “Fork me on Github” to work. Fossil now partly solves that with bundles, but there is still a stark inside/outside dividing line. So, here’s my new overly simplified categorical statement: Few organizations require federated development. :) ___ 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] New skin: Blitz
So are you connected to the Git community? Can you be our bridge? No, I couldn't fill that role for you. I'm an independent developer and not associated with the core Git team. -J ___ 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] Google code shutting down
What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? Feature-for-feature: GitLab If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash -J ___ 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] New skin: Blitz
No, I couldn't fill that role for you. I'm an independent developer and not associated with the core Git team. (A bit off-topic) I am impressed with your Blitz skin and also the relatively new skin on the main fossil web site. Do you have any quick tips/resources on how I can make my sites look more modern? I know you mentioned Normalize and I have also heard about Bootstrap, but I guess I'm looking more towards general techniques on more cutting edge CSS. When I design a web site it tends to look like it's stuck in 2004. Functionality wise I don't really care but it might be interesting to freshen up a bit. I am NOT a designer and have very little visual sense so something for a mere programmer would be appreciated. ___ 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] Git-v-Fossil. Was: Google code shutting down
At Fri, 13 Mar 2015 20:23:51 -0400, James Moger wrote: You have a great solution. If not then... 1. Corporate users/teams need client/server with a centralized/canonical repo. Check. 2. Corporate users/teams need multiple-repositories. Check, although configuration consistency/maintenance scales linearly with the number of repos. There appears to be shared authentication, so that is good. But authorization must be maintained for each repo. 3. Corporate users/teams need to be able to manage repo lifecycle (create/delete). Missing. 4. Corporate users/teams like to have overviews/dashboards of multiple repositorires - repository groups are a crowd favorite. Graphs are pretty. Missing. For the extent of my own open source projects, I would like a dashboard to promote awareness of my other (often related) open source projects. 5. Corporate users/teams need hooks to integrate with CI notification systems. Partial check. I see there are per-repository hook points, but they seem undeveloped. 6. Corporate users/teams need active notifications: mail, Slack, HipChat, Glip, etc 7. Corporate users/teams need LDAP/PAM/Windows authentication - especially LDAP. We use fossil extensively where I work, for almost any imaginable use, and LDAP authentication would be hugely beneficial. The other changes that you mentioned sound quite useful as well. At least in my view, the ticketing system would be more useful with more hooks for ticket editing and submission. I wrote a vastly more powerful interface to the ticketing system that we use internally, and as far as that is concerned, I don't know of a way allow inline editing of tickets on the ticket list view, at least not without using the edit page as a ticket listing page. If the JSON API supports such hooks in the future, that would be amazing. This is a non-trivial list and maybe it's beyond the scope of the intentions of Fossil. Or maybe not. Perhaps if a large company starts using fossil, then they would finance some or all of these features. Regards, Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] GitHub question. Was: Git-v-Fossil.
I periodically go to sites like GitHub looking for ideas on how Fossil might be improved. So just now I was browsing the SQLite mirror that somebody has put there. And I asked the simple question: How did this project start? (I already know the answer, of course, but I'm curious to see how somebody would figure it out if they were not the original author.) So I locate the initial check-in here: https://github.com/mackyle/sqlite/commit/a3b0e7bbb4e863e1f46ec7de5967e61cc57c8c4b Finding that check-in was an adventure in and of itself. Is there an easy way that I overlooked to find the start of a project in GitHub? But now that I'm on the initial check-in, how do I get to the second check-in? How do I find what comes next? It seems like every check-in information page has a parent link. But I can't find any children links. What am I missing? When reviewing the changes to a project, how to you move forward in time? I tried going to the network graph (https://github.com/mackyle/sqlite/network) which seems similar to the Fossil timeline graph, only sideways. But that graph only seems to go back to 2011-06-03. In other words, the graph only shows about the 5000 most recent changes. How do I go back further in time? Am I wrong to think that clicking through the changes in a project (not necessarily from the beginning, but from some signification event, say the most recent release) in chronological order is something that people might commonly want 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] Google code shutting down
On Fri, Mar 13, 2015 at 4:22 PM, Graeme Pietersz gra...@pietersz.net wrote: 6. There are cases where Fossil’s single-executable philosophy really matters. The ones I’ve run into amounted to cross-compiling: it’s easier to build an ARM executable for a Chromebook or Raspberry Pi and copy just that across than to set up a whole cross-compilation toolchain complete with shared libraries, package managers, etc., then ship some massive bolus-of-code over to the other platform and unpack it there. You don’t always get the luxury of building on the target platform. ChromeOS doesn’t even come with compilers. In the case of the Pi, Git and Fossil (and Mercurial and Bazaar and more) are in the Raspbian repos. So is gcc so I imagine you could compile the latest version on the Pi itself if you wanted to. ChromeOS seems to be rather an odd choice for a development machine, and if you are not using it for development why would you want to install a DVCS on it? Is this really a common problem? I can appreciate (potentially, anyway) why one might want fossil on a ChromeOS machine, given the ability to do wiki ticket stuff via the web interface. One could do all that stuff while disconnected even if actual code banging was not in progress. -- Scott Robison ___ 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] Git-v-Fossil. Was: Google code shutting down
The SQLite mirror is GitWeb which is a Perl script that ships with Git. I didn't name it because it is not a server like Fossil, Gitblit, Gerrit, etc. It is usually paired with Apache system-level SSH access. I rarely see it anymore as there are more competent alternatives for plain viewing, like cGit[1]. Absolutely, some are better than others. Some are of those are commercial (Stash), some are hybrid-commercial (RhodeCode, Gitlab), and some are pure FOSS (Gitblit, Gerrit). All the ones I mentioned 1. serve repos over http ssh (some do native, unauthenticated git:// protocol too) 2. offer multiple authentication mechanisms and authorization schemes 3. allow sharing/collaboration via branch/multi-repo mechanisms (not all follow the Github repo-fork design) 4. have rich hook integrations (mail, ci, realtime hosted chat ala Slack, Hipchat, etc) And then there are many rich GUI clients for the major platforms... SourceTree, SmartGit, Tower, Github for Mac/Windows, Eclipse EGit, etc. Not too mention major corporate funding. Git and it's ecosystem are a juggernaut. When Fossil is compared to Git, the comparison is of course going to extend beyond core Git and core Fossil to include clients servers integrations. Rather than using our tape measures to see who is awesome at X and who is lousy at Y, I would just consider what the needs of Fossil users are: I don't know who the intended audience of Fossil is, but I will assume that it includes FOSS projects and corporations. If that is not the intended audience, then I think you are done. You have a great solution. If not then... 1. Corporate users/teams need client/server with a centralized/canonical repo. Check. 2. Corporate users/teams need multiple-repositories. Check, although configuration consistency/maintenance scales linearly with the number of repos. There appears to be shared authentication, so that is good. But authorization must be maintained for each repo. 3. Corporate users/teams need to be able to manage repo lifecycle (create/delete). Missing. 4. Corporate users/teams like to have overviews/dashboards of multiple repositorires - repository groups are a crowd favorite. Graphs are pretty. Missing. 5. Corporate users/teams need hooks to integrate with CI notification systems. Partial check. I see there are per-repository hook points, but they seem undeveloped. 6. Corporate users/teams need active notifications: mail, Slack, HipChat, Glip, etc 7. Corporate users/teams need LDAP/PAM/Windows authentication - especially LDAP. This is a non-trivial list and maybe it's beyond the scope of the intentions of Fossil. Or maybe not. Has integrating/promoting ChiselApp for on-premise installs been entertained? I haven't tried it yet, but on it's face it seems to address some of the above list. -J [1]: http://git.zx2c4.com/cgit On Fri, Mar 13, 2015 at 5:46 PM, Richard Hipp d...@sqlite.org wrote: On 3/13/15, James Moger james.mo...@gmail.com wrote: What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? Feature-for-feature: GitLab If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash Which if these (if any) is used by http://repo.or.cz/git-browser/by-commit.html?r=sqlite.git to mirror the SQLite repo (compare: https://www.sqlite.org/src/timeline?y=ci) and are some of the others any better? -- 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] Google code shutting down
On Mar 13, 2015, at 4:22 PM, Graeme Pietersz gra...@pietersz.net wrote: On 14/03/15 03:01, Warren Young wrote: I believe that once you extract the hosting services from the comparison, Fossil comes out quite a bit ahead of Git. Even without hosted services, Git still has integration with the likes of Trac and Redmine, and , as James Moger pointed out, things like Gitlab, all of which you can host yourself. Yes, and you’re going to find out that setting them up is quite a lot more difficult than setting up Fossil. You’re trying to compare a hosted service, staffed by a full-time set of sysadmins and designers and such to Fossil. It would be just as unfair to try to compare ChiselApp to some Git+Trac+MediaWiki lash-up. It is not a matter of blame, but of a real disadvantage. More like a trade-off, I think. ChromeOS seems to be rather an odd choice for a development machine Mostly I did it just to see if it could be done, but Scott’s right, it makes a fine self-contained offline-editable wiki. Another practical use is on a Chromebook set up with Crouton [1] where actual software development and such takes place inside the chroot box, but you maintain a separate clone of the software repo outside the box on the ChromeOS side for answering tech support questions when you don’t want to bother firing up Crouton. You build the fossil binary while inside the chroot box, then scp it out before shutting Crouton down. Crouton + Ubuntu ends up being a cross-compilation environment for ChromeOS. And yes, I have used a Chromebook + Crouton for actual software development. For $200 and 3 pounds in my EDC bag, it’s a fine setup for cases where I don’t want to drag along the full-size laptop. To do better than a standard Chromebook for weight and size, you have to pay many times more for a Pixel or the new MacBook Nothin’. [1] https://github.com/dnschneid/crouton ___ 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] Git-v-Fossil. Was: Google code shutting down
On 3/13/15, James Moger james.mo...@gmail.com wrote: I don't know who the intended audience of Fossil is... Fossil was created to support the development of SQLite. All other use (and there is more and more of that lately) is just gravy. -- 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] Google code shutting down
On 14/03/15 03:01, Warren Young wrote: On Mar 13, 2015, at 6:40 AM, Graeme Pietersz gra...@pietersz.net wrote: My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. Some critiques: 1. The post is visually divided into two sections, pro-Fossil and pro-Git, but the actual prose frequently intermixes positives of both. You should separate the two. Cover all the things that are great about Fossil in the first section, then explain in the second why you choose to use Git despite Fossil’s advantages. The biggest example of this is your 2-point numbered list in the first section. If it were my post, I’d just fold these two points into the “one big advantage” section following the pro-Fossil section. If you’d rather discuss tools and services in a separate section, that’s fine, but as it is, your post feels more like a brain dump than reasoned exposition. Good point. My intention was that the first section would explain why I thought Fossil by itself was better for most people, and the second would explain why Git's bigger ecosystem and all those tools and services changed things for many people. I need to think about how best to arrange this. 2. Linux is not “the largest software project ever.” Not even close. Windows’ code base is ~3 times larger. Visual Studio and MS Office are each about twice as large as Linux. The highly-successful Alcatel-Lucent 5ESS telephone switching system was last reported to clock in at over 100 MSLOC. [1] Healthcare.gov was reported at 500 MSLOC, making it about 28x bigger! [2] That has been corrected - see my response to earlier comments on this. I worded it extremely badly and should not have used the word project. 3. I rarely use Git, and never speak more than pidgin Git to it, so perhaps I am just ignorant about some fact about the Git GUI situation, but I can’t see why you ding Gitk but then later in the post praise Gitg. It feels like you’re going out of your way to find bad things about Git which have been fixed elsewhere. Is there a good reason not to just ignore the existence of Gitk? Yes, because Gitk is the nearest thing to a default GUI for Git. It is developed as part of the same project, and the man page says it is developed in the main git repository. It is part of Git in a way things like Gitg are not. I’m all for Fossil boosting, but I don’t see a reason to manufacture negatives for Git. It already has enough genuine negatives to sink it, in my book. :) I was not particularly intending to boost Fossil. 4. Regarding email integration, I don’t blame Fossil for not tackling this one. The hosted VCS services have an advantage in that their sysadmins work out how to connect up to the public email system. Even at its best — as seen in popular GUI email programs — an email server connection can be difficult to set up. To even get that far, you have to write a whole lot of automated probing code to work out which security features some particular email server has, whether the username has an @ sign in it or not, whether it wants incoming email on port 25, 587, 465, 475, or 2525, etc. Email is a hot mess. My point is that you’re kind of mixing apples and oranges here, as well as in other areas. Your comparison should separate Git vs Fossil from ChiselApp/self-hosting vs Github. Yes, I know, ChiselApp still doesn’t compare to Github, so Git will continue to come out on top in that comparison. However, this is still the only fair comparison. Also, I believe that once you extract the hosting services from the comparison, Fossil comes out quite a bit ahead of Git. Even without hosted services, Git still has integration with the likes of Trac and Redmine, and , as James Moger pointed out, things like Gitlab, all of which you can host yourself. These do have email notifications, better ticket tracking, and nice wikis so I think Git comes out ahead in user friendliness after setup, Fossil in ease of setup. It is not a matter of blame, but of a real disadvantage. I do think it fair to compare Fossil to Github etc., because it is supposed to be an all in one solution, so how, for example, its ticket system compares to alternatives is relevant. 5. You’re missing one of Fossil’s advantages: truly private project hosting, as opposed to “We think it’s private, but there hasn’t been a publicized hack on Github yet” semi-private hosting. A lot of organizations are going to be unwilling to pay for “private” hosting at Github or BitBucket for that reason alone. That’s true here, for one. What exists in the Git world to compare to Fossil as a private, self-contained, all-in-one service? James Moger already answered that question, and as I pointed out above things like Trac and Redmine can be integrate with git and I mention these in the post. I think I will edit it to add a references to things like Gitlab. 6. There are cases where Fossil’s
Re: [fossil-users] Google code shutting down
On 13.03.2015 21:55, Richard Hipp wrote: On 3/13/15, Warren Young w...@etr-usa.com wrote: Few organizations have the problem that the full power of Git solves. And yet many organizations voluntarily take on the problems that come with using Git. Weird. Аnyway, Github won that game. In fact it is a good thing - consolidation of majority of the open source code in one collaborative place, 10x more compelling to the new generation developers than e.g. late 90's sourceforge is a phenomenon which greatly accelerates moving the world forward ... I hope the next big thing will be another Github for versioning, forking and merging (i.e. collaboration) on (meta) data, along with the text artifacts. And it seems natural this thing to be born here - in sqlite/fossil community - who other has in depth, first hand expertise in both fields - structural data handling and versioning? The semi-structural software/deployment artifacts (traditional service configurations, devops artifacts like Ansible playbooks, protocols/interfaces definitions, package recipes - RPM, NPM specs, etc, etc) all have at least the same impact as the code itself, because they *enable* the deployment and reuse of already perfectly written code at the site (managed by not-developer users/admins). But currently we rely on expressing this kind of information as text (e.g. YAML in the best case), mostly because we do not have real versioning/forking/merging mechanism, common place and suitable - well known schemes for tree/graph sqlite databases as a replacement of the whole insanity. Kind regards, Alek ___ 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 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] Google code shutting down
On Fri, Mar 13, 2015 at 3:36 AM, Warren Young w...@etr-usa.com wrote: On Mar 12, 2015, at 7:47 PM, jungle Boogie jungleboog...@gmail.com wrote: Hopefully some converts will check out the Fossil project. Unlikely. They’re offering an automated migration path to GitHub: https://code.google.com/export-to-github/ Should fossil-import from Google code be advertised on hosting services (e.g., chisel) or on the project home page even? Or, simpler, should fossil be mentioned in the google code exporting instructions (I suspect the hosting service has to work here to make it happen)? Luca ___ 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] Google code shutting down
On 13/03/15 08:17, jungle Boogie wrote: Yes, I'm being optimistic about the userbase but we must agree Fossil to much easier and friendlier to use. Not always. My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. I hope its not spammy to post a link here rather than paste it into an email: http://pietersz.co.uk/2015/03/fossil-vs-git The short version is, Fossil is easier to use than Git, but it is not easier to use than Github. ___ 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
[fossil-users] missing initial empty check-in repository from import
Hello everybody If I understood correctly from the recent discussion about repositories without initial check-ins (How to fix parallel timeline), the problem of two disconnected DAGs (and seemingly lost files) is triggered if A: fossil version 1.27 (or older) is used to open and work with a B: repository without an initial empty check-in (as created by newer versions of fossil) C: already containing (exactly / at most / at least) one check-in with files If I got that right, the problem might also appear with repositories created by an import from git fast-export (or from a subversion dump with the new svn-import feature). Such repositories do not contain initial empty check-ins, either. And, regarding the other discussion about Google Code shutting down and getting people to convert to fossil, that might lead to the same problem - and a reputation damage ... Regards, Marcel ___ 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] Google code shutting down
On 13/03/15 19:50, David Mason wrote: You have a typo in your post: Thanks, corrected. only projects I use Git on are my own pretty sure you meant Fossil in that phrase. Thanks, yes. I prefer to use Fossil, but when I take over something that is already version controlled it invariably uses Git, and usually Github. On 13 March 2015 at 08:40, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 08:17, jungle Boogie wrote: Yes, I'm being optimistic about the userbase but we must agree Fossil to much easier and friendlier to use. Not always. My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. I hope its not spammy to post a link here rather than paste it into an email: http://pietersz.co.uk/2015/03/fossil-vs-git The short version is, Fossil is easier to use than Git, but it is not easier to use than Github. ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] missing initial empty check-in repository from import
On Fri, Mar 13, 2015 at 3:35 PM, Marcel Graf graf.m.ml+sbf...@gmail.com wrote: Hello everybody If I understood correctly from the recent discussion about repositories without initial check-ins (How to fix parallel timeline), the problem of two disconnected DAGs (and seemingly lost files) is triggered if A: fossil version 1.27 (or older) is used to open and work with a B: repository without an initial empty check-in (as created by newer versions of fossil) C: already containing (exactly / at most / at least) one check-in with files If I got that right, the problem might also appear with repositories created by an import from git fast-export (or from a subversion dump with the new svn-import feature). Such repositories do not contain initial empty check-ins, either. And, regarding the other discussion about Google Code shutting down and getting people to convert to fossil, that might lead to the same problem - and a reputation damage ... Regards, Marcel Well, to kind of answer my own question: I tried it, and yes, it happens too. Only using fossil version 1.27! 1. Take any git repository and create the fast-export dump up to the first check-in: git fast-export --full-tree HASH-OF-THE-FIRST-GIT-CHECKIN git.dump 2. Import it to a fossil repository fossil import test.fossil git.dump 3. Open that repository fossil open test.fossil As long as the the fossil in step 3 is 1.27, the working directory is empty. fossil up does not do anything, fossil ui shows the check-in, though. And fossil up HASH-FROM-THE-WEB-UI-FOR-THIS-CHECKIN would bring it back. It does not matter if in step 2 a newer fossil is used (it asks for rebuild before doing almost anything - even for close, but only after the open ... ) or the same version 1.27 is used for the import. It does not happen when there is more than 1 check-in imported (so point C above should be exactly 1 check-in, probably). So, in conclusion: the problem can be triggered using _only_ fossil version 1.27, using an import of a one-check-in git repository. Which is probably a rare thing and not worth a repository conversion anyway. But indicates a bug in version 1.27 rather then in the newer versions, imho. And another reason not to use =1.27 anymore. ___ 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] missing initial empty check-in repository from import
2015-03-13 15:56 GMT+01:00 Marcel Graf graf.m.ml+sbf...@gmail.com: Well, to kind of answer my own question: I tried it, and yes, it happens too. Only using fossil version 1.27! Interesting. Thanks! Another way to trigger the 'problem' is using fossil reconstruct. This function reconstructs the repository from artifacts on disk, it is very unlikely that the initial empty checkin is encountered as first artifact and given rid=1. So, if the requirement is that rid=1 must contain the manifest of the initial empty check-in, the fossil reconstruct command builds an incompatible repository by design :-) 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] Google code shutting down
You have a typo in your post: only projects I use Git on are my own pretty sure you meant Fossil in that phrase. On 13 March 2015 at 08:40, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 08:17, jungle Boogie wrote: Yes, I'm being optimistic about the userbase but we must agree Fossil to much easier and friendlier to use. Not always. My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. I hope its not spammy to post a link here rather than paste it into an email: http://pietersz.co.uk/2015/03/fossil-vs-git The short version is, Fossil is easier to use than Git, but it is not easier to use than Github. ___ 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 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] Google code shutting down
Perhaps a better reference for the cargo cult reference in my previous post: http://en.wikipedia.org/wiki/Cargo_cult_science :P -bch On 3/13/15, bch brad.har...@gmail.com wrote: I am sure that Git has massive advantages for some people, particularly for large projects with huge numbers of collaborators. It was, after all, designed for the Linux kernel: the largest software project ever (it is approaching 18 million lines of code!) This[1] suggests otherwise. Additionally, (apparently) at Microsoft they use Perforce internally[2]. I can appreciate that people are passionate about tooling, politics, philosophy of design, etc. but we all have to be careful about putting up cargo cult[3] arguments as reasoning for anything... [1] http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ [2] http://www.quora.com/What-version-control-system-does-microsoft-use-internally [3] http://en.wikipedia.org/wiki/Cargo_cult On 3/13/15, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 19:50, David Mason wrote: You have a typo in your post: Thanks, corrected. only projects I use Git on are my own pretty sure you meant Fossil in that phrase. Thanks, yes. I prefer to use Fossil, but when I take over something that is already version controlled it invariably uses Git, and usually Github. On 13 March 2015 at 08:40, Graeme Pietersz gra...@pietersz.net wrote: On 13/03/15 08:17, jungle Boogie wrote: Yes, I'm being optimistic about the userbase but we must agree Fossil to much easier and friendlier to use. Not always. My reply to this turned out to be rather long and a bit of rant, so I turned it into a blog post. I hope its not spammy to post a link here rather than paste it into an email: http://pietersz.co.uk/2015/03/fossil-vs-git The short version is, Fossil is easier to use than Git, but it is not easier to use than Github. ___ 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 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
