Re: [fossil-users] how to use git to lose data
On Mon, Sep 01, 2014 at 05:29:41PM +0200, Stephan Beal wrote: Okay, more git bashing... Yeah. It's too easy _not_ to do. Git is just another steaming Linux-centric pile that makes me so thankful there are people like Dr. Hipp and you and all the fossil guys. Consider the following points: 1) The world is not Linux 2) See (1) above. There are many operating systems that aren't Linux 3) We want something safe that uses a proven database because source control is about controlling source, not losing it and not littering it all over your system. 4) We want something that builds without drama on many platforms using standards compliant compilers and without requiring gcc extensions or specific shells like bash or any other proprietary (yes, I said it!) gnu crap.. Git = MAJOR FAIL. 5) We want something efficient, compact and clean that doesn't depend on scripting languages or need add-ons to be useful. It shouldn't create dozens of executables and libraries all over the target system. Because if it sucks we're going to wanna yank it out cleanly. 6) We don't want to drag a thousand tons of gnu prereqs just to build an application or its documentation(!) and we don't want to depend on dozens of prereqs to run it. Heavy = bad, light = good. 7) A source control system should be sensible from the point of view of the person using it to manage source code. It should not be Linux-centric. It should not require you to understand its internals to use it effectively and it must not require you to understand the internals to avoid pitfalls and gotchas. Tricks = bad, least surprise = good. 8) Source control is not a hobby for normal healthy people. It's not something to become an expert in for chest-banging purposes. It's a critical tool that's supposed to stay the hell out of the way and let you write and keep track of code. You guys scored a huge win by creating fossil and basing it on sqlite. It's ingenious, it's simple, it's trustworthy, it's complete, and most of all it's nothing we _don't_ want in a source control system! Thank you! /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ 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 use git to lose data
On Mon, Sep 1, 2014 at 11:49 PM, Scott Robison sc...@casaderobison.com
wrote:
Based on reading {Stephan's message}, what do you agree or disagree with?
FWIW: i am in the small minority of my colleagues who regularly have
problems with git. They seem to be able to do the same things, click the
same buttons, and get their code in and out of where it should be.
It seems to me (after reading this and thinking about version control
systems in a slightly new way for the first time today), git is focused
less on securely keeping track of source code and far more on providing a
toolbox of ways to reorganize code to simplify (I use that term loosely)
social interactions between developers / users of git (aka collaboration).
It's not that it can't keep track of source code, but that it considers the
social aspects / reorganization tools to be more important, while at the
same time being quite terse / obtuse in the documentation / usage area.
An interesting response. Hadn't thought of it that way.
Is that an unfair assessment on my part? I still readily agree that I'm
a git newbie, and even a dvcs neophyte, and the reasons I use fossil have
little to do with its distributed nature (though I'm using it more often
that way as time goes by). Also that for certain project types where large
/ deep hierarchies of collaborators are at work, fossil is probably not an
ideal solution. It certainly wouldn't work in the same way git is used by
the linux kernel team.
Agreed completely.
I'll be interested to hear back from him what he thinks.
Me as well.
--
- 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] how to use git to lose data
On Tue, Sep 2, 2014 at 10:08 AM, John Long codeb...@inbox.lv wrote: specific shells like bash or any other proprietary (yes, I said it!) gnu LOL! 8) Source control is not a hobby for normal healthy people. Hey! ;) You guys scored a huge win by creating fossil and basing it on sqlite. That was 100% DRH, and i believe Andreas K. was there at the start - the rest of us came along sometime between then and recently. It's ingenious, it's simple, it's trustworthy, it's complete, and most of all it's nothing we _don't_ want in a source control system! Which is why we all joined :). Thank you! Thanks for your praise :). -- - 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] how to use git to lose data
On Tue, 2 Sep 2014 08:08:41 + John Long codeb...@inbox.lv wrote: 8) Source control is not a hobby for normal healthy people. It's not something to become an expert in for chest-banging purposes. It's a critical tool that's supposed to stay the hell out of the way and let you write and keep track of code. 9) Source control system is not only for keeping the code - here it's used for very general writings (even non-computer-related). (too) specific = selfish, universal = broad-minded. 10) Considering 9) (above) it's a proof that those serving God, serve other people as well. Sincerely, Gour -- As fire is covered by smoke, as a mirror is covered by dust, or as the embryo is covered by the womb, the living entity is similarly covered by different degrees of this lust. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Off-topic faith declarations (was Re: how to use git to lose data)
2014-09-02 5:44 GMT-03:00 Gour g...@atmarama.net: 10) Considering 9) (above) it's a proof that those serving God, serve other people as well. As a atheist I protest that this is deeply unsettling and off-topic. You believers have almost ALL the other existing forums for yourselves. Can you keep your exhibitions of faith out of SOME places, for crying out loud? ___ 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] Off-topic faith declarations (was Re: how to use git to lose data)
On Tue, Sep 2, 2014 at 8:57 AM, Marcelo richiead...@gmail.com wrote: 2014-09-02 5:44 GMT-03:00 Gour g...@atmarama.net: 10) Considering 9) (above) it's a proof that those serving God, serve other people as well. As a atheist I protest that this is deeply unsettling and off-topic. I think that Gour's comment was appropriate to the subject at hand and in good taste. Gour's remark was in no way judgmental or condescending and it contributed (tangentially) to the topic. Marcelo's reply, on the other hand, loudly proclaims his particular world-view and posits that anyone who disagrees must remain silent. Marcelo's reply is definitely off-topic. Marcelo, you are welcomed to contribute and ask questions and comment here and I hope that you will continue to participate in this forum. However, I ask that in the future you keep your remarks civil and on-topic and that you avoid trying to enforce your world-view on other members of the community. -- 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] how to use git to lose data
On Tue, Sep 2, 2014 at 2:44 AM, Gour g...@atmarama.net wrote: 9) Source control system is not only for keeping the code - here it's used for very general writings (even non-computer-related). (too) specific = selfish, universal = broad-minded. Interesting you should write this. One of my newest uses for fossil is the one case in which I'm using it distributed (even though all by myself): My blog (such as it is). It is not a unique idea at all, but I finally tired of heavy weight blog platforms and decided I wanted to just keep track of things in text files. I've started using the pelican static site generator to keep all my site's source files (restructured text files in a content tree config files etc) as well as the generated files (public tree). I only maintain the site on my home computer (including generating the public stuff), but then I commit sync it to the remote server and update the live site, making the generated file tree available (and giving me a live backup of all the files). -- 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] Off-topic faith declarations (was Re: how to use git to lose data)
Well said and yes, Fossil is a non-tedious, benevolent lifesaver. My reservation being scalability of large repo support. While I am unaffected, those professionals charged with release and maintenance of large code bases look past Fossil and its SQLite core. Questions: Will Fossil ever seek to address very large source control? Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? Thanks for Fossil! On Tue, Sep 2, 2014 at 9:31 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Sep 2, 2014 at 8:57 AM, Marcelo richiead...@gmail.com wrote: 2014-09-02 5:44 GMT-03:00 Gour g...@atmarama.net: 10) Considering 9) (above) it's a proof that those serving God, serve other people as well. As a atheist I protest that this is deeply unsettling and off-topic. I think that Gour's comment was appropriate to the subject at hand and in good taste. Gour's remark was in no way judgmental or condescending and it contributed (tangentially) to the topic. Marcelo's reply, on the other hand, loudly proclaims his particular world-view and posits that anyone who disagrees must remain silent. Marcelo's reply is definitely off-topic. Marcelo, you are welcomed to contribute and ask questions and comment here and I hope that you will continue to participate in this forum. However, I ask that in the future you keep your remarks civil and on-topic and that you avoid trying to enforce your world-view on other members of the community. -- 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
[fossil-users] Scalability (WAS: something else)
On Tue, Sep 2, 2014 at 4:18 PM, sky5w...@gmail.com wrote: My reservation being scalability of large repo support. While I am unaffected, those professionals charged with release and maintenance of large code bases look past Fossil and its SQLite core. Questions: 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. Steps have been taken to improve scalability for the benefit large repos, e.g. TCL and pkgsrc(?), but by very large source control i envision something akin to git's octopus model, reaching fractally out into the universe, and i don't personally see fossil ever scaling/needing to scale much in that direction. Would it be interesting? Sure, but i suspect it would be seen as quite out of scope for the core project. Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? In principle, fossil could be implemented in any storage, but in practice a _lot_ of the hard work is done by sqlite, and a port would be painful. That said, both fossil and libfossil abstract most db access behind another layer more suited to fossil, so swapping (e.g.) sqlite3 with sqlite4, 5, or 6 should be relatively painless. (Richard had it running (or compiling) in v4 experimentally at some point, IIRC.) -- - 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] Using a different RDBMS (was: something else)
On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote: Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? Fossil is not the first DVCS to use SQLite for local storage. That distinction belongs to Monotone (http://www.monotone.ca/) which in addition to being the first DVCS to use SQLite was the very first *Distributed* VCS (as far as I am aware). Monotone predates Git and Fossil by several years. Early versions of Monotone actually used SQLite version 2! Linus gave serious consideration to using Monotone as the DVCS for Linux during the Bitkeeper fiasco, before deciding to write his own instead. Regarding the SQLite-vs-Postgres question, the Monotone FAQ says this: http://wiki.monotone.ca/FAQ/#index11h1 -- 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] how to use git to lose data
On 2 September 2014 10:08, John Long codeb...@inbox.lv wrote: 7) A source control system should be sensible from the point of view of the person using it to manage source code. It should not be Linux-centric. It should not require you to understand its internals to use it effectively and it must not require you to understand the internals to avoid pitfalls and gotchas. Tricks = bad, least surprise = good. This is the main issue I have: git does not follow the principle of least surprise. I'm sure it *can* do everything, if you know all of the switches and gotchas. But you don't, even if you think you do. Apparently many advanced git users have their subset well figured out, and those never can understand outsiders complaining about how difficult git can be. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Spaces allowed in custom ticket drop-downs?
I was working in Admin - Tickets - Common and realized that the lists
there are just TH1 code. I asked myself, would it work if I changed this:
set type_choices {
Code_Defect
Build_Problem
Documentation
Feature_Request
Incident
}
to this?
set type_choices {
Code Defect
Build Problem
Documentation
Feature Request
Incident
}
It appears to work.
Am I missing some fact which makes this a bad idea?
If it's perfectly legal and has no consequence more severe than
requiring that you be careful about quoting when you run SQL queries
against it, then I suggest the possibility be mentioned on this page:
http://fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki
___
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] Off-topic faith declarations (was Re: how to use git to lose data)
On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote: Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? I think that the only way this will happen would be to fork Fossil into a new project. This would be because of the overall underlying goals of the Fossil project vs a Fossil-saurus project. As I understand it, Fossil is intentionally designed around the feature set provided by SQLite. Therefore, to support DB back-ends other than SQLite would not just require rewriting SQL queries, but significant re-working of Fossil's C implementation. Certainly, a huge scale DVCS like Fossil would be a good thing. A key question for a potential project team will be: Once you separate out the DB back-end, where do you draw the line? As for Fossil itself, it probably scales better than most people think. Part of the problem is perception. Part of the problem is lack of certain features that some people consider desirable or essential. I know many people who are more comfortable with large scale systems like Perforce, because they are used to working in large organizations. And I know that some of those do/did work on large software teams. The rest are like me: The overall software team is large, but for any given project, the number of software members is usually 2, sometimes 1 or 3, rarely more than that. The high ceremony system we are supposed to be using is not helpful to us. ___ 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 use git to lose data
On 9/2/2014 09:00, Dömötör Gulyás wrote: This is the main issue I have: git does not follow the principle of least surprise. I'm sure it *can* do everything, if you know all of the switches and gotchas. But you don't, even if you think you do. Apparently many advanced git users have their subset well figured out, and those never can understand outsiders complaining about how difficult git can be. Git solves the Linux kernel problem, and it solves it well. The thing is, Linus Torvalds is unique. No one else on the planet has a problem that big and complex to solve. Why is everyone trying to use a tool designed to serve his requirements? For almost everyone else on the planet with a source control problem, using Git is like using a computer-controlled quilting and embroidering machine to sew lost buttons back onto a shirt. ___ 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 use git to lose data
On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison sc...@casaderobison.com wrote: It certainly wouldn't work in the same way git is used by the linux kernel team. Git was originally created by the Linux Kernel team, including Linus. It's hardly surprising that git would be a better fir for them than Fossil or any other VCS (distributed or 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] how to use git to lose data
On Tue, Sep 02, 2014 at 02:02:39PM -0400, Ron W wrote: On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote: Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB here)? I think that the only way this will happen would be to fork Fossil into a new project. This would be because of the overall underlying goals of the Fossil project vs a Fossil-saurus project. As I understand it, Fossil is intentionally designed around the feature set provided by SQLite. Therefore, to support DB back-ends other than SQLite would not just require rewriting SQL queries, but significant re-working of Fossil's C implementation. I'm probably out of my area but it would seem writing a wrapper to transform the database calls to $BACKEND_OF_CHOICE would be in order unless sqlite does stuff that is really not appropriate for other databases and cannot readily be transformed to make sense with other databases. Theoretically it should be possible to do that without changing the API calls at all. You would just link the wrapper instead of sqlite. If you can get this to work it's obviously the safest, most low-impact way to do a major change like that while not breaking what already works. I have done stuff like this on another platform but am not familiar with any of the parts here i.e. I have no knowledge of C, fossil, etc. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ 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 use git to lose data
On Sep 2, 2014 12:10 PM, Ron W ronw.m...@gmail.com wrote: On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison sc...@casaderobison.com wrote: It certainly wouldn't work in the same way git is used by the linux kernel team. Git was originally created by the Linux Kernel team, including Linus. It's hardly surprising that git would be a better fir for them than Fossil or any other VCS (distributed or not). That was the point I was going for. Maybe should have made it explicit. ___ 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] Off-topic faith declarations (was Re: how to use git to lose data)
On 9/2/14, 8:02 PM, Ron W wrote: [...] I think that the only way this will happen would be to fork Fossil into a new project. This would be because of the overall underlying goals of the Fossil project vs a Fossil-saurus project. It may be plausible to simply implement a RDBMS wrapper library which presents a SQLite-like API. That would neatly encapsulate and translate all the SQLite-isms used by Fossil, which means you wouldn't have to change Fossil at all. I have no idea whether this is feasible or not. I don't really know how different SQLite's SQL dialect is from other databases --- since discovering SQLite I haven't really felt a need to get into MySQL or Postgres --- and there may also be killer non-API assumptions: e.g., with SQLite, local processing is cheap. With a remote DBMS, local processing is expensive, because you have to push all the data over the wire. So if Fossil's expecting to be able to cheaply enumerate big chunks of the version graph, that's unlikely to adapt well to a remote database. [...] As for Fossil itself, it probably scales better than most people think. Part of the problem is perception. I believe NetBSD has one of the bigger Fossil repositories, and they've complained that some Fossil operations are slow (commits and updates --- http://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf claims 8-10 seconds for an operation which git and hg do in 1. I have a vague memory of a discussion here coming to the conclusion that this is because of large chains of deltas having to be resolved? (I myself have a 250MB Fossil repository with a number of large files in it (multi-megabyte jpegs) and have noticed that operations are noticeably slower there than on small repositories.) [...] I know many people who are more comfortable with large scale systems like Perforce, because they are used to working in large organizations. Perforce handles very, very large repositories very well. (Repositories too large for git.) e.g.: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/34459.pdf Brief summary: it says that Google's VCS, as of 2011, had 200GB of *metadata* (amount of actual data is unspecified) and did about 25qps. (Perforce is *weird*. You thought git was weird? Go use Perforce.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Feminism encourages women to leave their husbands, kill their │ children, practice withcraft, destroy capitalism and become lesbians. │ --- Rev. Pat Robertson 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
[fossil-users] edits to ticket table not synchronized with 'fossil config pull all'
In one of my fossil repos, I edited the tickets table by adding a column. I wanted to pull the new column definition into a repo clone, so I said fossil config pull all from the other repo, to no avail. New reports, the New Ticket and Edit Ticket pages and so on were properly synchronized, but the table definition itself was not. This leads to this error message in one of the reports I have defined that uses the new column: SQLITE_ERROR: no such column: releaseGate Other commands that did not work: fossil config pull ticket fossil config pull ticket --overwrite fossil pull I have seen this every time I have tried to add a column to the tickets table. I normally work around it by copy-pasting the ticket definitions, but that is probably not going to be acceptable for my other users. Am I doing something wrong? Eric ___ 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 use git to lose data
On 9/1/2014 15:49, Scott Robison wrote: the reasons I use fossil have little to do with its distributed nature (though I'm using it more often that way as time goes by). A DVCS can be useful even to a lone developer. Several times since switching from svn to Fossil, I've spent some of my disconnected travel time working on a project backed by Fossil, and was able to check in changes while offline, knowing I can synch later, with every detail of my change history synched discretely, rather than as a monolithic blob. When doing the same kind of work in my svn days, I'd end up with these massive diffs that I had to spend a bunch of time disentangling in order to get sane checkin comments on each aspect of the change set. If you have more than one computer connected to a VCS and at least one is mobile, you should be using a DVCS. Fossil vs Git is a side issue, when it comes to that. (This is also why I've been advocating for the uber-patch feature. It lets outsiders contribute patches to a project they don't have commit permissions on, without making the one applying the patch do the work of disentangling many unrelated elements of the patch.) ___ 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 use git to lose data
On Tue, Sep 02, 2014 at 12:08:22PM -0600, Warren Young wrote: On 9/2/2014 09:00, Dömötör Gulyás wrote: This is the main issue I have: git does not follow the principle of least surprise. I'm sure it *can* do everything, if you know all of the switches and gotchas. But you don't, even if you think you do. Apparently many advanced git users have their subset well figured out, and those never can understand outsiders complaining about how difficult git can be. Git solves the Linux kernel problem, and it solves it well. The thing is, Linus Torvalds is unique. No one else on the planet has a problem that big and complex to solve. Why is everyone trying to use a tool designed to serve his requirements? While I agree on the uniqueness of Torvalds, I don't agree with the rest. The Linux kernel is *not* that big when compared with many other projects. There are quite a few other projects that are comparable in size and history. There is something else which is often ignored, especially by git advocats. The development model pushed by git is the development model used by Torvalds and that's pretty unique as well. In a way, it inverts the normal process used by most projects. A somewhat sarcastic view would call it organised distrust. Most FOSS projects and many commercial projects have a moderately flat hierachy. Members have work areas they commit code in, releases and contributions outside that area is handled either by senior members or other special subteams. There rarely is a single point of failure / approval... The Linux model effectively inverts that model. 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] edits to ticket table not synchronized with 'fossil config pull all'
You have to run fossil rebuild on _all_ repositories with the new definition. This rebuilds the derived tables (TICKET, TICKETCHNG) from the actual tickets, and ensures that they actually have the new column you defined. On Tue, Sep 2, 2014 at 11:36 AM, Eric Rubin-Smith eas@gmail.com wrote: In one of my fossil repos, I edited the tickets table by adding a column. I wanted to pull the new column definition into a repo clone, so I said fossil config pull all from the other repo, to no avail. New reports, the New Ticket and Edit Ticket pages and so on were properly synchronized, but the table definition itself was not. This leads to this error message in one of the reports I have defined that uses the new column: SQLITE_ERROR: no such column: releaseGate Other commands that did not work: fossil config pull ticket fossil config pull ticket --overwrite fossil pull I have seen this every time I have tried to add a column to the tickets table. I normally work around it by copy-pasting the ticket definitions, but that is probably not going to be acceptable for my other users. Am I doing something wrong? Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] edits to ticket table not synchronized with 'fossil config pull all'
Andreas Kupries wrote: You have to run fossil rebuild on _all_ repositories with the new definition. This rebuilds the derived tables (TICKET, TICKETCHNG) from the actual tickets, and ensures that they actually have the new column you defined. Works like a charm -- thank you sir! -- Eric A. Rubin-Smith ___ 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] Off-topic faith declarations (was Re: how to use git to lose data)
On Tue, Sep 2, 2014 at 2:35 PM, David Given d...@cowlark.com wrote: Perforce handles very, very large repositories very well. (Repositories too large for git.) e.g.: One of my clients uses Perforce. Yes, it can handle huge repositories very well. The company has a few projects that benefit both from the ability to handle huge repositories and from the level of management control Perforce's user interface uses. But most of the projects have tiny (2 to 5 SW devs) teams that don't benefit from those controls. (Perforce is *weird*. You thought git was weird? Go use Perforce.) Yeah, I've used it. Though the above mentioned client has several in-house plug-ins for Perforce that, while add some capabilities the client finds helpful, they also prevent use of some built-in features (for example, it is necessary to manually maintain each project's manifest of files (I did create a plug-in to partially automate this, but it still some manual intervention)) ___ 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 use git to lose data
On 9/2/2014 12:38, Joerg Sonnenberger wrote: On Tue, Sep 02, 2014 at 12:08:22PM -0600, Warren Young wrote: On 9/2/2014 09:00, Dömötör Gulyás wrote: This is the main issue I have: git does not follow the principle of least surprise. Linus Torvalds is unique. No one else on the planet has a problem that big and complex to solve. While I agree on the uniqueness of Torvalds, I don't agree with the rest. The Linux kernel is *not* that big when compared with many other projects. Lines of code is not the important measure here. The uncommon thing about the Linux kernel development effort is that it is highly distributed, with many merge layers and multiple independent but communicating major repositories. An outsider wanting to get a change into the kernel doesn't just email a patch(1) file to torva...@linux.com, he has to work it up through these layers. Some changes sit for months or years in one of the alternate kernel repos before it makes its way into Linus's git repo. Such a messy process requires a tool set that can wrangle that mess into some semblance of coherency. If you don't have that kind of mess, you don't need those tools. Other large projects either... 1. ...live largely or entirely within the scope of a single organization so presumably the check-in hierarchy is either flat or nearly so. (e.g. the Windows OS) 2. ...have a simple dividing line between those inside the project and those outside it. You either have a commit bit or you do not. Those without must submit patches. (e.g. FreeBSD) In both cases, commits end up in The Repository, singular, in short order. Such projects that use a DVCS are likely using it as master plus remotes with minor temporary differences rather than the federation model of Linux kernel 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] 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] how to use git to lose data
On Tue, Sep 2, 2014 at 2:35 PM, Warren Young war...@etr-usa.com wrote: If you have more than one computer connected to a VCS and at least one is mobile, you should be using a DVCS. Fossil vs Git is a side issue, when it comes to that. I do and I use Fossil (no surprise there, right?) because of the simplicity of set up. (This is also why I've been advocating for the uber-patch feature. It lets outsiders contribute patches to a project they don't have commit permissions on, without making the one applying the patch do the work of disentangling many unrelated elements of the patch.) This could be done using the --incremental feature of fossil export / import. It's just tricky to use. My experience with submitting patches (several different projects) has been (a) each patch must be limited to one fix or enhancement, and (b) should not result in merge conflicts when the dev applying the patch applies the patch. (Generally this means pulling the latest, merging, resolving, building and testing, then pulling and merging again to make sure. Then create the patch and send it as quickly as possible.) ___ 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] how to use git to lose data
On 9/2/2014 14:53, Ron W wrote: On Tue, Sep 2, 2014 at 2:35 PM, Warren Young war...@etr-usa.com mailto:war...@etr-usa.com wrote: (This is also why I've been advocating for the uber-patch feature. My experience with submitting patches (several different projects) has been (a) each patch must be limited to one fix or enhancement, and (b) should not result in merge conflicts when the dev applying the patch applies the patch. I've been running an open source project for a decade now, so I can tell you from experience that a lot of patches come in that do multiple things. You can often tell that they were built up in stages, each an independent step worth a separate checkin, but because they didn't have checkin privileges, they had to submit the whole mess as a single big patch. I will predict that if Fossil ever *does* get an uber-patch feature, that I'll still get intermingled hairball patches. Still, at least it will give the outsiders a *chance* to do the right thing. ___ 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
[fossil-users] Pull requests
Given the discussion in the other thread(s), I have been thinking about pull requests. (I've also had a beer. You Have Been Warned.) I rather like the pull request workflow from github and Bazaar, and it's something that I rather miss from Fossil. However, given Fossil's different philosophy, I think the workflow needs to be modified. So what I'm proposing works like this: We have a maintainer M and a contributor C. C does not have checkin privileges to M's repository. 1) C clones M's repository. 2) C does some work in multiple checkins. 3) C points the Magic Pull Request tool at a commit. This spits out a bundle containing everything that's needed to add that commit (and its ancestors) to M's repository. 4) C sends the bundle to M. 5) M adds the bundle to their repository (or a clone of their repository). All of C's changes end up in a private branch. 6) M examines the changes, and either rejects them or merges them into trunk. Key point: all of C's branch and tag information is discarded --- M wants all of C's changes to end up in a *single* branch, so they're all safely isolated. This means that M doesn't have to worry about conflicting tag names. If C does branching and merging before the bundle is created then they'll all show up as anonymous ad-hoc branches in M's import branch. None of this actually looks very hard. The trickiest part is step 3. Exporting the bundle is easy --- the git exporter is only 400 loc. Calculating what goes into the bundle is the only bit of interest, and even that's pretty straightforward: a) construct set of all ancestor commits from the nominated one b) subtract all commits in M's repository c) export commits remaining Pulling the commit graph from a local .fossil file looks pretty straightforward --- experimentation gives me this: SELECT parent.uuid, child.uuid FROM plink, blob AS parent, blob AS child WHERE child.rid = plink.cid AND parent.rid = plink.pid; (That seems way too easy, so I'm sure there's something I'm missing.) However, M's repository is *remote*, so I don't have direct access to its database. What's the easiest way to get the same information from a remote repository? It doesn't matter if it's hacky; I'd like to put together a proof-of-concept... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Blue is beautiful... blue is best... │ I'm blue! I'm beautiful! I'm best! │ --- _Dougal and the Blue Cat_ 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] how to use git to lose data
On Tue, Sep 2, 2014 at 5:09 PM, Warren Young war...@etr-usa.com wrote: I've been running an open source project for a decade now, so I can tell you from experience that a lot of patches come in that do multiple things. Apparently, the projects I've submitted patches to have stricter rules. Now that I think of it, most projects probably can't afford such strict rules for patches. Not sure what I would do if I were actually running an open source 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] Pull requests
Let me see On Tue, Sep 2, 2014 at 2:49 PM, David Given d...@cowlark.com wrote: 1) C clones M's repository. 2) C does some work in multiple checkins. 3) C points the Magic Pull Request tool at a commit. This spits out a bundle containing everything that's needed to add that commit (and its ancestors) to M's repository. 4) C sends the bundle to M. 5) M adds the bundle to their repository (or a clone of their repository). All of C's changes end up in a private branch. Alternatively, M always operates on a clone, obviating the need for the private branch. It would just be a branch. ... Ok, it is less secure given that M may forget to make the clone. Maybe M should have a Magic Pull Request Receiver Tool as well, to feed the bundle into; and it does all that (clone, import, ...) 6) M examines the changes, and either rejects them or merges them into trunk. None of this actually looks very hard. The trickiest part is step 3. Exporting the bundle is easy --- the git exporter is only 400 loc. Calculating what goes into the bundle is the only bit of interest, and even that's pretty straightforward: a) construct set of all ancestor commits from the nominated one b) subtract all commits in M's repository c) export commits remaining Pulling the commit graph from a local .fossil file looks pretty straightforward --- experimentation gives me this: SELECT parent.uuid, child.uuid FROM plink, blob AS parent, blob AS child WHERE child.rid = plink.cid AND parent.rid = plink.pid; (That seems way too easy, so I'm sure there's something I'm missing.) However, M's repository is *remote*, so I don't have direct access to its database. What's the easiest way to get the same information from a remote repository? It doesn't matter if it's hacky; I'd like to put together a proof-of-concept... What your are proposing is actually a sync over mail with the complicated part the detection of what M has and you therefore do not have to send. That information is part of a regular pull operation, so if we can invoke only the steps to get that, without actually sending any content back, then your new tool knows what the other side has. More info on this in http://fossil-scm.org/index.html/doc/tip/www/sync.wiki Note that this requires digging into the fossil sources and extending it with a command which runs the limited pull delivering the necessary igot's from M to C, and printing the data for your tool. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pull requests
On Tue, Sep 2, 2014 at 5:49 PM, David Given d...@cowlark.com wrote: I rather like the pull request workflow from github and Bazaar, and it's something that I rather miss from Fossil. Last time I actualy used github (as opposed to simply getting the latest sources for one thing or another), a oull was a an actual pull from an actual git repository. A contributor would clone the project repo to a new repo, located on githud but owned by the cloner (github called this forking). Then (s)he would clone the clone to the local PC, work and commit locally, then push the changes to their own github repo. Then (s)he would go to their repo's github page and click on Pull Request. Later, the responsible project dev could pull from the contributor's github clone of the project. The same could be done with Fossil. The big difference being that while git will pull the remote changes in to a staging branch, there by automatically isolating the changes, Fossil does no such implicit branching. As such, the pulling dev would necessarily have to make a fresh clone into which to pull the contributor's changes. (IMHO, this is a good practice anyway. (And, hopefully, the contributor made a feature branch to contain their changes.) Your proposal for automatically calculating a list of commits to treat as already exported is a very good idea. Would definitely make the incremental export much easier to use. Your proposal to automatically strip (or rename) branch/tag info is likely to break something. If nothing else, I would expect the commit IDs to be changed. In theory, commit ID changes could be mitigated by creating a special tag to hold the original commit ID, but that will invite new issues with resolving ID ambiguities. I'm not sure about what other problems that might be created. But the automatic export calculation is definately worth pursuing. ___ 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] Pull requests
On Tue, Sep 2, 2014 at 3:36 PM, Ron W ronw.m...@gmail.com wrote: Your proposal for automatically calculating a list of commits to treat as already exported is a very good idea. Would definitely make the incremental export much easier to use. Your proposal to automatically strip (or rename) branch/tag info is likely to break something. According to http://www.fossil-scm.org/index.html/doc/tip/www/fileformat.wiki#manifest a manifest (= committed revision) can indeed contain T'ag information. I am not sure under which circumstances such information is actually added (vs just possible). ... Ah, seems to happen when you commit --branch (looked at some of my own repos where I usually do that instead of 'branch new'.). So, yes, stripping information entirely is not possible, only creation of additional control artifacts which would cancel such tags. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On 9/2/2014 16:07, Ron W wrote: On Tue, Sep 2, 2014 at 5:09 PM, Warren Young war...@etr-usa.com mailto:war...@etr-usa.com wrote: I've been running an open source project for a decade now, so I can tell you from experience that a lot of patches come in that do multiple things. Apparently, the projects I've submitted patches to have stricter rules. Oh, I *have* the rule. That doesn't stop people from violating it, though. :) Not sure what I would do if I were actually running an open source project. 1. Be an ogre, and yell at the person to resubmit, then 50% of the time get no answer, so you have to... 2. Sigh, then dice the blob-o-hackage up into multiple patches, and apply them. Then when you get tired of the bad odds on #1, start doing #2 by default. ___ 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] Pull requests
Proposed plan of action: (1) Modify private branch processing to avoid the private tag and instead simply rely on the private artifacts residing in the PRIVATE table, which should survive a fossil rebuild. (A fossil deconstruct; fossil reconstruct will make all private branches public since there is no record of which are private in the deconstruct, but who ever does that?) (2) Create a new fossil bundle export command that generates a bundle from a designated branch, or all check-ins following a particular check-in, or just a single check-in. The bundle format is an SQLite database file (essentially the BLOB and DELTA tables, but with a few minor differences). The bundle assumes that all artifacts that existed prior to the first check-in of the bundle also exist on the destination and avoids resending those artifacts, and can use those artifacts as the source for delta-compression. The bundle includes information (in the CONFIG table perhaps?) about the project-id and the parent check-in(s) of the first check-in of the bundle, etc. Aside: An SQLite database of compressed BLOBs is as small, and sometimes smaller, than the equivalent ZIP archive. See http://www.sqlite.org/sqlar/doc/trunk/README.md for additional information. That webpage says that SQLAR files are about 2% larger than ZIP. But when I SQLAR an open-office odp presentation (which is really a ZIP archive) the SQLAR equivalent comes out about 0.5% smaller! (3) Create a new fossil bundle import command that imports a bundle as a *private* branch. Do not stress over branch-name collisions. Fossil is perfectly happy having two or more concurrent branches with same name. The human user might get a little confused with that, but not Fossil. To help avoid confusion among the humans, perhaps all bundle import check-ins and file artifacts should have a distinct background and/or foreground color to make their special role clear to the viewer. (4) Create a new command and new web pages that will delete a private branch or a portion of a private branch. I don't yet know what this command is called. (Suggestions?) Maybe this same command will also delete a public check-in that has not yet been synced - I recall that there have been requests for that feature. The UNSENT table can be used to discern whether or not a check-in has been synced. As this operation is not undoable, there will need to be dire warnings with an are you sure? prompt. (5) Create a new command and perhaps a new web page that will publish (make public) a private branch or check-in. I don't yet know what this command is called. (publish? Other suggestions?) This operation is not easily undoable, so there will need to be an are you sure? prompt, though with a less dire warning, since the worst that can happen is some ill-advised changes get pushed to the main repo and then have to be shunted off into a mistake branch or somesuch. -- 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
