Re: [fossil-users] Why do we need a fossil hosting service?
On 3/30/13, Stephan Beal sgb...@googlemail.com wrote: Fossil _repos_ are indeed intended to be used by relatively few people at a time. Fossil is designed for small, relatively tight-knit teams. It does not directly support deep hierarchies of developers like git does. From my limited experience with git, a few years ago, git does 2 things that require extra effort to do in Fossil: 1. Changes from below do not automatically propogate. This allows (requires) adevelopper to inspect/integrate received changed before sending them up. 2. A developper can receive changes from his/her subordinates in to a named branch. That is, the subordinate's trunk is pulled/pushed in to the receiver's repo as a named branch. The receiver then explicitly diffs/merges/integrates the received changes in to his/her trunk (or other branch) #2 could be handled by the subordinate developpers only commiting changes to named branches instead of the trunk. Working using named branches is a good idea, anyway, so this is not much of a burden. As for #1, as long as the subordinates are only commiting to named branches, if those branches are tagged privated, then they won't be automatically propogated. Question: If I push my non-private, named banch to another developper, can he/she tag it private in his/her repo, or will my pushes override the private tag on my branch in his/her repo? Also, I forget, can pushes/pulls to trunk be blocked while allowing to named branches? ___ 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] Why do we need a fossil hosting service?
On 03/30/2013 02:59 AM, Stephan Beal wrote: On Sat, Mar 30, 2013 at 4:06 AM, Steve Havelka yo...@q7.com mailto:yo...@q7.com wrote: You're saying that Fossil is intended to be used by few people, or that Fossil is intended not to have a user community? Fossil _repos_ are indeed intended to be used by relatively few people at a time. Fossil is designed for small, relatively tight-knit teams. It does not directly support deep hierarchies of developers like git does. I think the original poster, in mentioning community and the momentum that can come with it, was not referring to the number of contributors to any given project. My suspicion is that most of the repositories on Github have one or a few contributors, too. I think--and speak up please, Matt, if I'm misinterpreting or have misunderstood you--that Matt was obliquely referring to how much better off a tool is when there are lots and lots of people using it, improving it, building auxiliary tools around it, thinking on it, etc. I think it'd be just grand if lots more people used Fossil, and brought their ideas, code, and improvements to the table too. I can't really see a downside to this. That's the sort of stuff that Github has helped do for git, that we'd do well to have built around Fossil. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] auto.def:79: Error: Request for undeclared option --markdown
On Mon, Apr 1, 2013 at 9:14 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: Starting with [4dcea80236] http://www.fossil-scm.org/index.html/info/4dcea80236 on linux, I get: $ ./configure Host System...x86_64-unknown-linux-gnu Build System...x86_64-unknown-linux-gnu C compiler... cc -g -O2 Build C compiler...cc Checking for stdlib.h...ok auto.def:79: Error: Request for undeclared option --markdown I was receiving the same message too, but on FreeBSD 8.3. On Windows everything is OK. I too received the same message when compiling with Visual Studio 2010. However, I tried a later revision, 9f931a7569, and both appear to work fine on Windows and FreeBSD. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] font boosting on chrome for android phone
Hi, I get an android phone recently, and I notice that the fossil timeline look weird on it, some commit entry have bigger font size and this make the timeline to look pretty ugly. I see the same thing with chrome and firefox for android while I never had this problem on my iPhone before. After googling a bit, I found that this is cause by the font boosting feature that is supposedly buggy. http://stackoverflow.com/questions/11289166/chrome-on-android-resizes-font After trying some of the suggestion from this link, I found that adding: min-height 1px; max-height: 99px; for the div.content element on the CSS configuration solve the problem and in my case, it doesn't affect my desktop browser. (chrome and firefox) Someone else notice the same ? Would it be possible to add this workaround if it doesn't break other browser ? I don't have much experience in html/css to tell if this is the best workaround. Regards, -- 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] Why do we need a fossil hosting service?
On Tue, Apr 2, 2013 at 4:12 PM, Steve Havelka yo...@q7.com wrote: On 03/30/2013 02:59 AM, Stephan Beal wrote: On Sat, Mar 30, 2013 at 4:06 AM, Steve Havelka yo...@q7.com wrote: You're saying that Fossil is intended to be used by few people, or that Fossil is intended not to have a user community? Fossil _repos_ are indeed intended to be used by relatively few people at a time. Fossil is designed for small, relatively tight-knit teams. It does not directly support deep hierarchies of developers like git does. I think the original poster, in mentioning community and the momentum that can come with it, was not referring to the number of contributors to any given project. My suspicion is that most of the repositories on Github have one or a few contributors, too. I think--and speak up please, Matt, if I'm misinterpreting or have misunderstood you--that Matt was obliquely referring to how much better off a tool is when there are lots and lots of people using it, improving it, building auxiliary tools around it, thinking on it, etc. I think it'd be just grand if lots more people used Fossil, and brought their ideas, code, and improvements to the table too. I can't really see a downside to this. That's the sort of stuff that Github has helped do for git, that we'd do well to have built around Fossil. Yes, although lots of contributors to a single project might be great and might need the features that git provides that is not the collaborative energy I'm referring to. It is more that there are lots of people browsing github, using git itself, and, occasionally, finding interesting projects and forking them and making contributions. I think that fossil will grow into a better tool with more widespread use and a hosting service with some features that make participating in existing projects in a detached way (i.e. unblessed forks) could contribute to that growth. Because it is easier to use than git (at least in my opinion) fossil does have an opportunity here to grow if the existing community wants to make that happen. It seems to me that unblessed forks could be supported within the same repository with by adding some optional features: 1. Allowing logged in users to create branches with their user name as the prefix. 2. Adding branch name pattern filtering to sync. 3. Adding a mechanism to shun based on branch name. A project owner could turn on the name-prefix branches to enable unblessed contributions. People could sync everything or just the things they want using the branch filtering. Cleaning up after a mistake or obnoxious user would be as simple as shunning all on that branch. I know that the database uses deltas and it I suspect some of these actions might require some non-trivial re-processing of stored data but it does seem technically feasible and might be worth considering for implementation one day. . -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://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
