Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Mon, Dec 31, 2012 at 8:21 AM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/31/12 11:17, Nico Williams wrote: But I feel I must at least address this insinuation that I was trolling. It's obvious that you aren't trolling. You don't have to defend yourself against such nonsense. At this point, I'd like to apologize the readers of the list, including Nico. My intent was not to be hostile or insulting. I was trying to get a description of the functionality he was looking for in terms of fossil's existing commands to be sure I correctly understood what he was suggesting. I got frustrated when he repeatedly ignored the question, and then outright refused to answer it, and clearly stepped over a line. Again, my apologies to all concerned. mike ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: Go back through those 30 posts you mentioned. Go back to the very first one from me. I tried to be concise and wrote just three paragraphs that, IMO, captured what was needed. I certainly did not say I want git rebase in fossil and then watched the fireworks -- no, I explained *concisely* (or at least that was my aim). No, you said I want something slightly different than git rebase in fossil. Concise? Yes. Precise? No. Well-defined? No. Useful? No. If I had written a ten-page post explaining in excruciating detail what rebase is, why it matters, and how to adapt it to the Fossil philosophy, who -but who!- would have read that first post? I was being (I thought!) considerate. And judging by last night's 30 posts, would it have made any difference to post a thesis-length argument for rebase? And if so, how was I to know that? Or should I have given up at the very first sign of trouble? That depends on the goal. If you want to troll the list, then arguing for rebase is a good choice. If you want fossil to incorporate a solution for your problem, you should provide the information people are asking for. Given how poorly your attempt to work with the comunity has gone, giving up now isn't an unreasonable option. On the other hand, if you want to be able to use fossil, and are willing to work with us to solve your problem instead of arguing about what rebase does, you can start by answering our questions. For instance, you haven't answered any of my questions. You've explained in detail what rebase does, but that's irrelevant, because rebase is only an approximation to what you want, and you haven't explained how what you want is different in sufficient detail for us to figure out what that is. You haven't shown us why the existing solutions are to much work. You haven't said what kind of interface you want (otherr than interactive rebase, and you haven't said what that interface looks like!). You may think you have, but your opinion here doesn't matter: if we don't have a clear understanding of what you want, we don't have it, and the onus is on you to provide it. The best way to do that is by answering our questions. rebase is just a name. Forget it. Quit trying to convince us that rebase is compatible with fossil. Show us that *what you want* is compatible with fossil. Of course, that has to start with a *precise* description of what you want, in fossil terms, not in git terms. Give us an *example*. Simplify it as much as you can, but leave in all the features you want. Show us how you'd do it with fossil now. Show us the commands you would like to have (and call them TBD or some such), and how we would use them. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: In the first message of these, Mike Meyer, first ruled out the whole tool (Git) due to hating its optional feature If you're going quote someone out of context, at least get their reasons right. You called rebase a killer feature of git. Ok, you like it. I consider rebase a serious misfeature, as it reflects an underlying philosophy for the tool that I flat disagree with. As far as I can tell, rebase is *not* optional. At least, it's enabled in my install of git, and I've never run into a way to disable it (or, for that matter, a git tutorial that didn't gush about how cool and wonderful the rebase command was). This should be compared to mercurial, where rebase is available - but in an extension that's turned off by default. *That's* an optional feature. You may enjoy trying to force your philosophy onto a tool that was designed with a completely different philosophy in mind, but I've got better things to do. There are DSCMs designed with a philosophy that I agree with. I'll use those, and not annoy the git folks by trying to get them to remove history-altering commands. and then proceeded with a fancastic technical argument against it: None. Zero. Nada. Never.. That wasn't a technical argument, that was an answer to a question you asked. Ok, maybe your question was rhetorical because you assumed everyone would have the same answer you do, but my answer is still None. I have never been asked to edit commits on a submitted patch. In any way. I don't think I've ever worked on a project were asking someone to edit commits would be considered acceptable behavior. You totally ignored my question to you, which asked for more details about your proposal. While rebase pretty much isn't going to happen (as I explained, it's contrary to the philosophy of fossil), you suggested a feature that sounded like it wouldn't clash with that philosophy. However, your description was rather vague. If you can get off your high horse long enough to describe what you'd like done in terms of commits and how they show up on the new branch, as opposed to rebase, it might get some consideration. But please don't continue wasting everyone's time by just complaining that people disagree with you. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: I suggest you to calm down. I see my plead to not being zealous was in vain, so just please calm down at least. I am calm. Yes, I'm a little bit bothered about being insulted in various ways, but I'm trying to return the discussion to the technical merits of a proposal by getting a more detailed proposal from the OP. If you can't contribute to that technical discussion, please don't contribute to the discussion. mike ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: tl;dr: we agree that public history should not get rewritten. You missed the point of when, where, and why I need rebase. Which is why I asked for clarification about that point. See below. On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: Rebase is one of teh killer features of git. It certainly kills any interest I have in using git on a regular basis. Why? You don't have to use it if you don't want to. Because it indicates that the designers of git and I have a fundamental disagreement about what a SCM is for. This means it's very likely that using git is going to be one pita after another (which in fact it turns out to be). It all depends on the upstream though, doesn't it. I've worked with projects where the upstream want commits split because arguably a given commit does two things instead of one (e.g., fix a bug and a buglet). It doesn't all depend on the upstream. Part of it depends on you. You always have the option of saying No when someone makes such a request. You missed the point. The only thing that should ever get rebased is private branches (i.e., that no one should ever pull from). Once something's in an official repo it should never get rebased. You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. That's exactly what rebasing is. Here's the difference between git and fossil then: git has a nice tool for interactive rebasing (several, really, if you count git add -p as a tool for rebasing because it is so useful when splitting commits); fossil doesn't have that. Can I rebase with fossil? Yes, definitely. I just have to manually pick commits to merge, manually build the command lines, manually track the state of a complex rebase (this is the hardest part). And sure, I could script it, but the beauty of the git rebase -i interface should be built-in. This doesn't provide an answer to my question at all. A feature request can't simply be I need other-scm's foo command. Especially when said command is one that is philosophically unsuited to fossil. For instance, I'd love to have hg's rollback command, but I'd never suggest it with those words. Instead, I described what it did, and suggested a command syntax, and possibilities for some problematic cases. I already got that you have a need for rebase that you think is compatible with fossil. You've provided a use case, and I agree that fossil could handle that reasonably. But you haven't actually proposed a new command for fossil, other than rebase, which has already been rejected multiple times. Do you want a more controlled merge for this? I know I'd like a more controlled merge; compared to perforce's 3-step merge, everything else feels like throwing code at the wall and hoping the right bits stick. But maybe you want a less-controlled merge. I can't tell from the descriptions you've given. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org wrote: You missed the point. Nothing should *ever* be rebased. It's a rewrite of history, which is a fundamentally bad thing. While a SCM should make generating patch files easy, it shouldn't require rewrites of history to do so. You missed my proposal that a fossil rebase operation always copy the branch being rebased and rebase that copy. It was in my very first post on this thread: I didn't miss it. I asked for clarification, for two reasons: 1) Rebase involves two branches, both of which get changed. Your proposal only mentions one. Given that I'm not all that familiar with rebase, I have *no* idea what this means in terms of additions to the history tree. 2) Your use case (generating patches to make upstream happy) isn't one I've ever experienced, but it doesn't sound like it needs to change the tree at all. So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: What I'm proposing is that in fossil the rebase operation create a new branch named after the currently checked out branch (or named by the So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and -1. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org wrote: So, for the third time, can you describe your proposed new feature *without* saying the words git or rebase. No: it's too much work, and many people understand git rebase, and -1. So is that a -1 to the attitude, the proposal, or both? The proposal. It smells. Without a better description of the problem than I need rebase, its impossible to do the evalutation of alternative solutions that good engineering practices call for to decide if the smell is an indication of a real problem or not. Minimally, knowing how you solve this problem using existing fossil commands would help decide if to much work is a valid evaluation, a straw man, an overlooked fossil feature, or a need for a minor workflow tweak. But technical descriptions of why things like perforce's three-step merge or mercurial queues or any other alternatives mentioned here aren't acceptable are pretty much required. Given a proper problem description, I'd be glad to do that for the ones I'm familiar with. I'd also be happy if you want to provide those, but expect that it's also to much work. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 12:56, Nico Williams n...@cryptonector.com wrote: What is it about rebase that causes so many to miss the idea of a rebase that is NOT destructive because it creates a new branch instead of doing a destructive change to an existing branch? I don't know. You won't explain it. It's too much work, remember? You had left me under the impression that you knew what git rebase is. Fair enough, here we go: I thought I did, but then you said rebase works on one branch. Except... So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits Uh, that's *two* branches! What happened to rebase working on one branch? But the crux of the issue is right here: Other things that can be redone in a rebase would include: From what you've said, I believe that it's these *other things* that you want: an easy way to munge commits as they get copied to a new branch. I don' think that's an unreasonable request, as opposed to wanting rebase. After all, we can do that now with repeated cherry-picking merges. But without a more detailed description than I want rebase, it's hard to tell if that's the case or not, propose alternatives, and otherwise engage in the process of refinement that peer review is supposed to provide. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Restrict access on per-directory or per-branch level?
Stefan Bellon sbel...@sbellon.de wrote: On Fri, 28 Dec, Richard Hipp wrote: When somebody clones the repository,and has a local copy of the repository, then they can do anything they want with that local copy since it is a file they own. Permissions only come into plan when dealing with a remote server. Right. So, of course, the permissions should already restrict what one can clone. They do. It's just that they are at the repository level, not the branch level. But in many senses, a cloned repository *is* a branch. [push permission] The idea is that you trust your developers. This is not always possible. Back in our university days we had a stable code branch where only university employees were allowed to commit, but in certain branches, students were allowed to commit their work which was merged into trunk by employees. Students were not allowed to directly commit into trunk. So do that with repositories. Create a stable repository that only employees can commit to. Let students create their own repositories, or (if you feel the need) create a different one they can commit to. Then have employees merge changes from students into the trunk repository using an appropriate mechanism. This is regarding push permission. Of course, the other direction is problematic as well. E.g. if there exists 3rd party code that is used to build the complete product, but for which not each developer has the required license to see it in source form. Again, just create a repository that only developers that have the appropriate license can see. Making the results of building it available to others is an issue for your CI/OR/etc. system, not your version control system. Then we'll have to think about moving to Fossil with our main repositories again. Key word/letter there is repositorieS. Clones repositories in fossil (and other DVCS systems) are as cheap as branches in a CVCS, and have a lot of the same properties. Many things that you'd do with a branch in a CVCS you do with a clone in a DVCS. Since merging changes between repositories is only slightly harder than merging changes between branches, this really isn't a problem. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Nico Williams n...@cryptonector.com wrote: Rebase is one of teh killer features of git. It certainly kills any interest I have in using git on a regular basis. How many times have you submitted a patch to an upstream and then been told to make a bunch of changes, re-organize your commits, make specific changes to specific commits, and/or squash commits? Yeah, that's why rebase is good. None. Zero. Nada. Never. The thing is, I actually submit a *patch*, not a pull request or a commit history or anything that would invite such a request. That's also how I work merges between branches: the mrege is a single commit that incorportes all the changes from the other branch, or on rare occaisions a cherry-picked set of changes. The history is still there in the old branch if I want to review it, but the commit log for the trunk is nice and clean. That's one of the philosophical differences that determine which of the DSCMs you want to use. If the philosophy is that history is important, then you never rebase, and nobody would dream of asking you to make changes to your commits beyond making the comments more accurate. Rebase is not merely unnecessary, but anathema. If, on the other hand, the repository is considered to be part of the public face of the project like user docs or the web site, then editing it for readability and marketing purposes is SOP, and rebase is a critical tool. Fossil is designed to avoid destructive operations. Rebasing is a destructive operation. A compromise would be to allow rebasing but into a new branch, leaving the original alone -- this is how I do rebases in git anyways. I think you need to be mor explicit. Rebase is used for a number of different things, most in my (admittadly limited) experience with rebase it involves moving one branchinto another. It sounds like you're wanting to use it to rewrite a single branches history onto a new branch. If that's the case, can't you just do it with a series of cherry-picked merges? If so, could provide an example and show how rebase would make it easier? If not, maybe explain what you want to do? -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Fossil vs. Git/Mercurial/etc.?
Michael Richter ttmrich...@gmail.com wrote: On 19 December 2012 07:33, Mike Meyer m...@mired.org wrote: for u in $DEVS ADMINS $READERS do # create user name from company mail address, password is PWname. fs new $u $u...@company.com PW$u -R $REPO done for dev in $DEVS do # Set up developers fs cap $dev v -R $REPO done I know I'm probably going to come across as being thick as a whale sandwich here, but ... what is this fs thing? No, it's my bad. fs is my local alias for fossil. I should have replaced expanded it before sending in the examples. mike -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] PLOS (II)
On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff veedeeh...@googlemail.com wrote: I would find it far more intuitive if _after_ a `clone' of the above sort (password query for `myname' and all) the corresponding local user would be created automagically and also be set to the default user so that I'm Nothing to do with computers is intuitive. At best, it's familiar because it acts like something else you had to learn to use. Personally, I'd be *very* surprised if I cloned a repo and it copied *any* password information, no matter what auth* was done during the clone. That's just a huge security faux pas. Creating users without passwords is even worse. which again 99.9% of the time should be what the user wants anyway (and might be really surprised to not have happened autmatically). I disagree. It might be what the user wants to happen 99% of the time for local clones, but I'd say that the current default (current login name) does that 99% of the time as well, without opening up the possibility of unknowingly handing someone a clone that includes your password. For remote clones - things change. I almost never want the same password on the two ends (again, a security faux pas) and don't really care whether or not the username is the same. Given that it takes one command to create a user password vs. one command to set the password, automatically creating the same username with a new password is at best a meh. ___ 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] PLOS (II)
On Thu, Dec 20, 2012 at 2:11 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer m...@mired.org wrote: I'm just proposing to automate what you do manually in the considered situation (including chosing a different local password, why not?): create the user, make him the default, choose some (local) password. where'd be the problem? Well, for one, it's a violation of what POLS means (as opposed to simply I was surprised). POLS means that you can correctly extrapolate how the software will behave in some situation by observing how it behaves in other situations. Fossil always uses the current login name as the default user name when a repo is created (whether by cloning or ab initio). Since that's the only observed behavior, doing that in one particular instance can't be a violation of POLS. In fact, if fossil were to change so that some particular case the default user name were something else, that would be a violation of POLS. And as I said, just setting the user name doesn't buy anything. Either it's a clone that's not going to have a password, in which case the default user name is already what I want it to be, or it's going to need a password, in which case I have to issue one command whether the user exists or not. I don't believe that this change would buy anything, much less enough to warrant the violation of POLS that it calls for. ___ 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] Fossil vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 12:06:05 +0100 Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. A lot of the things you discussed have been touched on, but not this central point: The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. This is a description of workflows, not SCM properties. I've never used that workflow with either git or mercurial (part of my believing that history is sacrosanct). I've pretty much always pushed pulled everything no matter which DSCM I use. In SCM terms, this boils down to fossil not having an easy way to cherry-pick changes to move between repositories. The default push/pull for mercurial is the same as fossil - everything. For git, it's more complicated, but I believe it can be configured so you get the exchange everything behavior if you want it. The bottom line is that if your organization needs fine control over which changes gets exchanged between repositories, fossil isn't for you. At least not yet. It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil vs. Git/Mercurial/etc.?
On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 00:02:11 +0100
j. v. d. hoff veedeeh...@googlemail.com wrote:
even for small teams I'd prefer to be able to do user management (easily)
from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?
Nope, it doesn't.
some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...
It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.
would be nice to have. fine-tuning might be delegated to the webinterface
but
the basic things (adding admin users, development users etc) should be
possible otherwise.
I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:
for u in $DEVS ADMINS $READERS
do
# create user name from company mail address, password is PWname.
fs new $u $u...@company.com PW$u -R $REPO
done
for dev in $DEVS
do
# Set up developers
fs cap $dev v -R $REPO
done
Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.
mike
--
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.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] why does `fossil rm' not do the real thing?
I don't really care which behavior is the default. I've dealt with both long enough that neither is surprising, and my workflow doesn't change enough to notice for this. I'm just tired of seeing the bogus claim that one is somehow surprising and natural and one isn't. The only thing I want to avoid is a builtin fossil rm that can do different things in different repos that are supposedly running the same version of fossil. Well, ok, I also really don't want the silly git behavior of having to force the SCM to record a move in the repo that's already happened on disk. On Sun, 16 Dec 2012 11:06:57 -0500 daniel gregory gig...@gmail.com wrote: Yes, but - as has been written so many times now that it's not even funny any longer: rm/mv has a canonical behavior, and new users continue to be surprised by the current behavior. This is so true. Only if you behave the way you want to: not for something where I have to think rm in unix is this, but rm in fossil means this. It doesn't matter whether it touches the work space or not, rm in fossil means something different than rm in unix. It *has* to. Unix doesn't know anything about fossil repositories, so it's rm *can't* deal with them. The only thing that would be surprising is if fossil rm actually did what unix rm does, and removed a file from disk without changing the repo in any way. The only way you can be surprised by either behavior is if you do what daniel suggests, and *don't* think about what you're doing. This kind of surprise - cause by thoughtlessly extrapolating from a *different* command set - is not what POLS is about. Otherwise, Unix would have a DEL command because people coming from VMS/DOS/RSTS/etc were surprised that it didn't. I don't see anything *in fossil* that would lead one to expect rm or mv to have either behavior. My gut reaction: This is a silly argument, caused by people being overly attached to those two-letter commands. Just nuke them both. del and ren both work fine, and are only one character longer. A --filesystem/-f flag would be nice if the commands don't change. If they change to touch the filesystem - well, make sure they always queue changes to the repo for the next commit, even if they fail to change the file system for some reason. And a flag that says repo only, ignore the file system would probably be appreciated by some. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] why does `fossil rm' not do the real thing?
On 12/12/12, Themba Fletcher themba.fletc...@gmail.com wrote: to alias 'fossil rm' to 'fossil rm -f'. That is a disaster waiting to happen. If the user in question forgets that they've done that, and then runs a series of commands from someone who *didn't* do that (either cut-n-paste from an answer on the list or the web, as part of a script for doing something, or whatever), they'll wind up removing files that nobody wanted removed. An alias mechanism is fine, but it really shouldn't let users change the behavior of builtin commands. Either aliases should have to have different names, or be invoked by some other mechanism. Both of those sort of defeat the purpose of the rm alias, though. mike ___ 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] howto `grep' through old revisions
Stefan Bellon sbel...@sbellon.de wrote: I'd rather vote for a list all matching revisions in the --all case and the default behaviour to stop at the most recent match. I think there are three cases, the third being the earliest matching revision. Especially if the current revision is a match. Having the default list both most recent and earliest seems like a reasonable alternative. -- Sent from my Android phone. Please excuse my swyping.___ 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] suggestion
On Mon, Nov 19, 2012 at 6:13 PM, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff veedeeh...@googlemail.com mostly I would like to get information here whether there are changes (edits, adds, removals...) or not and what files are not tracked. `hg stat' does provide that. in fossil I have to do `fossil changes' _and_ `fossil extras'. [...] Maybe we could invent a system whereby a user could create their own fossil commands to suite their own tastes? So you could define a site-specific fossil stat command that simply runs changes and extras in succession. Would that help? Mercurial has a couple of such features, and they are useful. The reason there are a couple (and the reason I bring it up) is that they learned the hard way that letting users override standard commands breaks scripts. So either a script command (that defines and executes such scripts), making the above fossil script stat, or make sure that builtin commands are checked first, and possibly warn about defining commands that are shadowed by builtins. mike ___ 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] fossil backend for zsh vcs_info...
On Mon, 15 Oct 2012 10:14:42 +0200 Gour g...@atmarama.net wrote: On Sat, 19 Feb 2011 06:25:32 -0500 Mike Meyer m...@mired.org wrote: Any other zsh users out there? If so I couldn't find a fossil backend for the vcs_info facilities in zsh (an API to extract info from various vcs's to display in your prompt), so I wrote one. I'm back to zsh (after some experiments with fish) and I see that Changelog for new zsh mentions fossil as supported VCS, but wonder where one can find some more docs and/or what is required to enable it besides autoload -Uz vcs_info ? It's used pretty much like all the VCS backends that zsh has support for. They are documented in the zshcontrib man page, including a quick-start. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] status of TODO list (was Re: comparison with Git)
On Sat, 13 Oct 2012 09:27:38 -0400 Richard Hipp d...@sqlite.org wrote: On Sat, Oct 13, 2012 at 4:06 AM, Gour g...@atmarama.net wrote: Now, I'm curious about some of the items from the TODO list (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List) and their status: * Uncommit All what I need is simple mechanism to quickly 'fix' some wrong commits without tinkering deep into the commit history. Deleting content from a repository is scary. A bug in the delete logic could easily cause loss of information. [excellent explanation elided] Hence, I am reluctant implement uncommit on a repository. [...] Brainstorm: A potential work-around How about a second one? Uncommit limited to the last commit, for the 'oops' commits where your fingers got ahead of your brains, or you realized seconds after making it that one of the globs included files you didn't commit, and so on. This is about the only kind of uncommit I ever want. The repo would keep track of the last commit, and allow it to be removed. Any non-commit commands that made removing it dangerous would NULL that out, so you could no longer remove it. Syncing remote repositories makes removes interesting. I believe that the git tutorials recommend not removing any commit that's been pushed, because - well, it just screws things up. I think this limited version might be made safe: - uncommit after a push is ok - syncing a removal only works if the commit is removable on the receiving repo. - failing to sync a removal is a warning, but doesn't stop the rest of the sync. In this case, the removed commit eventually comes back everywhere. On the other hand, you could make push clear the removable commit, and have uncommit simply not available if autosync is on. I suspect you want that for most forms of uncommit in any case. Your proposed workaround has similar issues. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Actually... No. Fossil, with it's monolithic single-app design, is relatively hard to both extend and embed. Actually there are two kinds of people in the world, those who expect something to do whatever they think it should, and those who look at what it is designed to do, and how it is designed to be used, and then either use it accordingly or find something else. Of course success in extending or embedding depends on the level of available skill in awk or Perl or Expect or whatever. Remember that the target end-user for Fossil is a developer! Yeah, you pretty nailed it. A perfect explanation why Fossil's integrations into various IDE's, GUI front-ends and other integrations are so popular. I may be OK with CLI, but it already bit me a few times: I can not use Fossil in my day job, because there's no Eclipse plugin (apart from that, the team said whatever, we're free to start new projects in whatever VCS that Eclipse supports). Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. The mercurial folks have a Python API, but strongly recommend that you just run hg, as they work to keep that compatible between versions, and make no such effort with the Python API. It seems to have a plugin for most GUI IDEs. But don't say it's easy to extend by writing a separate client or ipc-ing to this one... Why not, it's a perfectly acceptable technique. Acceptable, yes, in some circumstances. In *far* more circumstances than linking to a library is acceptable. But compare: open3 a process and parse the output (is it even guaranteed to be stable?) to a function call... Well, an API - no matter how it's implemented - is only as stable as the developers make it. Whether or not you break an API when you upgrade the provider depends *far* more on the developers than whether they chose to provide it via an executable or a shared library. And if you're going to compare them, compare the entire process: One is - well, open the executable and parse the output. The other is: select a language that can be coerced into linking with the library you want to use, write or find a wrapper if it's required that will translate between calling conventions and data types, load the shared library and wrapper code, and *now* you can call your wrapper to get and convert the data. Oh, and if you want to let someone else use your plugin, you have to make sure all the licenses involved are compatible. Nuts, after writing the Python wrapper for the perforce C++ library, I wound up rewriting it for our Windows group to use the p4 command instead of the library, because that was easier cheaper than buying the C++ compiler used to build the Perforce Windows binary and porting Python to it. But it made our support scripts portable across Windows and Unix. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] comparison with Git
Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Oct 10, 2012, at 14:28 , Mike Meyer wrote: Well, the lack of an in-binary API certainly isn't the reason there's not an Eclipse plugin. The Eclipse license is incompatible with the GPL, so any scm that's GPL'ed (*cough* git *cough*) isn't linked with Eclipse, but probably uses a process API. But Fossil is not GPL. It would make perfect sense to link it wherever you'd like. For Git, it seems that it's primary implementation is a bit too messy for most big projects, so they simply reimplement it. Eclipse's implementation is called JGit. And it does provide a reasonably stable Java API, used by a few projects. Yeah, the *reimplimented* git in order to avoid the language and license issues of using the git code directly. That pretty much kills the argument that having to invoke fossil as a command is to much work! On the other hand, Fossil's implementation is (apart from the regular forking) quite nice. I'd bet you a beer that once the JSON API is finished (in my already outlined understanding), it will be used by some useful projects. No bet, because I agree with you. Except that I consider using modern concurrency technics a plus, not a minus. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Linux binary compatibility
On Thu, 27 Sep 2012 15:30:38 +1000 Christopher Vance cjsva...@gmail.com wrote: The binary runs fine if the shared libraries used on your distribution have the same version numbers as those the binary is compiled against, and assuming the same library source version gets to be the same library runtime version. Just like DLL hell. And gnu CC/glibc between them make building a truly static binary nearly impossible, if not completely so. I'd assume you can avoid those issues if you're writing assembler. Best is to use a prepackaged version from your Linux vendor or to compile yourself from source. Unfortunately true if you're using a Unix that uses glibc. Which leaves only the Mac with enough users to make a binary distribution worthwhile. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] comparison with Git
On Fri, Sep 14, 2012 at 8:35 AM, Michal Suchanek hramr...@gmail.com wrote: The thing to which promoters of immutable history are blind is that while exact history record of development of particular feature might be interesting and educational it is not the primary purpose if VCS. That depends on what you're using the VCS for. Given that I use the VCS to capture an exact history of the change sets I thought were worth committing, that *is* it's primary purpose. And the makes *sense* is the crucial part here. When you learn maths you often hear something like this theorem AB was first proven by XY using method CD but we will today prove it using a much shorter and easier to understand method EF. Similarly, when implementing a feature into a piece of software the real history and the logical changes that make sense and are easy to review are often quite different things. True. And which of the two things you are interested in will depend on *why* you're using the VCS. For me, the *real* history is the important thing. Yeah, I may record having done something the wrong way, but having a record of the wrong way and the results of doing it that way is *also* important. Others can either skip doing that exploration, or look through the history to see *why* that way is wrong. With git you get powerful history rewriting commands. The drawback is that you have to be careful to not lose anything important in the rewriting. Your view matches the common view of git users, which follow the Linux project and treat the repository as part of the public face of the project. If you look at things that way, not being able to edit the repository history makes about as much sense as not being able to edit the web site. I see the VCS as part of the internal project documentation. Being allowed to edit it makes as much sense as editing generated API documentation to change function signatures. mike ___ 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] comparison with Git
Wes Freeman freeman@gmail.com wrote: The fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. Well, you can choose whether or not to use it locally. But once you share the repo, anyone you pull from can use it and force you to live with all the things that caused you to decide not to use it. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] comparison with Git
Michal Suchanek hramr...@gmail.com wrote: On 14 September 2012 18:49, Mike Meyer m...@mired.org wrote: Wes Freeman freeman@gmail.com wrote: The fact of the matter, though, is you can choose whether you want to use that feature of git or not; you're certainly not forced to use it. Well, you can choose whether or not to use it locally. But once you share the repo, anyone you pull from can use it and force you to live with all the things that caused you to decide not to use it. What you pull from them is up to you when you do the pull. So you end up with two (or more) repos for the same project with different histories? And this is supposed to be better? I think I'm better off choosing software designed to do the job I want done. Which in this case is to preserving history. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Turning off change tracking for certain files
On Mon, 2 Jul 2012 08:08:18 -0400 Richard Hipp d...@sqlite.org wrote: I am willing to *consider* some option that says do not commit these files, even if they change, unless that are specifically named on the command-line. I think this would be easy to implement by messing with the is_selected()/if_selected() function http://www.fossil-scm.org/fossil/artifact/9b15f53f6?ln=1366-1385. My issue with this solution is that this doesn't really solve the problem as I've encountered it. That is, a config file that needs local changes to run/build, but with a base version in the repo that needs evolves along with the project. My solution has been to push things out to the build system. What gets stored in the repo is config.template. In this, the values for everything document what they are used for. The end user (or a command run by them, depending) creates config from that, filling in the values as appropriate. The build (or launch, depending) system breaks if the local version doesn't exist, and issues a warning if the template is newer than the local copy (when it gets updated). A SCM system could do that, with a private branch of the config file for everyone who is building (running) the project, but that seems like overkill. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] build fossil with ssl support on debian and ubuntu
On Mon, 02 Jul 2012 23:21:39 +0200 ahrens benedikt.ahr...@gmx.net wrote: I should add that openssl is installed: $ which openssl /usr/bin/openssl That's the binary, not the bits you need to compile code that uses it. Just one of the many reasons I develop on FreeBSD: they don't do that. If you had openssl installed, you'd have the bits you needed. Could anybody tell me how to compile fossil with openssl on Debian/Ubuntu, please? I recommend aptitude for this: sudo install build-dep fossil Which will install all the build dependencies used by the fossil binary you installed. That way, you'll get any that are missing besides openssl. Of course, if it's not in your repository, or they built it without openssl, you'll be out of luck. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Propose changes
On Tue, 12 Jun 2012 10:32:14 +0300 Baruch Burstein bmburst...@gmail.com wrote: On Tue, Jun 12, 2012 at 1:36 AM, Mike Meyer m...@mired.org wrote: On Tue, 12 Jun 2012 00:06:38 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Jun 11, 2012 at 10:01 PM, Baruch Burstein bmburst...@gmail.com wrote: +** (versionable) text files which should have CR+NL line endings +** automatically fixed to CR LOL! As much as i agree with the sentiment, isn't saying fixed likely to alienate users of that other OS? So is there a setting for this variable that breaks text files when you check them out? Um..., no. If you fix a file, it will also fix your current checkout to match the fixed file in the repository, but any other open checked-outs will get fixed (or get conflicts) when doing an update. To bad. The only SCM I ever used where we *never* had line ending problems behaved that way. Only it wasn't optional, and they described it as line endings are converted to canonical form when you check in text files, and converted to the local representation when you check files out (this was before Apple had switched to Unix, Macs still used \r). This setting is most likely useful for new repositories or existing ones that already make sure to use only UNIX line endings. It will likely mess up repositories with existing Windows line endings. True either way. And unfortunately, not fixable. You might be able to correct the source code in a single commit to isolate the changes, but history is immutable. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil vs. Windows
On Tue, 12 Jun 2012 00:15:08 +0100 Jacek Cała jacek.c...@gmail.com wrote: Hi, Could you please be a bit more specific about what errors exactly you have experienced. I wish I could. It's my boss that's having problems, and I've already sent the full report to him. I'm now pursuing this on my own time. I've been using fossil on Windows (Vista 32-bit and 7 64-bit) for more than 3 years now and haven't ever experienced any problems with spaces in dirs or file names; How about the path to the repository? He can't get fossil open to work (or at least, that's the last report I had). Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Propose changes
On Tue, 12 Jun 2012 00:06:38 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Jun 11, 2012 at 10:01 PM, Baruch Burstein bmburst...@gmail.comwrote: +** (versionable) text files which should have CR+NL line endings +** automatically fixed to CR LOL! As much as i agree with the sentiment, isn't saying fixed likely to alienate users of that other OS? So is there a setting for this variable that breaks text files when you check them out? mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil vs. Windows
My boss just sent me mail that said, and I quote: Fossil sucks and is actually not compatible with Windows I'm pretty sure I've seen people here who use it no Windows, and there's a Windows distribution, which makes me think he's wrong. His problem is that he has lots of spaces in his directory and file names, and we (Windows is a third-line gaming platform for me, but I try...) couldn't figure out how to get such passed to fossil as file names, instead of broken up by command.com or whatever does that job these days. Quoting again: If I try adding parentheses or quotes then the ignorant application bombs out. So, anyone got advice on this? Maybe a GUI that works with the fossil Windows binary from fossil.org? Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Security of Fossil
Thomas Stover c...@thomasstover.com wrote: On Thu, 31 May 2012 13:44:52 +1000 Chen, Zon wrote: So ideally we want to be able to limit Fossil's Administrator account to only work from the local PC (or better yet, from LAN only.) ok that makes sense. I do know that you can unlock the admin account by just doing a fossil ui on it locally, which I have done when I have just forgotten the password. I'd like to see what the other answers turn out to be. My understanding is that the fossil serve mode is meant more for very lightweight or ad-hoc usage, and it's recommended that you put a server in front of (i.e. - an http server via cgi, or inetd, or some such) fossil for heavier work. Pretty much required if you want consistent access to multiple repositories. Maybe that's wrong for the windows version, or out of date, or I misunderstood something. But because of that, I expect it to punt hardcore security issues to that other server. I just today set up a half-dozen repositories for a client behind lighttpd, using the cgi mode with the recommended fossil script pointed at the directory the repositories reside in. We set remote_user_ok (I think that's it - fossil will log you in as the httpd user name if it has a user by that name). We let the httpd daemon handle auth, and only create users in the repositories we want them to have access to. The downside is we have to create an extra user. The upside is we get a single signon for all our repositories. We didn't create an httpd account for the admin user. This means you can't log in as the admin user at the browser auth point that users normally see. I think you can log in as a user with httpd access, then log into a repository as admin, but that may only work if the user doesn't have access to the repository, or if you log out of fossil first. If you wanted to allow admin access from the LAN as well as localhost, you'd set up the http auth so that admin had an account, but could only log in from the LAN Come to think of it, I did something very similar with svn served by apache. Apache's auth handled restricting access into the repository to members of apache groups. -- Sent from my Android tablet. Please excuse my swyping. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Allowing REMOTE_USER auth from the command line?
I found a number of people asking about this, but none of them seemed to have gotten an answer... Is there some way to set the use REMOTE_USER for authentication setting from the command line (or more accurately, a script)? I could just create a configured empty repository and copy that, but that seems like I'm asking for trouble. Thanks, mike ___ 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] HOWTO delete a Wiki page?
On Mon, 7 May 2012 14:16:59 +0200 Jiri Navratil j...@navratil.cz wrote: I made a typo in Wiki page. Can I rename Wiki page or delete a Wiki page? In one sense, no. Artifacts are forever (though you can shun them). However, if you delete all the text from a page, it'll vanish from the list of wiki pages. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] managing documentation in Fossil?
On Fri, 20 Apr 2012 09:50:02 -0400 Miles Fidelman mfidel...@meetinghouse.net wrote: Just started using Fossil for a new project - it just seems so much easier than git, and the integrated wiki and ticketing system just simplifies things a lot. Yup. A question to the group: To what extent are any of you using Fossil for managing documentation associated with projects - any or all of developer, user, administrator, sys admin (configuration files, configuration notes, shell scripts, cfengine/puppet/chef recipes, tickets, checklists, procedures, user account info, logbooks), etc.? I use the wiki for developer docs for clients that don't already have a preferred tool for those, or a preferred SCM other than fossil. Docs for the users/admins wind up stored in fossil, but normally aren't done in the wiki. There's a tension here in that I also use Google Docs for writing documentation. Things like architectural diagrams wind up there, and get links in the wiki. If the client has a google id, I'll give them write access to such, so there's a pull to keep everything there. I'm still working that division out. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] managing documentation in Fossil?
On Fri, 20 Apr 2012 10:26:26 -0700 Andreas Kupries andre...@activestate.com wrote: On 4/20/2012 7:34 AM, Mike Meyer wrote: ... Things like architectural diagrams wind up there, and ... I like to program my diagrams, instead of drawing them. Easier to change, and the code (aka text) is nicer to version than some binary blob. If I don't need to work on such collaboratively, I'll use graphviz for the same reasons. But google docs is easier to get other people to contribute to. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] managing documentation in Fossil?
[Drifting off topic here...] On Fri, 20 Apr 2012 14:25:59 -0400 Miles Fidelman mfidel...@meetinghouse.net wrote: Mike Meyer wrote: On Fri, 20 Apr 2012 10:26:26 -0700 Andreas Kupriesandre...@activestate.com wrote: On 4/20/2012 7:34 AM, Mike Meyer wrote: ... Things like architectural diagrams wind up there, and ... I like to program my diagrams, instead of drawing them. Easier to change, and the code (aka text) is nicer to version than some binary blob. If I don't need to work on such collaboratively, I'll use graphviz for the same reasons. But google docs is easier to get other people to contribute to. Don't know about google docs - no real version control. Unusable for anything serious, like a multi-author paper or proposal. I always end up sharing Word Documents, with change tracking, via email. Gets ugly with more than a few people. I'm still exploring how google docs fits into a small team. So far, I've just used it for one-page diagrams, and it's worked well there. Word, on the other hand - never again. The differences between implementations - different programs, different versions of the same program, the same version on different platforms - is just to painful. In one case, I saw word documents that would cause some *machines* to crash when opened. Other machines (presumably using the same version of word) would open them just fine. Saving the doc unaltered on those machines created a doc that didn't cause other machines to crash. Right now, the WikiPedia (or more accurately, MediaWiki) model seems to be really effective - what with support for multiple authors, change tracking, discussions, etc. Starts to fall down if you want to manage a structured document or generate printed versions as an output. It's certainly proved itself in the real world. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Behavior of rm, mv, and changes/extra
On Mon, 5 Mar 2012 18:12:15 -0500 Richard Hipp d...@sqlite.org wrote: On Mon, Mar 5, 2012 at 6:03 PM, Christopher Berardi cbera...@natoufa.comwrote: (n+2) Have a compile-time configuration option to choose what to build into fossil. For example, maybe I just want the 'core' vcs without the wiki, ui, or bug-tracking. Or, maybe I just want the vcs and the bug-tracking, but not the wiki or ui (though, in this scenario, tickets may need some way to be handled sans the web ui). By default, it would build everything like it does now, but a user could opt-out of certain elements. Note, this whole idea assumes that the different elements that make up fossil are not too tightly coupled ... but, if they _are_, we might wonder whether or not that is a good thing to begin with. Why is it important to you to have an executable that doesn't support the feature you don't use? Can't you simply not use the unwanted features even if they are included in the build? The if you don't use it costs nothing meme is wrong, and needs to die: http://blog.mired.org/2011/09/myth-of-costs-nothing.html That said, I don't think splitting up fossil's functionality is a good use of time - the default build is reasonably small and provides an excellent set of functionality. But if someone who feels otherwise provided a patch for it, I'd certainly be for accepting it, with the caveat that non-default builds aren't necessarily tested. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] documentation clarification
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. I was in a situation where this was happening regularly. I got warnings about the clocks being out of sync from fossil. I'm no longer in that situation (and traveling), so I can't easily test it, but isn't that still the case? mike ___ 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] fossil rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.com wrote: On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. Anything that takes so long you have to update between ready/completed states takes long enough you really ought not to be working without a net, uh, SCM. Either work on a branch and merge, or disable autosync, work locally and pull. Then merge back (or push) when it's ready and updated. mike ___ 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] Fossil completion for Zsh
On Fri, 27 Jan 2012 07:48:09 + Baptiste Daroussin baptiste.darous...@gmail.com wrote: Nice one usually the zsh project prefers to have it incorporate upstream so do not hesitate to send your contribution to the zsh-workers mailing list also and because you are working on zsh+fossil did you already have a look at vcs_info to add support for fossil in it? I wrote that a while back (it was announced on the list). You can find it here: http://chiselapp.com/user/mwm/repository/vcs_info/doc/tip/README.wiki I gave it back to zsh, but it doesn't seem to be in releases just yet. mike ___ 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] What you think about this functionality?
On Thu, 26 Jan 2012 20:54:19 +0100 Lluís Batlle i Rossell vi...@viric.name wrote: On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski http://nuclearsquid.com/writings/git-add/ Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. Very well explained! I totally agree. I imagine that in git, users are expected to commit wrong untested code (thus, that may not match the commit log), and some minutes later, edit all the history to make up. Also not testing the rewrites, of course. The git workflow. I commit untested code all the time, just to save the state of it. Of course, I *only* do this in my local repo, not to something anyone else might see. If I'm using a CSCM, I'll create a private branch for that purpose. Anything that gets pushed (or merged to the trunk) will be tested before the push, and if that results in a merge, tested before the merge results are committed. The Git philosophy seems to be that the repository is as important as anything else produced by the product, so editing history is crucial functionality. So they have tools to collapse/reorder/rewrite commits and hide all that. Personally, I think having accurate history is more important (one of the reasons I don't use git any more), and don't mind exposing it to those I share the code with. That said, between stashes and the ability to check a bug fix working copy out of the same repo (my usual mode for such), there's more than enough ways to deal with multitasking. mike ___ 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] Behavior of rm, mv, and changes/extra
On Thu, 22 Dec 2011 10:06:47 -0500 Tomek Kott tkott.s...@gmail.com wrote: -1 renaming rm to untrack or something similar that conveys correct message -- personally I think of fossil rm as acting on the repository. So I am, in fact, removing the file from the repository. Except you're not removing the file from the repository. The file - and it's entire history - is still there. You might be able to abuse shun to actually remove the file, but removing files from the repository is hard by design. What you're doing is causing future checkouts to the file system to not include a version of that file. You might argue that you're removing future versions from the repository, but future != now to me. mike ___ 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] fossil not tracking directories / dir artifacts after switching branches
On Thu, 22 Dec 2011 20:15:35 -0500 Richard Hipp d...@sqlite.org wrote: The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. I'm used to seeing it the other way 'round. You can't delete an empty directory on an nfs mounted file system because the nfs server has issues about doing so. And I'd say it's not an infrequent occurrence. mike ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 21 Dec 2011 20:21:18 +0100 Ramon Ribó ram...@compassis.com wrote: It is not the job of the SCM system to keep in step with my working directory Why not? In that case, fossil update shouldn't delete files that have been removed from repository, but it does. Any chance of getting rm/delete's named changed if it's behavior isn't? forget, ignore or untrack are all more descriptive of what it actually does. Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. A backup tool stores files for later retrieval. If your SCM doesn't do that, it's not much of a SCM. mike ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 21 Dec 2011 19:44:50 - Eric e...@deptj.eu wrote: On Wed, December 21, 2011 7:31 pm, Mike Meyer wrote: On Wed, 21 Dec 2011 20:21:18 +0100 Ramon Ribó ram...@compassis.com wrote: Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. A backup tool stores files for later retrieval. If your SCM doesn't do that, it's not much of a SCM. Missing the point entirely. Yes, you did. In your other message, you said And backup is for all your files. That's true - you need to backup all your files. But files have different sources, uses and values, so may well be backed up with different strategies. Which may well call for different backup tools. Any tool that can store files for later retrieval could be part of such a system, and hence is a backup tool. On my desktop system, I use mirroring, snapshots, install media, the SCM, a LAN backup, a cloud server and fs duplicates as part of my backup strategy. I use Perforce to backup /etc and /usr/local/etc for a number of reasons. One is that I can put the server on a different system, so get non-local backups without further effort. Another is that it stores *everything* on the server, so there's no SCM cruft in /etc or /usr/local/etc, and I can recreate them *from scratch* with a simple p4 sync -f. Using a DSCM would be more complicated. mike ___ 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 can I sync with a directory on each commit?
On Wed, Oct 26, 2011 at 12:28 PM, Kevin Ar18 kevina...@hotmail.com wrote: Perhaps I should explain more about it? At this stage, I am mostly using the VCS to backup and keep track of a single directory structure. (Of course I may use it for other purposes.) Point is, it would be really difficult to have to try and find every file that was added, deleted, or moved manually. I would constantly be worrying whether I really added all the files. Given that that's not what a SCM is designed for, it shouldn't surprise you that there's not a simple solution to your problem. On the other hand, you can script fossil to do this. You'll need two commands: addremove (to find all new files and any removed ones) and then a commit to create a new version in the repository with those (plus any changed files in it). You'll probably have to fool with the ignore facility to get this to work properly. If you don't need to keep old versions around, this is almost certainly overkill, as there should be tools for your platform to keep two directories in sync. If you do need to keep old versions around, it may still be overkill. Personally, I use create a file system for each such directory, and then take file system snapshots after doing the directory sync. This does require a file system which makes creating both new file systems and snapshots cheap. mike ___ 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] Veracity
On Thu, Oct 20, 2011 at 3:46 AM, Martin Gagnon eme...@gmail.com wrote: On 2011-10-20, at 01:13, Jeff Slutter j...@slutter.com wrote: A couple weeks ago I posted about the possibility of a new configuration setting called something like allow-binmerge (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict? I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved. But for that, you would need a different gmerge-command per file type. (that have a merge tool) Others have pointed out that a smart merge tool can deal with multiple formats. But providing a way to deal with multiple different merge commands isn't that far beyond the things fossil already does. Consider a setting merge-command whose value is a list like the ignore-glob setting, except the values are regular-expression=command. Making an empty command mean use the internal merge would allow you to route all merges through it. mike ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: I'm a novice Fossil user working in a small group with need to track both text and binary files. It seems to me that locks are nice to have for text files since 3 way diffs can be merged at relatively little cost. But inability to merge binary files might mean painful hand merging based on side by side comparisons for word processing documents or presentation slides, or based on repeating the edits for image files. So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. The problem is that locking in a distributed environment is hard to do reliably. Mostly reliable could well be worse than no locking at all: you start to depend on it, and it will then naturally fail at the worst possible moment. How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. mike ___ 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] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell virik...@gmail.com On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. It looks very nice, but that should be able to be set on past checkins too, the same way you edit checkins to change tags. Otherwise, when created sounds very limiting. Two issues. One is that it really belongs on files, not checkins. The other is that you have to figure out what to do about files derived from that one when you set the flag retroactively. We don't have anything like file tags, other than the executable bit. And changing this detail may involve a change in the manifests some new artifact types. I think that something that worked as propagated-tags, but could set files readonly, would be great. That would help accross branches, and also allow avoid locking files in subgraphs. Would fossil stand some dozens of propagated tags with long names? of the kind readonly:PATH. To bad easy to describe doesn't imply easy to implement. Having a real file properties solution would make this easy. Hmm - maybe the readonly-glob setting is enough? If it's not set, you get the current behavior. Otherwise, you check it when you pull files out of the repository (to set them read-only) or commit (unless -force is on). That also fixes the question of retroactively setting the flag. But it might be to expensive. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Locks (Was: Veracity)
This requires a lot of work on fossils part in order to be reliable. Unlike source changes, you can't do a commit and then require a merge before pushing if there's a collision. There are also nasty restrictions on how you do things. In particular, you have to have autosync on (or ignore it if off) and be connected to all repositories you push/pull from to use it. Given those restrictions, if you're looking to change things to support fossil, wouldn't you be better off using a tool designed for managing binaries ( an artifact repository) instead of one designed for managing textual sources? mike ___ 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote: This requires a lot of work on fossils part in order to be reliable. If I had to implement that on fossil, I'd use some kind of table like the shun table, propagated on autosync, that would ban a commit modifying a file. 'commit' could have a '--force', that would bypass the locks. I think they should be informative, and not restrictive. But it's not only locks alone that help, because that would depend on how often you sync, and you would notice new locks only when syncing, and that would be already late, because you may have already modified the file in your working directory, requiring a complex merge. That's what I meant by a lot of work on fossils part to be reliable. Whether the lock command fails to create a lock or warns you if someone else has a lock is immaterial, they both take the same amount of work to figure out if someone else has a lock. If it isn't reliable, then it doesn't really solve the problem. And being reliable is a lot of work. No, I take that back. You could force locking to use a central server model. For each repository, you have to set a repository as the lock server. Using self or some such would mean You are the lock sever. The lock command could then either handle the lock locally, or request it from a remote server. Otherwise, you need a distributed lock manager, which is a hard enough problem to warrant it's own project. Svn introduces the property of files of needs_lock. Those files, once checked out, are checked out in read-only into disk, and get the writeable state only if properly got a lock. Of course read-only-ness can be bypassed by the user owning the file, and that also has only an informative role. Maybe something like propagated tags could mark files as needs_lock, and act accordingly on updates/checkouts/... SVN has a central server, thus avoiding the hard problem. Once you've got that, needs_lock is a good idea for a SCM that uses a change/commit workflow instead of the checkout/change/commit workflow. mike ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Wed, 19 Oct 2011 16:24:17 -0700 Matt Welland estifo...@gmail.com wrote: I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync Suggestion: If autosync is not enabled, treat this as an error. Override with -force. What happens if you find out that someone else has locked the file during the sync? Do you then revert all the changes you made and fail? On check out 1. Files locked by others have write perms removed So the lock is on the file, at all revisions? Are the same file on different branches considered different files in this case? On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure If locks aren't specific to a revision, shouldn't this happen on a pull (or the pull part of a sync) and not an update? On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. So long as you've got either one central server, or a collection of very tightly synchronized servers, it should help a lot. Here, tightly synchronized means synchronized much more frequently than pushes come in from developers. Personally, I still think this is a lot of work to go through to adopt one tool for a job that other tools are designed to do. Sort of like building a claw hammer fitting for a screwdriver. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] ui side-by-side diffs
On Mon, Oct 10, 2011 at 8:20 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Oct 10, 2011 at 4:04 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: All those flashy JS bells and whistles consistently make me think they're really there for the sake of being there. But what better reason could there possibly be ;). Providing the reader a better experience. Yes, I know you weren't really serious. But enough web authors seem to take that attitude seriously that it's a sore point for me. Such things are generally there to hide the fact that the content isn't worth reading. In this case, there's useful information there, so why not actually present it? Personally, I find the colorize the code on the client hacks incredibly wasteful. You could colorize it once when you generate it, but instead you colorize it every time someone wants to read it? Talk about a silly waste of CPU. Or has CPU really gotten so cheap that this is now acceptable, and I'm doing nothing more than showing my age by worrying about it? Now, there *is* something useful that could be done here. Let the reader control the colorization. Of course, that can be done with dynamic CSS, and you could provide it and still only colorize things once. But I haven't seen a colorizing tool that does even that much. In this case, you're generating the diff at read time, so there's no savings in avoiding doing things in JS. But if you're going to do that, at least take the opportunity and let the reader control what they see. mike ___ 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] ui side-by-side diffs
On Mon, Oct 10, 2011 at 9:16 AM, Stephan Beal sgb...@googlemail.com wrote: Personally, I find the colorize the code on the client hacks incredibly wasteful. You could colorize it once when you generate it, but instead you colorize it every time someone wants to read it? Talk about a silly waste of CPU. Or has CPU really gotten so cheap that this is now acceptable, and I'm doing nothing more than showing my age by worrying about it? One could just as easily argue that doing it server-side is wasting server CPU cycles and why not make the client work a bit for his presentation? i'm not arguing either way (they're both valid), just playing Devil's advocate. The JSON API, as a whole, is intended for use in clients where a server-side colorization process is most likely just troublesome noise (i.e. non-HTML clients). I guess I didn't make the point clear. I agree with you - if the choice is to do it on either the server or client, putting it on the client helps distribute the load. In the case of colorizing code, I was referring to a third option: generating static html on the authors desktop. That way, you can do it just the one time, instead of every time the thing is read. But it's not a sexy solution. This option isn't available for the case under discussion - the diff listings are generated at read time in the first place. Doing formatting work on the client makes a lot of sense, but I'd be happier if the code allowed the user to control as much as possible, rather than wiring it to what the author prefers. Unless, of course, you're feeding an iPhone, when you have to wire it to what Apple prefers :-). mike ___ 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 vs fossil again (was: why you should not shun)
On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Bottom line: while more features may imply more powerful, it doesn't imply better. mike ___ 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 vs fossil again (was: why you should not shun)
On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek hramr...@centrum.czwrote: On 5 October 2011 20:12, Mike Meyer m...@mired.org wrote: On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. No, that's not how things work. Rebase is nothing more than taking commits comprising a branch from its branching point and applying them somewhere else. Not that complicated, really. No, that's not how things work. Either that, or the git rebase documentation is really badly broken. It sure looks to me like rebase moves the patches from one point to another in the repo. As applying patches is doable, even patches stored in fossil history already, this is doable with a bit of scripting around fossil as it is doable with git. So not having the feature is not perfect defence, it only defends against people who don't care about the feature. People who find it useful for their workflow and want to use fossil for compatibility with upstream of for other features it provides can do so. If rebase moves the patches, then the two operations are different. This is basically a merge - except you're doing it outside the SCM, so you get two copies of the patches. But whether you do it inside or outside the SCM, you wind up with a history of the patches having been applied twice. Rebase changes that. mike ___ 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] Wiki formatting with empty lines
Jos Groot Lipman donts...@home.nl wrote: I also found out about this http://www.fossil-scm.org/index.html/wiki_rules The verbatim tag works like pre with the addition that it also disables all wiki and HTML markup through the matching /verbatim. But why this special tag? Is this not something the pre should do under all circumstances? When would you ever want wiki or HTML markup inside a pre? That contradicts the primary reason of existance for the pre tag. No, it doesn't. The pre tag preseves layout, but not other formatting. It's valid and common to change fonts inside of a pre tag. And I'm anal enough about my html to run an editor that does on-the-fly validation. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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] Wiki formatting with empty lines
On Thu, Aug 18, 2011 at 1:44 PM, Jos Groot Lipman donts...@home.nl wrote: The verbatim tag works like pre with the addition that it also disables all wiki and HTML markup through the matching /verbatim. But why this special tag? Is this not something the pre should do under all circumstances? When would you ever want wiki or HTML markup inside a pre? That contradicts the primary reason of existance for the pre tag. No, it doesn't. The pre tag preseves layout, but not other formatting. It's valid and common to change fonts inside of a pre tag. And I'm anal enough about my html to run an editor that does on-the-fly validation. Which causes me to ask - does any have a schema for fossil wiki/html combination? Thanks, I did not realize that. I believe I got pre mixed up with xmp (deprecated in HTML 4.0 and rightfully not supported by Fossil Wiki) So verbatim is more like the combination nowikixmp. I will start using verbatim I think of it more as pre!CDATA[ section, but that's the idea. mike ___ 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 features for merging
On Mon, Aug 15, 2011 at 10:49 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Sun, 14 Aug 2011 19:16:50 -0700 Mike Meyer m...@mired.org wrote: [...] If you insist on them being files, then there's not much point in further discussion. And having them in files means you can bring the full power of unix to bear on them (which, of course, is why I want them *out* of my workspace - as they are just noise when working with *my* files), which is hard to argue with. But - any chance of moving them into the wiki? The fossil wiki command would let you work with them with almost the same power at the command line (i.e. - fossil extras | fossil wiki import settings/ignore_glob should work), and in return you get to edit the settings via the wiki gui. This is a rather beautiful idea but I always thought that wiki in fossil is not really versioned and it is also repository-wide (hence you woun't be able to have different ignore settings on different branches). Please correct me if I'm wrong. But if I'm not, the idea of using wiki for this kind of job won't work. Half right. Wiki pages are versioned, and you can use the UI to go looking through the older versions, etc. The version of fossil I have here (downloaded windows binary) doesn't have the ability to deal with wiki pages by version from the command line, thought it's listed as a TODO. Their doesn't appear to be any way to branch them, though. So yes, like the current version settings, you couldn't have different settings for different 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] New features for merging
On Sat, 13 Aug 2011 09:48:09 +0100 Ben Summers b...@fluffy.co.uk wrote: On 12 Aug 2011, at 22:39, Mike Meyer wrote: On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers b...@fluffy.co.uk wrote: On 12 Aug 2011, at 20:44, Mike Meyer wrote: On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 07:10 PM, Joshua Paine wrote: On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. Aye. My fossil extras .fossil-settings/ignore_glob brought a smile to my lips. I'm at worst neutral on all the other changes. This one bothers me. I consider fossil only having one file in the work space (__FOSSIL__) to be an advantages, because it makes working with the tree using standard unix commands that much easier. With most SCM software, I wind up doing some tree-level command, seeing the SCM files in the output, cursing, and then either running a SCM-provided command or a tweaked version of the unix command that deals with the SCM files. You can ignore this new feature, and everything will continue to work as it did before. The slightly clumsy name of versionable is to imply that they *can* be versioned, not that they inherently *are*. So these won't get copied around by push, pull, clone or sync? If they do, is there at least an easy way to turn them back into regular settings so I can delete them (and thus start the commit wars)? Settings aren't synced, which is the problem. When the values of the settings are stored in normal versioned files, they are, just as any other file. What I meant was that if you don't want to use this feature, you can still use settings in exactly the way you do in the current version. Yes, but my point is that my using setting exactly the way I do now isn't sufficient to keep my workspace from getting cluttered by these SCM files if someone turns them on in another clone of the repository. Whether or not they're actually used is immaterial. Let me be crystal clear - I have absolutely no objection to the features this change adds, and might well use them. My problem is with the extra clutter in my workspace. Maybe I was spoiled by 7 years of nothing but perforce (with *no* SCM files in the workspace) before being exposed to svn in '05, but fossil having so little clutter is one of it's attractions for me. I can understand wanting versioned settings, but does it need to go into the file system? Fossil versions other objects that aren't in the file system (wiki, tickets, etc). Is there some reason the same can't be done for versions? It would need to be part of checkin somehow, as wiki pages, tickets, etc, aren't in a branch. This would be adding another mechanism, when the whole point of this new feature is to give the option to move away from using an additional mechanism for these settings. I thought the whole point was to provide versioned settings? If all you want is not to have an additional mechanism, then just don't merge this feature into the trunk :-). OK, I wanted a mechanism which works. And it doesn't add a new concept into fossil, it just uses files, which everyone understands. If you insist on them being files, then there's not much point in further discussion. And having them in files means you can bring the full power of unix to bear on them (which, of course, is why I want them *out* of my workspace - as they are just noise when working with *my* files), which is hard to argue with. But - any chance of moving them into the wiki? The fossil wiki command would let you work with them with almost the same power at the command line (i.e. - fossil extras | fossil wiki import settings/ignore_glob should work), and in return you get to edit the settings via the wiki gui. Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] New features for merging
On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 07:10 PM, Joshua Paine wrote: On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. Aye. My fossil extras .fossil-settings/ignore_glob brought a smile to my lips. I'm at worst neutral on all the other changes. This one bothers me. I consider fossil only having one file in the work space (__FOSSIL__) to be an advantages, because it makes working with the tree using standard unix commands that much easier. With most SCM software, I wind up doing some tree-level command, seeing the SCM files in the output, cursing, and then either running a SCM-provided command or a tweaked version of the unix command that deals with the SCM files. I can understand wanting versioned settings, but does it need to go into the file system? Fossil versions other objects that aren't in the file system (wiki, tickets, etc). Is there some reason the same can't be done for versions? If it has to be in the file system, I'd prefer one file to many. At the very least, change the name of the directory to something that starts with __FOSSIL__ to make it easier to tweak commands to deal with the names. mike ___ 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 features for merging
On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers b...@fluffy.co.uk wrote: On 12 Aug 2011, at 20:44, Mike Meyer wrote: On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 07:10 PM, Joshua Paine wrote: On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. Aye. My fossil extras .fossil-settings/ignore_glob brought a smile to my lips. I'm at worst neutral on all the other changes. This one bothers me. I consider fossil only having one file in the work space (__FOSSIL__) to be an advantages, because it makes working with the tree using standard unix commands that much easier. With most SCM software, I wind up doing some tree-level command, seeing the SCM files in the output, cursing, and then either running a SCM-provided command or a tweaked version of the unix command that deals with the SCM files. You can ignore this new feature, and everything will continue to work as it did before. The slightly clumsy name of versionable is to imply that they *can* be versioned, not that they inherently *are*. So these won't get copied around by push, pull, clone or sync? If they do, is there at least an easy way to turn them back into regular settings so I can delete them (and thus start the commit wars)? I can understand wanting versioned settings, but does it need to go into the file system? Fossil versions other objects that aren't in the file system (wiki, tickets, etc). Is there some reason the same can't be done for versions? It would need to be part of checkin somehow, as wiki pages, tickets, etc, aren't in a branch. This would be adding another mechanism, when the whole point of this new feature is to give the option to move away from using an additional mechanism for these settings. I thought the whole point was to provide versioned settings? If all you want is not to have an additional mechanism, then just don't merge this feature into the trunk :-). If it has to be in the file system, I'd prefer one file to many. At the very least, change the name of the directory to something that starts with __FOSSIL__ to make it easier to tweak commands to deal with the names. More tools hide names beginning with a dot than they do _FOSSIL_. Having to keep track of which tools need to deal with both and which only need to deal with one makes things worse, not better. If we didn't already have __FOSSIL__, it'd be a win, as it would mean some tools would work right even if you forgot to deal with the SCM turds in the work space. But we already have __FOSSIL__, so (in the words of Arlo Guthrie) one big pile is better than two little piles. mike ___ 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 features for merging
On Fri, Aug 12, 2011 at 2:44 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 12, 2011 at 11:39 PM, Mike Meyer m...@mired.org wrote: space. But we already have __FOSSIL__, so (in the words of Arlo Guthrie) one big pile is better than two little piles. For the benefit of those born after Star Wars: http://www.arlo.net/resources/lyrics/alices.shtml Which will make http://www.ai.sri.com/~delacaze/alu-site/alu/humor/alices-lispm.html a lot funnier. mike ___ 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] _FOSSIL_ vs. .fos Was: New features for merging
On Fri, Aug 12, 2011 at 3:42 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 12, 2011 at 5:24 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Aug 12, 2011, at 22:28 , Ben Summers wrote: If it has to be in the file system, I'd prefer one file to many. At the very least, change the name of the directory to something that starts with __FOSSIL__ to make it easier to tweak commands to deal with the names. More tools hide names beginning with a dot than they do _FOSSIL_. Most notably shell's glob ignores dotfiles, what makes them mostly a non-issue for me... And I find the _FOSSIL_ string particularly disturbing on listings. You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? Yes! If I had thought that was a possibility, I would have asked for it instead. mike ___ 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] Creating repositories remotely
On Thu, Aug 11, 2011 at 2:03 PM, Stephan Beal sgb...@googlemail.com wrote: There is no built-in way to create a remote repository (a fossil server represents the _one_ repository which must already exist before the server can start). You have to create the .fsl file, run fossil ui once to set the admin password, upload it to the server, and either run it (if you're running it as a server) or set up a CGI script wrapper to run it (for CGI use). How much damage would setting up one .fsl file, and then copying it multiple times - once for each new repository - cause? If that worked, you could wrap a script around scp (or pscp on Windows) to make a create remote repository command. mike ___ 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] Fossil destroys repositories?
On Mon, 25 Jul 2011 23:20:31 -0700 Russ Paielli russ.paie...@gmail.com wrote: I posted a recommendation for Fossil earlier today on a Scala forum (see my earlier post today on this forum). I got this reply: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? Already discussed at length on the list (http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html). IIRC, there was a subtle bug that caused a fossil update to update to an empty branch - which then removed most of his files (bug fixed during this discussion). At this point, none of his work was lost. However, he then panicked (not unreasonable) and in trying to get things fixed managed to do things that did lose work. I don't think enough information was ever posted to decide if fossil actually lost work, or if he just managed to destroy it while trying to recover from the checkout of nothing. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Converting from mercurial
On Mon, 18 Jul 2011 21:18:29 -0700 Jeremy Anderson jere...@gmail.com wrote: Out of curiosity, why are you converting from mercurial? While you weren't asking me, I converted from mercurial (and did the hg - git - fossil path) to fossil, so feel an answer from me isn't unreasonable. I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) I'm an independent consultant, and often work for small companies that don't have a corporate SCM or issue tracking system, etc. I originally looked at fossil because I couldn't get a working build of mercurial on an antiquated solaris system (couldn't seem to get a Python build to use any of the ssl libraries, which broke hg even if you aren't using ssl). Getting a working fossil build on that system was easy - just turn off SSL in the Makefile. Once I had it up and working, investigating the wiki and issue tracking system was free, and turned out to be a real win. All for less work than setting up hg (or git) in the first place. Being able to have multiple checkouts of the same repository is also a win - I keep multiple branches checked out, and can merge differences without a push/pull, and can then push all of it to my clients machine. I still use hg for projects I release as open source, mostly because the major hosting sites (I prefer google code) don't support it. To make up for that, I plan to make adding fossil support to cabal as one of my next projects. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil not removing files when switching branches
On Wed, 13 Jul 2011 19:30:08 -0400 Joshua Paine jos...@letterblock.com wrote: On 7/13/2011 7:13 PM, Brian Cottingham wrote: was wondering if some of the Fossil internals could be refactored to not need an explicit 'open' command. I.E., Git and SVN don't need an open command- you just cd into a repo's directory and stuff works. Could Fossil be reworked to act similarly? Ok, now I see. In git the repo is a hidden directory containing many files stored in the same directory as the 'working copy' (to use a SVN term). The fossil repo, however, is a single SQLite database file with a special schema. So there is no repo directory to CD into until you open a repo in a directory. Once you've done that (one-time operation), all the commands do work in that dir without further fanfare. I don't see this changing anytime soon, as drh (I believe) regards this as a feature. I agree, fwiw. So do I. This means fossil can do something that you can't do with git or hg (and probably other DSCMs) that CSCMs do: have multiple working copies open from the same repo. I use this to keep different working copies open to different branches, so I can move code between branches just by merging. If I were using a hg or git, I'd have to push/pull the changes between the repos in each working copy before I could merge them. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Needed: volunteer to autoconf Fossil
On Tue, 14 Jun 2011 22:55:18 -0700 Matt Welland estifo...@gmail.com wrote: I thought that from an end user perspective all that is needed with autoconf is sh. Not quite true. The problem is that, while every system has a /bin/sh, different systems use different shells for that: most (but not all) GNU/Linux systems use bash, the various BSD's use either things derived from the original v7 sh, OSX switched from a BSD sh to bash at some point, on SysV-based systems you can find Bourne shell, ksh or pdksh variants, just to name the obvious ones. You can't even write for a hypothetical posix shell because /bin/sh isn't posix compliant on many systems. Which explains the (possibly apocryphal) Bourne quote: It's easier to write a shell than a portable shell script. The result is that the autotools config script searches (or searched - I haven't looked into it in a year or so) the system and $PATH for the best shell to use. This means whether or not the script actually works properly depends on which shell it finds (if the best shell has a bug that some test trips over), which means it can depend on $PATH and which shells are installed on the system. In practice, it works fairly well because most systems have bash installed (if only because GNU/Linux developers tend to write bash-specific shell scripts, so a lot of software has a run-time dependency on it) where the config script will find it, and the autotools tests generally work around the bugs in it. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Needed: volunteer to autoconf Fossil
On Mon, 13 Jun 2011 19:27:49 -0400 Richard Hipp d...@sqlite.org wrote: On Mon, Jun 13, 2011 at 7:07 PM, Steve Havelka smh...@gmail.com wrote: Is it necessary that it's autoconf? Or would you take a CMake-based build script? ccmake is not installed by default on either my iMac nor my SuSE Linux desktop. So it a a non-starter. If you have a way other than autoconf to generate a universal build script that runs on any unix machine without special software installed, then that will be fine. CMake does not qualify because it is not installed by default on most unix boxes. I think autoconf is probably going to be the only general-purpose solution, but I am open to alternatives if you have them. I feel compelled to point out that installed by default on most unix boxes isn't a realistic requirement. I'd say it eliminates autoconf because it isn't installed by default on any of *my* Unix boxes (all running OpenSolaris or FreeBSD). For that matter, a C compiler isn't installed by default on OpenSolaris or most of the GNU/Linux distros I'm familiar with, so by that definition you can't build fossil without special software installed on those systems. For most unix and unix-like systems, a more appropriate requirement would be is available from the package system. I.e. - it's something that can be trivially installed, without having to configure or build or chase dependencies for it. Since Windows and OSX don't come with package systems, that won't work for them, but having a binary build available from the authors should meet the goal of being trivial to install. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Needed: volunteer to autoconf Fossil
On Tue, 14 Jun 2011 17:37:06 -0400 David Slocombe sloco...@vex.net wrote: But autotools should come first as it both supports the above and goes at least a long way to helping all the other folks who aren't plugged into some Linux distribution's binary package system. Is autotools the only such tool the fedora committers support? Seems like a lot of things don't require them, and many of those that do require patching by hand to build anyway. Of the 23,054 package Makefiles in the FreeBSD ports tree, only 1732 use any of the autotools (most of those seem to be libtool), and of those, 1165 need further patching(*). mike Those are *very* rough numbers, based on checking for the USE_AUTOTOOLS variable in the Makefiles and whether or not the port has a files directory (which holds patches). Lots of things could throw those numbers off, but unless something really weird is going on, they should be the right order of magnitude. -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil merge question?
I recently ran into a merge scenario that most DSCMs seem to fail, but fossil gets right. See the attached fstest.sh for an example. The question is - is fossil just lucky, or is it looking at the intermediate revisions in the merge instead of doing a pure 3-way merge? Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org fstest.sh Description: application/shellscript ___ 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] CRLF conversion on windows
Getting pedantic here... On Thu, 7 Apr 2011 12:55:14 -0400 Richard Hipp d...@sqlite.org wrote: On Thu, Apr 7, 2011 at 12:42 PM, Ramon Ribó ram...@compassis.com wrote: MacOSX is using UNIX line ending since more than 10 years-ago. In modern computers, there are two options: Unix/MacOSX: LF Also, Solaris, AIX, HPUX, NetBSD, OpenBSD, QNX, etc. Solaris, AIX and HPUX are UNIX(tm) systems, and are (or were, I haven't kept careful track) derived from ATT Unix distributions. NetBSD, OpenBSD and FreeBSD can all trace their genealogy back to ATT source code, but aren't UNIX(tm) systems, just Unix-like. For that matter, Mac OSX is a UNIX(tm) system, but shares the BSD genealogy instead of being derived from an ATT distribution. Also: Minix, Ubuntu, Redhat, Gentoo, Fedora, Debian, etc, which are Unix-like but have source code that never included ATT code. Windows: CR-LF There are countless operating systems available today, each with is own peccadillos. So why is it always windows that gives trouble? The more one tries to make code cross-platform, the more one realizes that windows is the problem child. Basically, Unix won. I think Windows is the last system maintaining backwards compatibility to systems that predate the rise of Unix. Pretty much everything else either was designed with the Unix model in mind, or converted to it somewhere along the way. At this point, I wouldn't be surprised if there were more Unix-like systems than Windows systems in the world, given that two of the three most popular smart phone/tablet OS's (IOS and Android) are Unix-like, and the popularity of Unix-like OS's on embedded devices. Most of them could probably be convinced to run a static build of fossil, but not a dynamic one, as there's a fair chance they've been stripped of one or more libraries that fossil needs. mike *) UNIX(tm) is a trademark of The Open Group, and can legally only be used to describe systems which The Open Group has certified as meeting the Single UNIX Specification. -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] File dates
On Mon, 28 Mar 2011 14:17:10 -0400 Volodya Savastiouk volo...@io3.ca wrote: I've raised this issue before with little success, although a few people responde The issue is the file dates being always today's date whenever one downloads a copy from the repository or simply opens a local copy. I'd really like to either see the file dates being the date of the last update or at least have an option of saving the update date in the filename so I can use that info and force the file date myself. I figure that all of the necessary information is already in the database and the only step that's missing is a call to the file system for the file's date/time update after it is re-created from the database. Does anybody else feel this is a useful feature/option? As noted, this breaks build systems that compare file dates to see if a file needs to be recompiled. As such, this feature is dangerous. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] git equivalent commands
On Fri, 11 Mar 2011 18:53:55 +1000 Steve Dalton st...@refactor.com.au wrote: Maybe we should start a comparison table on the wiki svn/git/mercurial/fossil equivalent commands http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_Commands Though it doesn't cover the command in question, and the section on advanced commands doesn't include fossil. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] git equivalent commands
On Fri, 11 Mar 2011 19:40:03 +1000 Steve Dalton st...@refactor.com.au wrote: Should things like lock and rebase be no as apposed to Unknown? I understand rebase is something that can't be done in Fossil due to fossilizing the history right? I'm also certain fossil doesn't support locking, right? :) Lock is pretty much impossible in a DVCS. If you check the advanced commands table, it's no for pretty much all of them (including fossil), even though it's unknown for all of them in the basic commands table. I guess since fossil allows multiple checkouts from one repo, it could lock files *in that repo*. As you say, rebase cuts against what I understand to be fossils philosophy. And the rollback question is sorta odd. You can delete things from fossil, by shunning them then rebuilding (?) the repo. However, there's still a record of it in the shun list, and possibly elsewhere. I'd say that no here is at least as correct as mercurials yes when mercurial only allows you to remove the *last* change to the repo. While questioning things - I notice that interactive commit is listed as yes in the advanced features table. The comment says that means you can cherry-pick changes, meaning you can commit some changes to a file without committing all of them. If that's right, I couldn't find it. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] IMHO Fossil needs renaming...
On Fri, 4 Mar 2011 12:59:12 + Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Some logo ideas: t-rex 'Exciting!' http://t1.gstatic.com/images?q=tbn:ANd9GcQeEF1HR0h6BpVnOpRq3wMhFl9DOkh2j7nA7VzALlWdDqstpI68EA Um, no. Exciting is the *last* thing I want from a VCS! In looking at the other DVCS sites (and other OSS software) and comparing them to fossil, three things stick out: 1) Most of them have very visible download buttons/sections. Most also have a short quick start section on the home page. 2) Colors. The two sections often have different background colors or bright borders to make them stand out. 3) Bullet lists. For some reason, people like using graphic bullets for lists, with different bullets for each item. At least for major lists. They also keep the lists short - normally no longer than seven items, and then only if they are single-line items. With those three things in mind, I'd suggest reorganizing the home page along these lines: The main content - the long numbered list - gets shortened. Either drop three or four items, or drop the explanations and make them link to a page that provides the detailed explanation. Switch from a numbered list to custom graphics bullets. Replace the box on the right with a download section: A big colorful download link to the downloads page, followed direct text links for Mac, Windows and whichever is most popular of the two Linux links. Below that is a short quick start box, showing a cut form a terminal window of doing doing clone, open, edit, commit. The first four lines (or maybe 8 to show a branch) of the screen capture near the top of http://blog.mired.org/2011/02/adding-vcs-to-zshs-vcsinfo.html is about right. Except leave out the RPROMPT. The bottom half of the page gets split into four parts. The right most part gets the contents of the box that was in the upper left plus the free hosting link. Oh, and add a Quick Links header. The second column gets a User Docs header, and then the links for Concepts, Building And Installing, Embedded Documentation, Branching, Built-in Wiki, Event, Content Deletion, Password Management, Command Line Reference, TH1 Script Language, Server Setup, Ticket System Customization, and Import and Export. Yes, this is about twice as long as I'd like, but fixing it requires reorganizing the user docs. A quick stab at that: Create an advanced topics page, put Content Deletion, Command Line Reference (since it's unfinished), TH1 Script Language, Ticket System Customization, Embedded Documentation, and Server Setup there, and just have the Advanced Topics link in User Docs. The third column gets an Advocacy header, and links for Testimonials, Quotes, Questions Criticisms, fossil-vs git, and Performance stats. The last column is Developer Docs, and is the links for fossil developers. Ok, I know I'm not very good at the UI/graphics design game, so I'm not going to try. But after looking at the other sites suggested, those changes sort of popped into my head. Since no one else mentioned anything along those lines, I figured I would. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] IMHO Fossil needs renaming...
On Wed, 2 Mar 2011 17:54:15 +0200 John Found johnfo...@evrocom.net wrote: Also look at other similar systems - Bazaar - makes allusion with crowds of developers. Mercurial - something very agive, quick, versatile. Mercurial also means erratic, fickle, liable to sudden unpredictable changes. You really want to trust your source code to that? And you wisely didn't mention git. My only problem with the name is that it's to common a word - searching for info on fossil keeps turning up paleontological sites. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil for Android?
On Sat, 26 Feb 2011 20:53:11 -0800 (PST) Timothy Brown javelin...@yahoo.com wrote: For your consideration, How hard would it be to build Fossil for Android? For that matter how hard would it be to get Fossil built for iOS? Since both are Unix variants, it shouldn't be to bad. The makemake script already has two compilers wired in - one for building the build tools, and one for building the cross-compiled binary. That doesn't set TCC in the Makefile, but that's an easy fix. For android, it took about three hours to get it to compile starting from scratch (literally - I had to locate and download the appropriate development kits). The hard part was figuring out the correct thing to set LDFLAGS in the Makefile to for the cross-compilation environment to get a complete link. Doesn't appear to be working very well - but I'm not an android developer, so that's not really surprising. iOS is probably easier - if you're happy using the jailbroken dev tools. Using Apple's tools may be a bit harder. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil for Android?
On Mon, 28 Feb 2011 07:21:58 +1000
Steve Dalton st...@refactor.com.au wrote:
Hi Mike
Would like care to share what you did to get it working (ie. LDFLAGS
etc) - I wouldn't mind having a try myself just to see what the
process is.
Thanks
Steve
Sure.
Note that setting TCC in makemake.tcl doesn't work for builds on
Linux. I believe this is a bug in makemake.tcl, as the value of TCC
gets copied into win/Makefile.mingw properly.
You need to install Googles ndk (that's the Native Developers Kit) for
your platform if you don't have it already. Assuming that's extracted
into $NDK (i.e. $NDK ends in something like android-ndk-r5b), do the
following:
In Makefile in the top level, set:
TCC = arm-eabi-gcc -I$NDK/platforms/android-5/arch-arm/usr/include
LDFLAGS=-Wl,-rpath-link=$NDK/platforms/android-5/arch-arm/usr/lib,-dynamic-linker=/system/bin/linker
-L$NDK/platforms/android-5/arch-arm/usr/lib
-L$NDK/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/lib/gcc/arm-eabi/4.4.0
$NDK/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o -nostdlib -lc
You'll also want to comment out the setting of -DFOSSIL_ENABLE_SSL
and the addition of -lcrypto -lssl to the link line (the ssl libraries
aren't in the ndk).
Two source file tweaks to cover for functionality that isn't included
in the NDK:
Index: src/config.h
===
--- src/config.h
+++ src/config.h
@@ -126,11 +126,11 @@
#endif
/* Unset the following to disable internationalization code. */
#ifndef FOSSIL_I18N
-# define FOSSIL_I18N 1
+// # define FOSSIL_I18N 1
#endif
#if FOSSIL_I18N
# include locale.h
# include langinfo.h
Index: src/user.c
===
--- src/user.c
+++ src/user.c
@@ -86,12 +86,12 @@
/*
** Do a single prompt for a passphrase. Store the results in the blob.
*/
static void prompt_for_passphrase(const char *zPrompt, Blob *pPassphrase){
- char *z = getpass(zPrompt);
- strip_string(pPassphrase, z);
+ //char *z = getpass(zPrompt);
+ //strip_string(pPassphrase, z);
}
/*
** Prompt the user for a password. Store the result in the pPassphrase
** blob.
Given that the NDK is meant to let you write native-mode methods for
Java, but not interact with the user, these being missing make
sense. Obviously, don't do things that might make it prompt for a
password with this fix.
The resulting binary will correctly spit out help text and version
info, but quietly exits or just hang if asked to do any real
work. That might be because I used android-5 instead of whichever
platform was correct for my tablet, but I spent more time getting this
far than I should have (noticed the TCC setting, and just had to see
if it would work out of the box).
mike
--
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Restricting trunk checkins
On Tue, 22 Feb 2011 07:09:14 +0200 Ron Aaron r...@ronware.org wrote: One feature missing from Fossil is a way to restrict checkins on the 'trunk' (or other branch) to certain people. This is necessary in a group where the methodology is for a gatekeeper to approve integration into the main line of development. Has there been any thought along those lines? In my perfect scenario, a branch (including trunk) may have an ACL list which would restrict who could do what operations on it. The way I envision it working is that if a branch has an ACL, it would get checked against the current user and kind of access, which would be approved accordingly. In current practice, I have two repositories, one with golden code and another to which any developer can contribute. This is a little bit painful, as you can imagine. Thoughts? First, you can't really restrict just checkins on the trunk in a DVCS. Someone can always make a personal clone, unset whatever you have that is preventing those checkins, and then checkin on the clone. So you have to restrict pushes to the trunk as well. Because of that this feature seems to be missing from most DVCS's as a feature per se, but is covered by another common VCS feature that is missing from fossil: hooks. This kind of thing is then done by a pre-commit and pre-receive hook with the ability to reject the change. Hooks are apparently in the works for fossil: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg03190.html If your developers are only pushing changes into the repository (i.e. - no direct commits) and it's being run under an HTTP server, you might be able to get the servers authentication system to help here. I haven't looked at what fossil is actually doing under the covers, so this may not be possible at all. Finally, I think you've already found the correct solution with two repositories. Yeah, having to deal with two repos is a little bit painful - but it's only a *little* bit painful. Instead of merging from another branch, you have to pull from another repo. If you've got both repos being served via an http server (and here the server auth system should be able to help - you should be able to restrict access to each repo individually), that should be the only difference. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] fossil backend for zsh vcs_info...
Any other zsh users out there? If so I couldn't find a fossil backend for the vcs_info facilities in zsh (an API to extract info from various vcs's to display in your prompt), so I wrote one. No archives yet, but it's available from a chiselap repo at: https://chiselapp.com/user/mwm/repository/vcs_info/ The home page (from README.wiki) provides short installation instructions and a brief description where it differs from other vcs_info backends. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] SSH status
On Wed, 16 Feb 2011 13:38:08 -0500 Ron Wilson ronw.m...@gmail.com wrote: On Wed, Feb 16, 2011 at 12:03 PM, Chad Perrin c...@apotheon.net wrote: I've been rummaging through the list archives, and sifting through the Web documentation, but I am still not clear on the status of using SSH to encrypt connections for push/pull and other operations using Fossil. Is Assuming you already have Fossil set up on the remote server, the following should work: ssh -L8088:127.0.0.1:8080 -e 'fossil server repo' -f fossil sync 127.0.0.1:8088 This will start Fossil running on the remote end, forward local port 8088 to port 8080 on the remote and run a sync between the local and remote repos. (The -f will cause ssh to prompt for the remote password, if needed; otherwise use -n) (I am doing this from memory and I might not remember the exact details.) Seems like we ought to be able to leverage the inetd handling code (used by fossil http repo) in some way, though it may take some client side tweaking. Or is the fact that it only handles one http request going to keep it from handling a complete sync, push or pull request? Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Deploying A Web Application with Fossil and FTP
On Fri, 4 Feb 2011 13:44:18 -0800 Brian Smith br...@linuxfood.net wrote: For some personal sites, what I do is I actually have the fossil repo opened in the web directory. It's .htaccess'd off so that you can't get at it, even if you know it's there. Any particular reason to keep the repo in the web directory? Wouldn't putting it somewhere outside whatever security wrapper you have on the web server make more sense? Then, I've got a cronjob that once every 15 minutes does a 'fossil update release'. Where 'release' is just a tag that I apply to checkins that I feel are ready. I could probably also have a 'vX.Y.Z' tag so that I could force it backwards too, but, they're just personal sites. :) I've done this kind of thing with perforce for a couple of clients, including automatically syncing to test, q/a and then production servers. I could probably also wrap it in a script that did more complicated release logic, if I wanted. Based on my experience, you don't really need much release logic in the script. While mine was wrapped in a script, most of the script was to parse the output of the update command to find added/changed/deleted files to have the search engine index/reindex/delete them. Just create branches for the various sites in the release process (test, q/a, production or whatever) have each site open on the appropriate branch, with the repo autosyncing so the update command will pull from the master, and then your release process can focus on updating the branches in the master repo properly, and the web sites will follow along automatically. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] newbie failing to log into server...
[This didn't show up in the archives; I'm assuming a filter ate
it. Apologies if you saw it twice.]
Hello,
I've just started with fossil, so this is probably a simple problem -
but googling for it hasn't turned up anything.
I'm setting up a cgi server inside a firewall. I access it by ssh'ing
into a gateway box, using -L to forward local requests to the proper
host/port. The basic setup seems to be working, in either of two ways:
With cgi-bin/fossil that contains:
#!/usr/local/bin/fossil
directory: /home/mwm/repos
(I know, the docs say add a not-found, but wanted to see what it
did...).
Or with cgi-bin/reponame that contains:
#!/usr/local/bin/fossil
repository: /home/mwm/repos/reponame.fossil
I can access either one of those from my desktop machine (i.e:
localhost:2525/cgi-bin/fossil/reponame or localhost:2525/cgi-bin/reponame),
log in to the anonymous account, and look at individual commits, files,
etc.
However, if I try and log in using the userid/password from the repo,
I get
SQLITE_CANTOPEN: cannot open file at line 27596 of [fabcb6b95e]
SQLITE_CANTOPEN: statement aborts at 28: [UPDATE user SET
cookie='1/6E8AD0C7D6B7CDB96470AE6EF37458A19344AE610099A3D23E',
ipaddr='202.80.186.24', cexpire=julianday('now')+31557600/86400.0 WHERE uid=1]
Database Error
unable to open database file
UPDATE user SET cookie='1/6E8AD0C7D6B7CDB96470AE6EF37458A19344AE610099A3D23E',
ipaddr='202.80.186.24', cexpire=julianday('now')+31557600/86400.0 WHERE uid=1
If you have recently updated your fossil executable, you might need to run
fossil all rebuild to bring the repository schemas up to date.
Well, I recently *installed* fossil, so I don't think the rebuild is a
problem. However, I did try rebuilding the repositories. This didn't
help.
The ultimate goal is to push to the repo.
thanks,
mike
--
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
