Re: [fossil-users] Scalability (WAS: something else)
On Tue, Sep 2, 2014 at 11:26 PM, sky5w...@gmail.com wrote: (2) Fossil's purpose is to be able to recreate historical versions of the project - exactly. It cannot do that if historical images have been deleted. I understand the purity intended, but continue to be frustrated by it. :) I merely seek an automated way within Fossil to manage garbage. Re-repoing to delete spam or 'add *.*' mistakes is quite painful. Fossil's design is not only to make it painful, but impossible, to remove old data. Mistakes are painful - that's why we learn from them. To work against a given software's internal assumptions/laws of physics generally leads to pain and suffering. From what i understand, git will quite happily let you remove whatever you want (and afterwards you might even be able to still access the other data, too). -- - 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] Scalability (WAS: something else)
On Tue, Sep 2, 2014 at 10:27 AM, Stephan Beal sgb...@googlemail.com wrote: but by very large source control i envision something akin to git's octopus model, reaching fractally out into the universe Fossil uses the octopus model as well. I just don't know of any projects using Fossil that have more than 2 layers of developers. By 2 layers, I mean devs with push access to the main repository and devs who submit patches. As compared to, say, the Linux Kernel project, where several rings of repositories (and their respective maintainers) marshal changes inward. (That said, someone on this list was talking about a project that potentially could involve project devs pushing changes to a Fossil server in their respective offices, which in turn would push the changes to the main office. However, it looks like that person may have decided to pass over Fossil due to real time issues.) ___ 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] Scalability (WAS: something else)
On 9/2/2014 08:27, Stephan Beal wrote: On Tue, Sep 2, 2014 at 4:18 PM, sky5w...@gmail.com mailto:sky5w...@gmail.com wrote: Will Fossil ever seek to address very large source control? Fossil's main target is sqlite (it's a cyclic relationship), and in my humble (but quite fallible) opinion that project won't ever need very large source control. While I don't think moving to PostgreSQL is the right answer, there are some things about Fossil where it's making SQLite-based assumptions that break down in projects with large repos. SQLite is a relatively tight code base with little in the way of media files checked into the repo. The SQLite repo is currently 52 megs. The Fossil repo for the web app I work on is 284 megs, probably in very large part because I check in two copies of most every graphic used in the web app: a high-res multi-layered working copy, and a downsampled flattened and optimized PNG version for display. Every time one of these files changes, the whole file has to be copied back into the repo, because you can't diff a PSD or PNG file. (Well, *Fossil* can't.) Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here. There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases. ___ 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] Scalability (WAS: something else)
On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote: Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here. There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases. Huh? You can. It has been available for ages. 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] Scalability (WAS: something else)
On 9/2/2014 14:47, Joerg Sonnenberger wrote: On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote: Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here. There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases. Huh? You can. It has been available for ages. This is the message I was thinking of: http://goo.gl/Q0wtIr I see that repo-cksum already exists, so I'm not sure what drh was talking about that's different. Maybe just a threshold, beyond which repo-cksum is always disabled? ___ 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] Scalability (WAS: something else)
While disabling checksums helps with speed http://www.fossil-scm.org/index.html/help?cmd=settings It does not help with redundant binary images in the repo. For that, you have to shun and rebuild. If you could flag a file as Keep latest only, that would be less painless. I don't mind the artifact overhead of a changed binary file, but it hurts to have the data stored too. On Tue, Sep 2, 2014 at 4:47 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote: Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here. There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases. Huh? You can. It has been available for ages. Joerg ___ 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] Scalability (WAS: something else)
On Tue, Sep 2, 2014 at 5:04 PM, Warren Young war...@etr-usa.com wrote: On 9/2/2014 14:47, Joerg Sonnenberger wrote: On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote: Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here. There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases. Huh? You can. It has been available for ages. This is the message I was thinking of: http://goo.gl/Q0wtIr I see that repo-cksum already exists, so I'm not sure what drh was talking about that's different. Maybe just a threshold, beyond which repo-cksum is always disabled? When I write that message, and said it might be possible to implement I had forgotten that I had already implemented it for Joerg, ages ago. -- 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] Scalability (WAS: something else)
On Tue, Sep 2, 2014 at 5:07 PM, sky5w...@gmail.com wrote: While disabling checksums helps with speed http://www.fossil-scm.org/index.html/help?cmd=settings It does not help with redundant binary images in the repo. For that, you have to shun and rebuild. If you could flag a file as Keep latest only, that would be less painless. I don't mind the artifact overhead of a changed binary file, but it hurts to have the data stored too. (1) Fossil *does* store binary files as diffs from their predecessor, if they are sufficiently similar (that is, if the diff is smaller than the file itself). the problem is that with compressed images, changing a single pixel can potentially change most bytes of the file, making a diff pointless. (2) Fossil's purpose is to be able to recreate historical versions of the project - exactly. It cannot do that if historical images have been deleted. -- 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] Scalability (WAS: something else)
On 9/2/2014 15:07, sky5w...@gmail.com wrote: If you could flag a file as Keep latest only, that would be less painless. That wouldn't work for me. I want the past versions of the image. [*] The branch I made of the web app three years ago won't run right with the current bitmaps. The new ones may be different sizes, have a different design esthetic, etc. With repo-cksum on, Fossil has an O(N) complexity component. Without it, you only have the logarithmic time complexities due to the tree structures of the DB. [*] Well, I suppose I could go through and weed out a few bad ideas, but that goes against Fossil's nature. ___ 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] Scalability (WAS: something else)
On 9/2/2014 15:11, Richard Hipp wrote: (1) Fossil *does* store binary files as diffs from their predecessor, if they are sufficiently similar (that is, if the diff is smaller than the file itself). the problem is that with compressed images, changing a single pixel can potentially change most bytes of the file, making a diff pointless. You're right, it probably *is* storing diffs of my PSD files, but not the PNGs. Just as well: it's the PSDs that are the real pigs. ___ 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] Scalability (WAS: something else)
(2) Fossil's purpose is to be able to recreate historical versions of the project - exactly. It cannot do that if historical images have been deleted. I understand the purity intended, but continue to be frustrated by it. :) I merely seek an automated way within Fossil to manage garbage. Re-repoing to delete spam or 'add *.*' mistakes is quite painful. On Tue, Sep 2, 2014 at 5:19 PM, Warren Young war...@etr-usa.com wrote: On 9/2/2014 15:07, sky5w...@gmail.com wrote: If you could flag a file as Keep latest only, that would be less painless. That wouldn't work for me. I want the past versions of the image. [*] The branch I made of the web app three years ago won't run right with the current bitmaps. The new ones may be different sizes, have a different design esthetic, etc. With repo-cksum on, Fossil has an O(N) complexity component. Without it, you only have the logarithmic time complexities due to the tree structures of the DB. [*] Well, I suppose I could go through and weed out a few bad ideas, but that goes against Fossil's nature. ___ 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
