Re: [fossil-users] Fossil 2.1: Scaling
On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp d...@sqlite.org wrote: Ben Pollack's essay at http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ succinctly points up some of the problems with DVCS versus centralized VCS (like subversion). Much further discussion occurs on the various news aggregator sites. So I was thinking, could Fossil 2.0 be enhanced in ways to support scaling to the point where it works on really massive projects? The key idea would be to relax the requirement that each client load the entire history of the project. Instead, a clone would only load a git can do this, and it's a relatively new feature. The really nice thing would be to load whatever is needed on demand, or to perform certain operations (e.g., producing annotated sources, viewing history, ...) on the server. limited amount of history (a month, a year, perhaps even just the most recent check-in). This would make cloning much faster and the resulting clone much smaller. Missing content could be downloaded from the server on an as-needed basis. So, for example, if the user does fossil update trunk:2010-01-01 then the local client would first have to go back to the server to fetch content from 2010. The additional content would be added to the local repository. And so the repository would still grow. But it grows only on an as-needed basis rather than starting out at full size. And in the common case where the developer never needs to look at any content over a few months old, the growth is limited. By downloading the meta-data that is currently computed locally by rebuild, many operations on older content, such as timelines or search, could be performed even without having the data present. In the bsd-src.fossil repository, the content is 78% of the repository file and the meta-data is the other 22%. So a clone that stored only the most recent content together with all metadata might be about 1/4th the size of a full clone. For even greater savings, perhaps the metadata could be time-limited, though not as severely as the content. So perhaps the clone would only initialize to the last month of content and the last five years of metadata. For wide repositories (such as bsd-src) that hold many thousands of files in a single check-out, Fossil could be enhanced to allow cloning, checkout, and commit of just a small slice of the entire tree. So, for example, a clone might hold just the bin/ subdirectory of bsd-src containing just 56 files, rather than all 147720 files of a complete check-out. Fossil should be able to do everything it normally does with just this subset, including commit changes, except that on new manifests generated by the commit, the R-card would have to be omitted since the entire tree is necessary to compute the R-card. But the R-card is optional already, controlled by the repo-cksum setting, which is turned off in bsd-src, so there would be no loss in functionality. Yes, this would be very nice. Though a BSD would probably need significant build system rototilling to make it possible for developers to work on isolated portions of the code with partial clones only. The sync protocol would need to be greatly enhanced to support this functionality. Also, the schema for the meta-data, which currently is an implementation detail, would need to become part of the interface. Exposing the meta-data as interface would have been unthinkable a few years ago, but at this point we have accumulated enough experience about what is needed in the meta-data to perhaps make exposing its design a reasonable alternative. Exposing the metadata would be one of the best things Fossil could do, IMO, once it's ready. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to force text for all files?
On Sun, Dec 7, 2014 at 12:35 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Dec 7, 2014 at 6:55 PM, to...@acm.org wrote: The problem: A (mostly) text file with just a few normally non-text chars which confuse fossil into thinking the whole file is binary. There's an irony in there somewhere. It can't be partly binary, it is either entirely binary or not binary. i.e. 0 or 1. There is no middle ground (in the world of integers). A VCS shouldn't have to know the contents' type, not for the purpose of versioning the file, except that: - for diff presentation purposes it helps to know - there may be many delta algorithms to choose from, and the contents' type might help choose one Picking a default sanely is a useful thing to do; an 80/20 heuristic is needed. If the heuristic can be cheaply fine-tuned to be 90/10, so much the better. When the heuristic fails the user should be able to tell the VCS what the content type is. Whatever content type is set (even if heuristically determined) should be sticky, even if a subsequent commit introduces contents that yields a different heuristically-determined content type. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to do branching with new major versions
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote: On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote: Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible fix if there have been additional commits is to reverse cherrypick out the change but that leaves the timeline without a clear visible trace of the actions. A similar option would be to cherrypick the post-goof commits to a new trunk and rename the goof + downstream commits as branch goof and then close (and maybe hide) it. Do you have a better way to do this? On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) More seriously, rebasing the upstream generally means that downstreams need some instructions on how to recover. I've been thinking that any VCS with first-class support for rebasing ought to have an option to record in a merge-like commit what has been done in a rebase operation. Something like a commit with subject Rebase, the rebase script in the message body, and, crucially, two parent commits listed: the pre-rebase head commit, and the base commit for the rebase. This would provide everything a downstream needs to recover, and it would record what happened. And it would retain live references to dead branches, thus preventing garbage collection commits that would not be reachable but for Rebase commits. I wonder if something like that could make rebase more acceptable as a concept elsewhere than git. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Thu, Sep 11, 2014 at 10:18 AM, John Long codeb...@inbox.lv wrote: On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote: On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote: git branch -D name Eh, filesystems let you delete files. Unlike most filesystems, git lets you restore your deleted branches (yes, provided you don't gc the repo). Then just use a file system and various command line tools! But seriously, it's a philosophical difference between those who want to be able to rewrite their history to what they should have done and those who want to keep the history around to see what they did. I can understand for personal projects people might want stuff to disappear. And I can understand vandals want to make stuff disappear when they attack a system. But in a serious, large project there are often requirements for an audit trail. There is no downside to this given the cheapness of backing storage. And it can prevent all sorts of problems. If you want a secure audit trail then you have to send the audit records elsewhere (preferably replicate the trails too). And you have to commit the audit records to their destinations before (or otherwise atomically as) commits are incorporated into a repo. Refusing to modify history doesn't make history unmodifiable -- Merkle hash chains alone only provide integrity protection for the past, but not if the attacker controls it and the present. An attacker can always edit the history directly via SQLite3 access to the repo. Of course, anyone who has fetched the pre-edit history will notice the re-write, which is why pushing and pulling often is helpful. Alternatively you can sign commits. Then editing history breaks the signatures, thus requiring re-signing of edited commits or a signature by some authority describing what history editing took place and why. In the places I work the problem tracking system entries are immutable. And [...] Nothing can really be made immutable, but you can detect mutation. That has nothing to do with whether a VCS permits mutation, and everything to do with using Merkle hash chaining and replicating (auditing, if you wish) the chains to secure storage as soon as possible so as to make mutation detectable. Whether to permit mutation for all, some, or no branches, is a policy decision to be made. I don't think one size fits all. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to do branching with new major versions
On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams n...@cryptonector.com wrote: On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) Except that the original sequence of changes is preserved in the tree, not discarded at the next GC. That's an important difference. Right, and I very much agree with that. But you're doing this without first-class support for rebase; it's a very manual process :( ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Thu, Sep 11, 2014 at 11:18 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams n...@cryptonector.com wrote: Nothing can really be made immutable, but you can detect mutation. No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6 release) cannot be modified in any way without changing its hash value, thus making it something different. (Unless you can mount a pre-image attack against SHA1 - let's assume that is impossible.) But the repo containing it can be mutated to, for example, no longer have that commit. This can only be detected. It can't be prevented. Merkle hash chains are only one part of the detection story. Digital signatures and/or replication are another. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal sgb...@googlemail.com wrote: No, he can't. Well, he can, but he will break the hashes of other records, so any tamping will be noticed. Specifically, the Z- and R-cards detect any sort of tampering. Right. He can. If you've not pushed the commits anywhere else before the attack, and if you've not signed them, and if no one has pulled the commits elsewhere before the attack, then you can't detect it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to use git to lose data
On Mon, Sep 1, 2014 at 10:29 AM, Stephan Beal sgb...@googlemail.com wrote: Okay, more git bashing... Seems like a lot of the complaints are the sorts of complaints you would get about -say- laptops: - it's easy to forget you left something on your laptop two flights ago, when you had no connectivity, and forgot to copy it to ... Maybe mobile devices should behave like Fossil repos, though that would require automatic conflict resolution to be workable. I've long thought that we need a decent filesystem with disconnected operation functionality. And with ZFS and such we know that a Merkle hash tree version-control-like approach works well for filesystems. But on the other hand, I like to be in control of what code goes up and what doesn't. To me the designed to forget comments seem like a stretch. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pull requests
On Tue, Sep 2, 2014 at 6:47 PM, Richard Hipp d...@sqlite.org wrote: (3) Create a new fossil bundle import command that imports a bundle as a *private* branch. Require a branch name as an argument and there will be no need to think about branch name collisions. It doesn't matter that the branch namespace is not unique for Fossil; it has to be for users. Nico -- ___ 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-based arrangements. code review and ticket export
On Sat, Jul 26, 2014 at 10:04 PM, Eric Rubin-Smith eas@gmail.com wrote: Richard Hipp wrote: Fossil can give you the ticket data as SQL. I think that is probably about as portable as ticket data is going to get. +1 ... says the top SQL expert between here and the Romulan Neutral Zone. :-) But it's true though. Sure, a JSON representation of the same data would be more portable in some sense, but either way you have a standard representation of complex data with a plethora of tools to manage it. SQL is quite powerful; if the schema transformation required is very complex then SQL is the right tool for the task! Fossil *could* support export to JIRA+git in particular, for example, by providing a tool that (a) exports to JIRA's supported JSON import format, (b) collects the mapping from the fossil ticket IDs to the JIRA ticket IDs, then (c) does a git export but massages the check-in comments according to the data collected in (b). My approach to this sort of task is to write a small Python program to extract SQL data in a dead-trivial JSON encoding (an array for every row, with each column mapped to an element of that array), ETL (extract-transform-load) either the SQL data (i.e., with complex queries), the JSON output (with jq), or a combination, to match the desired schema. Typically I do JOINs and such in SQL as that will run much faster in the RDBMS (since it has an optimize) than I could code it myself. My favorite tool for ETL (extract-transform-load) at the JSON level is jq (https://stedolan.github.io/jq). Full disclosure: I maintain jq, so this is shameless self-promotion on my part. SQL is declarative, jq is functional. There's a pattern there :) Nico -- ___ 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 CLI tricks: interrupting a commit message
On Mon, Jun 16, 2014 at 11:49 PM, B Harder brad.har...@gmail.com wrote: Remember that the buffer is only one level deep, though. A subsequent ^W, ^K , etc will clobber the previous contents. Along lines of Stephan Beals method, I use : preceding the fossil command. So: $ : fossil ci -m 'some msg' ($ is shell prompt). While we're on stupid shell tricks... If you setup your $PS1 and PS2 just so you can make your commands safe to cut-n-pase. Set $PS1 to something that starts with : and ends with ;, and set $PS2 to just whitespace. I do something similar with the sqlite3 shell... Nico -- ___ 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] Intent to release version 1.29
On Thursday, June 12, 2014, JR jr...@saintlyreverend.com wrote: I will avoid the rant I had just written and simply say that I do not use cmd.exe except where required. I use PowerShell exclusively, which makes cmd.exe look like the ancient tool it is, and there are debates that PowerShell is better than bash due to its use of objects instead of straight text (I suck at regex, so I prefer objects). I will leave that flame war for another day, as I like bash on *nix machines and love PowerShell on Windows. I just don't like to mix the two :). I really want something like a powershell for Unix, but still somewhat similar to the typical Unix shell, and with JSON as the object representation (since that will play best with existing tools, the environment, and command-line arguments). Ideally i'd want something like jq (https://stedolan.github.io/jq -- something of an awesome JSON query language as an inspiration for such a shell. Nico Full disclosure: I am a contributor to and maintainer of jq, but biased as I am by this, I think one can objectively say that Stephen Dolan did an awesome job. ___ 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] autocrlf like in Git?
On Sun, Jun 8, 2014 at 7:15 PM, Ron Wilson ronw.m...@gmail.com wrote: On Sat, Jun 7, 2014 at 8:37 PM, Nico Williams n...@cryptonector.com wrote: The same is true for git, and Mercurial, and... It doesn't mean it can't be done, just that the VCS has to know how to canonicalize the file's contents, and that is awful. But sometimes someone has no choice. Depends on how you define no choice. [long] Did you read what I wrote after that? Nico -- ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 1:32 PM, Stephan Beal sgb...@googlemail.com wrote: It's unfortunately not a minor technical issue because of how fossil calculates the hash for the whole contents of a repository for ... The same is true for git, and Mercurial, and... It doesn't mean it can't be done, just that the VCS has to know how to canonicalize the file's contents, and that is awful. But sometimes someone has no choice. Like OS X's HFS+, which normalizes path components to NFD. Either the user, or the VCS, have to work around such problems. In the case of HFS+ that means never using characters where NFD form and the forms produced by the users' input modes differ... or having the VCS deal. In the case of CRLF vs. LF the VCS can be told to canonicalize those for specific files. (The HFS+ NFD thing first bit git years ago, and Linux Torvals ranted about it. His rant was about ZFS, which wasn't to blame -- the aborted Apple port of ZFS to OS X changed ZFS behavior to match HFS+'s. But for that he was quite right. A filesystem that does this is intolerable, especially when the Unicode form chosen happens to not match the form output by input modes most commonly (which isn't quite NFC, but usually is, at least for all Latin scripts).) Nico ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. Also, one may want to break up a commit into: code, test, doc updates that go together, in which case the test may not pass for one of those commits by intention. ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Saturday, June 7, 2014, Andy Bradford amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org wrote: Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. This workflow certainly seems like a lot of time spent playing with the tool and less time working on code. Do Git users typically make such large commits? Why don't they just use branches to separate different lines (as in tracks) of development rather than bundling a bunch of unrelated checkins all at once? Not git users. Engineers who work on codebases with maintenance releases. For example: Solaris, Windows, ... but also a number of smaller projects, like MIT Kerberos, Heimdal, and so on. When you have a bug that needs to be fixed in older releases, you want to be able to cherry-pick it, and sometimes you don't know this until after you've integrated a fix for it in the main trunk. This is one reason that clean history is appreciated. And when investigating a bug it's also nice to be able to look back through the history and understand what was done (as opposed to how a programmer got there, which is ticket/comment fodder). (For years i worked on codebases where we used Teamware -an ancient, ancient VCS now- and we'd worked out how to implement a rebase-heavy workflow, in a team of thousands. This isn't about git. Git just happens to be the first modern VCS that made this workflow possible with little pain. If i had to use Fossil in such a workflow, I'd do the sorts of things i was used to doing with Teamware, as meantioned earlier in this thread.) The first case is easy to drop: never keep maintenance releases. Mostly that's the right thing to do, especially if in the process you can train your users to stay on the bleeding edge instead of worrying about upgrading with every critical security bugfix. But it's not always possible or easy to do this, or perhaps having older releases on maintenance is part of the vendor's business model. Either way, there's still the matter of clean, comprehensible history -- reasonable people can disagree about this, of course, and precisely because of that there are codebases where the gatekeeprs force a rebase heavy workflow on contributors. I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. I also want the power of SQL for history, and so on. So I can get this neither from Fossil nor git. Well, so be it. I won't be adding writing a VCS to my bucket list, we each have our priorities, and I wouldn't likely do a very good job of it; at most I will pursue minor extensions (or hooks) to git to get me the query power and recovery semantics I need. I think it best now for me to let this poor dead horse be. Thanks for listening and engaging me on this subject, and my apologies for taking so much of your time (especially since I love SQLite and want to do nothing to slow down your efforts there), Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo agalys...@gmail.com javascript:_e(%7B%7D,'cvml','agalys...@gmail.com'); wrote: I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print: http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I click on the - and + to stage the line). But today, using fossil, I couldn't find anyway to do that, so I had to put all the changes on the same commit. Well, in the theory I can work on one task at time and commit when I finish, but in the practice I work on all the tasks at same time. Right. Having to backport fixes to maintenance release branches will make one hunger for tools that make it easier to disentangle a pile of changes. It really helps to have individual bug fixes and feature additions isolated for easy cherry-picking into maintenance release branches (as well as for easy code review (prior to and after integration). The Fossil and SQLite developers have the luxury of mostly not doing backports though. Admittedly, that is my first answer to backports as well: don't! And when i don't have to worry about maintenance release, i do tend to put less effort into having clean commits -- depends on the codebase, and whether there is a code review process, or who the reviewers are. But not everyone has that luxury, or at least not all the time. Still, the community and maintainers appear have spoken. Fossil is at least not appropriate for some projects that I work on, and yet I yearn for something Fossil-like. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 10:36 AM, B Harder brad.har...@gmail.com wrote: drh Fossil allows you to commit a subset of files (by listing the files on the fossil commit command line) but there is no mechanism for committing a subset of lines within a single file. That, and there _are_ branches/tags which are encouraged to be used... my prev comment was for the case where a single file gets two-thoughts worth of changes (subset of lines). For subsets of lines (assume we want two logical commits), I head to my editor, tease out logical Key words there: tease out. You have to stare at diffs and do/undo part of the change by manual application of diffs. Compare to SourceTree's interface to the index: https://www.google.com/search?q=sourcetree+stage+hunk+screenshotstbm=ischtbo=usource=univsa=Xbih=663 Or git add -e or -p, or hg record. SourceTree's GUI interface lets you: - stage/discard/neither by hunk - stage/discard/neither specific lines in hunks - edit hunk lines to be staged That's also what git add -e lets you do. It's just much easier to disentangle large diffs this way than with manual teasing out via $EDITOR. section1 - tmp file. fossil stash save -m logical thought temp1 ./file-of-interest; re-enter tmp.file - file-of-interest; fossil ci -m description of logical thought ./file-of-interest; fossil stash pop [edit if necessary]; fossil ci -m description of other logical thought ./file-of-interest I know how to do this. I did this for many, many years before the advent of git, and my learning git add -p/-e. Even a grumpy systems guy whose every command-line is a script... can learn to love not having to do error-prone operations like this in such a manual way. I could never teach my non-programmer spouse to do what you do to work around Fossil's lack of anything like hg record or the git index, but with SourceTree's interface to git she does this every day without breaking a sweat. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. Sometimes I don't realize that A is really two separable changes worth separating. Or maybe I don't think they are worth separating but my upstream does. Or maybe I'm the upstream and it's a contributor that I am asking to split up A. Counting on foresight is not a good plan :) The main reasons I can think of to not have an index are that one either really is so careful that they have such foresight, and/or one does not [have to] care to disentangle changes. Fossil and SQLite3 seem to only move forwards: there are no maintenance release branches, because there are no maintenance releases. Need a bug fixed? Get on the bleeding edge. That works fine for some projects, in which case Fossil will do. Otherwise one must very manually disentangle changes or not use Fossil. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com wrote: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a fossil stash snapshot. Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: Ah, foresight. I should be blessed, but I am not, for that that's not how I work. I have different reasons for opposing the ability to checking individual lines of a file, and I'd like to get Nico's feedback: The reason you should never do a partial check-in of a file is because you clearly have not tested that partial change. And you should always test your code before you commit. Especially when committing to trunk. Ah, I forgot to mention how I deal with that: I abuse (but Fossil could do this differently) git rebase -i, adding an exec line after each commit to run tests. I say abuse because the rebase is a no-op as far as history is concerned. This is standard use of rebase in git-land though, and I won't fault anyone for thinking this should be done with a less scary-sounding command. In Fossil terms that would be like checking out each commit in the series to be integrated/pushed upstream, run tests, then checkout the next commit. Wrap that in a script and there you go. It is true that wanting clean history upstream does lead to something of an interactive-rebase-test loop. That's the price of clean history. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I'm not Nico, but allow me answer that as well. When I was learning to use git, my teacher told me: When you have a set of changes where a peace of code requires another peace, you must commit all that together. But if you have a change that doesn't have any dependeces, you should commit that change alone. Where to draw the line is a bit of an art. The programmer (and code reviewers) have to judge what changes are independent in some way and which are too interrelated to be separable. This is true. And, well, the same reason you can use to not allow partial chink-in of a file can be used to not allow commits on a set of files. So, if we have commit what we tested, we alwayes must to commit all the changes in all the files. That's the same point that DRH made, and so it gets the same answer: you must test each commit. And there's a way to with git, and surely that can also be scripted for Fossil (or written right into Fossil). And yes, every time your individual commits fail to pass tests you have to go rebase. So there is another reason to not want an index: if you get it, you'll inexorably also want rebase functionality, including interactive rebase. And if you hate (or misunderstand) rebase, you'll then not want an index. I hadn't considered this. Of course, I like rebase -- no surprise there. And the Fossil community evidently hates rebase. I suspect I can't sell you on rebase, even though I'd like to, and even though I think a dislike of rebase results mostly from misunderstanding what it is and how to use it. (As opposed to a dislike of having to rebase, which is what happens when an upstream asks a contributor to rewrite their history -- more homework - dislike.) Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: You're mixing things up :) Rebase is just a script around new branch starting at given base, cherry-pick all the commits from the base to the head of what's being rebased. It's a script, literally. It can't break your repo. You're right, i'm confusing rebase and reset (and its --hard option). Thank you for so politely pointing that out :). This is a very polite crowd. When in Rome... :) - if the index is not empty, then the user can't change branches - if the index is not empty, then commit should commit only what's in the index Neither of those seems to pose any problems, so long as the index isn't using the current versioning-related infrastructure (concretely: doesn't have any unique content which is referenced by other commits). This is certainly a use case i'll explore in libfossil (where i've got a bit more leeway in making changes). Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. [...]. It's not about undo. It's about capturing a subset of the extant deltas for committing. i've only ever used the index for (basically) an undo area, but you're right, that's probably not what most people use it for. In my mind the index is basically autosync=0, but of course that's a hugely oversimplified world view. The index is very ephemeral, unlike stashing. I never use git stash, and I don't care for it. stage is close to stash, so I can see the confusion. i have some ideas about how this could be done. In libf it would be relatively straightforward, i think, because it allows the client more control over the source and destination of the content bytes. In fossil it would require more infrastructure, but probably not prohibitively much. In terms of primitives it's not much. You should play briefly with the index in git: % git init % date somefile % git add somefie % git commit -m initial % date somefile % sleep 1 % date somefile % git add -e somefile select the one hunk and choose to edit it so as to take one, but not the other of the two new lines % git commit -m add a date % git diff % git commit -m add another date % git log -p Now picture working on some bug and then you realize you've written a fix for two different things, and you want to disentangle them into two commits. How? You could checkout a clean workspace and manually add the changes for one fix, commit, and go from there. Or, you can use git add -p or git add -e and it's much, much easier. It's like having a logical snapshot of the workspace set aside. You add things to the index (copy, if you like) from the workspace, then you commit what's in the index. The stash is similar, at least in principal, so there may already be a basis in place for something like this. The stash is much more permanent. The index is much more ephemeral. These are the things you can do with an index: - add to it - inspect it - remove from it - commit it A stash is a more complicated beast, as it's really saving extant changes in a bundle with a name. But you're right that the stash too is something that can be bolted on the side of the VCS with relatively little help from the VCS. In a sense the index and stashing are alike. But the index is much easier to use and explain. If you can use OS X and try out the SourceTree app.. that will make it even easier, self-evident even, straightforward. I mean, my wife discovered the SourceTree equivalent of git add -e and just used it, even though she was days into learning how to use SourceTree. It allowed her to really solve a real problem without having to learn how to rebase to split commits (which is a much more difficult thing to explain!). Sounds reasonable. :) I have to use Mercurial in some cases. My commit history for git projects tends to be much cleaner than for Mercurial projects, and this is largely due to the index and git add -p/-e (and the way _I_ go about writing code). Fair enough. i've just jotted down some ideas to play with, but i can't commit to any timeframe. I ask for no commitments. I wanted only to plant seeds. :) Ideas on implementation strategies are of course welcomed! I will look at Fossil source and think about it. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com wrote: Mercurial too had heavy-duty branches only, then they added bookmarks that are very similar to git branches. Since a bookmark is just a symbolic name for a commit... this is just a new table at best, with two columns. Bookmarks. That's a nice idea, actually. Added to my TODO list. It's interesting that I just sold you on the git branching model, by using the Mercurial analog. I don't know what that says. To me any heavy-duty branching model is difficult to explain, but clearly bookmarks are easy to explain, or at least easier to explain when you start from a heavy-duty branching model. Regardless of what it means, it's good! :) You might find that it helps to have boomarks and something like detached HEAD mode. Detached HEAD mode is a fancy name for checking out a commit (or adding one to a detached HEAD) that may not be reachable from a branch name / bookmark / tag. But it's not critical. If checking out a commit requires giving it a name (bookmark), that's annoying, but workable. Nico -- ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:15 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 6:03 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com wrote: Bookmarks. That's a nice idea, actually. Added to my TODO list. i was thinking more generically: f bookmark add blah trunk f bookmark add 'oops!' deadbeefabcdef0123 f bookmark ls [blah] = trunk [oops!] = deadbeefabcdef0123 f co bk:oops f merge bk:trunk i.e. a system with which to assign non-version-tracked aliases to arbitrary other symbols which we already know how to resolve. They needn't be push/pull'able, but it might be nice to be able to. We already have precedents for special symbols like bk:NAME, e.g.: To be truly useful it has to be possible to [selectively] push/pull bookmarks. Strictly speaking, bookmarks needn't be versioned, but it's nice to have something like the git reflog to help you recover from accidentally clobbering a bookmark. In effect, bookmarks' history needs to be versioned, because let's face it, the git reflog is an odd bolt-on thing, odder still when you consider that git has a powerful history mechanism. So, yeah, bookmarks should be versioned. Nico -- ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:53 AM, B Harder brad.har...@gmail.com wrote: Indeed, non-propagating tags are also checkout-able items. What am I missing about bookmarks that we can't already enjoy w/ tags, outside of new syntax ? In git, tags and branches are both very light-weight bookmark-like concepts. The differences are as follows: - both can be pushed/pulled, but tags have a single global namespace - while branches are namespaced by a remote repo name - when you checkout a branch and then commit something, you automatically move the branch to point to the new commit as its HEAD - when you checkout a tag you're in detached HEAD mode; adding a commit leaves you in the same mode -- the tag doesn't move or change Nico -- ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:24 PM, Stephan Beal sgb...@googlemail.com wrote: In the core, basically the only addition would be adding another block to symbolic_name_to_rid(), which simply expands the ... part from bk:... from the bookmark list, then runs that result through through symbolic_name_to_rid(). That would allow all other APIs to inherently resolve bookmarks (or aliases might be a better name). Right, a light-weight bookmark need to be referenceable as a symbolic name of a commit just as any tag or branch. That's what Mercurial does, FYI. ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 12:30 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Jun 4, 2014 at 7:25 PM, Nico Williams n...@cryptonector.com wrote: To be truly useful it has to be possible to [selectively] push/pull bookmarks. If that's the case then they really provide no benefits over propagating tags (which are versioned), but note that Fossil cannot selectively See my notes about the differences between tags and branches in git, the most important of which I'll repeat and expand on here: - when you checkout a tag and then commit something, the tag doesn't move with the HEAD of your workspace -- you're in detached HEAD mode when you checkout a tag - when you checkout a branch and you commit something, the branch's HEAD moves with the HEAD of your workspace. E.g., % git clone somerepo myclone % cd myclone % git tag list of tags; pick one % git checkout footag Note: checking out 'footag'. You are in 'detached HEAD' state. [...] ... % date f % git add f % git commit -m example % git show HEAD the commit we just did % git show footag the commit we were on before Now branches: % git checkout master % date f % git add f % git commit -m another example % git status -uno # On branch master nothing to commit (use -u to show untracked files) % git show HEAD the commit we just added See? Tags are precious: they are for noting releases and such, so mostly they are not intended to be modified. Branches are intended for ongoing development, so adding a commit with a given branch checked out moves that branch's HEAD. Nico -- ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams n...@cryptonector.com wrote: Right, the index is a very light-weight mechanism for giving the user power in deciding what to commit. I.e., more fine-grained control than choose what files to commit. My view is that the Git staging area (I really dislike the use of the word index in that context) merely makes Git more difficult for people to understand and complicates the interface without adding any new capability. I felt it was a power feature that made my power user life better. Then I showed my wife how to use SourceTree on OS X. I had figured that I'd never show her the index. ETOOHARD I thought. Until something came up where she needed to discard some changes and keep others she had made to a file. SourceTree's GUI interface to the index turns out to be very natural and easy to you. I couldn't believe it, but she picked it up immediately even though she'd never before used git and I'd never thought of how to build a UI to the index. In retrospect the thing is this: at a CLI level, yes, the index requires that users know how do deal with and even edit patch chunks in order to make powerful use of it, and for most users that's just a lot of detail. But in a GUI it turns out that the index can be made a very easy to use feature. The staging area is another element of state on a check-out. It is one more thing that the developer must keep in mind. Better to minimize the amount of mind-space required for the VCS in order to leave as much mind-space available to the application as possible. Mind-space is a finite resource. Use it wisely. The staging area complicates the interface. Instead of just a diff between the current check-out and the most recent check-in, now you have to add syntax for a diff between the checkout and the staging area and a diff between the staging area and the most recent check-in. Multiply that by as many commands as you have that involve both the repository and the current check-out. Does undo/redo effect the staging area? What if you update in order to pull in changes made by a collaborator before you commit - how does that effect the staging area? How does the staging area interact with the stash? If you are making a change in one branch and decide you'd really rather have that change in a different branch (or you just happen to discover that you were mistakenly on the wrong branch - which is the usual reason this comes up for me) and you move all your changes to a different branch prior to check-in, does your staging area move with you or not? Thousands of details like this need to be considered. And all of these details and complications and the associated mental clutter can be quickly and easily eliminated simply by omitting the staging area. My understanding is that the Git staging area arose as part of the implementation showing through into the interface. In Git-speak, it is plumbing that is visible from the porcelain. It is a misfeature. My readings on the matter suggest that most people agree with me on that point. Please keep all thoughts of a staging area far, far away from Fossil. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] git-fossil-git does not obtain the same commit hashes.
So git doesn't handle power failures so well... And Fossil's use of SQL, and SQLite3 in particular, is awesome. But my colleagues and I like git workflows, and anyways we have git repos we can't just migrate to Fossil. The obvious idea is to use a git post-receive hook to backup git to Fossil, which would give us the ability to a) use Fossil for informational purposes, b) use Fossil as a high-level backup/restore for git. However, a git-Fossil-git doesn't produce the same commit hashes. It seems like it ought to be possible to reproduce the exact same commits, therefore the exact same commit hashes. Looking at the very first commit in a test run of a git-Fossil-git conversion, the only differences are: - the commit author information (Fossil loses the comment part of the author's RFC5322 email address) - the date (Fossil changes the timezone to +, that is, it loses the timezone of the original). If these two issues were fixed then at least the initial commit of the repo I was testing this on would end up with the same commit hash. I'm guessing there will be other minor differences in, for example, merge commits, but first things first... Two ideas occur for fixing this: either add metadata so that Fossil can reproduce git commits exactly, or store the commit headers as-is in Fossil along with Fossil's parsed metadata from the same. The latter will work better, but seems like a hack. The former might prove to be a lengthy iterative process and may be git version sensitive. Nico -- ___ 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-fossil-git does not obtain the same commit hashes.
On Tue, Jun 3, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.com wrote: My point being: at least some small percentage of round-trip timestamp conversions will fail because Julian Days to not have a 1-to-1 mapping for all millisecond-level ranges in use today. Yes, though perhaps Fossil could store the Date (and Author) headers from git exactly, for reconstruction of git repos from Fossil. I'm guessing there will be other minor differences in, for example, merge commits, but first things first... ANY difference results in a different hash, so the email change is enough (regardless of all my blather about timestamp precision changes). I'm aware. FWIW: Fossil was never intended to be a round-trip safety hatch for other SCMs which aren't as data-robust. Maybe convince the git developers to move their metadata into sqlite instead? Being able to round-trip this way might allow more users to test-drive Fossil. Getting radical architectural changes to git accepted seems likely to be impossible. I'd rather convince the Fossil developers/community to support the git features we need: - workflows that use rebase (not on public branches, of course), including interactive rebasing - the git index, including git add -e/-p - by default only push the branch that's checked out Since Fossils can cherry-pick, rebase shouldn't be difficult. We'd not mind if rebase always results in a new branch being created, for example. BTW, even non-power users can make powerful use of the git index. I've been using SourceTree on OS X lately to teach a novice how to use git, and SourceTree's interface to the index is shockingly straightforward, easy to understand, and easy to use. I'd expected that a GUI just would not be able to provide a decent git add -e/-p interface, but SourceTree delightfully surprised me. Things my colleagues and I are used to: - the index, of course - workflows with feature branches and clean history at integration into master time, preserving interesting history (e.g., bug fixes for cherry-picking onto maintenance release branches, feature-related commits) but not uninteresting commits (fix intra-feature branch history typos/bugs) - workflows with distributed and hierarchical teams - merge-heavy workflows with multiple remote repos and trunks (different product vendors collaborating and competing using an originally common codebase) Nico -- ___ 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-fossil-git does not obtain the same commit hashes.
On Tue, Jun 3, 2014 at 1:32 PM, Andy Bradford amb-sendok-1404412362.ophlclhccgjkadkek...@bradfords.org wrote: Thus said Nico Williams on Tue, 03 Jun 2014 11:42:44 -0500: - the date (Fossil changes the timezone to +, that is, it loses the timezone of the original). Timestamps in Git are UTC and have no timezone offset. There may be additional metadata associated with a commit that records the timezone of the user making the commit, but that is informational only and not actually relevant to the commit timestamp (at least as far as Fossil is concerned). Right. Fossil doesn't really care about timezones (all timestamps are in UTC), but perhaps a git-timezone tag could be added to the artifact? Right, that was one suggestion. Nico -- ___ 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-fossil-git does not obtain the same commit hashes.
On Tue, Jun 3, 2014 at 2:03 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 3, 2014 at 8:07 PM, Nico Williams n...@cryptonector.com wrote: Being able to round-trip this way might allow more users to test-drive Fossil. It's not possible due to the limitations of round-tripping doubles to and from ISO format. Some percentage of the records will not translate accurate (at the msec level). It's possible by storing additional metadata. Redundant, annoying even, but to be ignored most of the time (except when computing hashes and when exporting to git). Getting radical architectural changes to git accepted seems likely to be impossible. I'd rather convince the Fossil developers/community to support the git features we need: Good luck with that ;) These aren't architectural changes. For example, rebase == scripted sequence of cherry-picks. The index is more architectural, but not really that intrusive. Pushing only one branch, and so on, are also not really very intrusive (FYI, git went through that same evolution, in that initially the default was to push all branches unless you named a branch(es) to push.) - by default only push the branch that's checked out Some work was done a year or two ago(?) on pushing only certain branches, but i don't know where that ended up (not in the trunk, AFAIK). See? Things my colleagues and I are used to: - the index, of course - workflows with feature branches and clean history at integration ... - workflows with distributed and hierarchical teams - merge-heavy workflows with multiple remote repos and trunks Something to consider: the only thing git's lacking from your wish-list, apparently, is durable storage. Conversely, Fossil seems to be lacking all features you rely on _except_ durable storage. You're missing one item: a relational approach to history. I'm sure git can be fixed to recover more cleanly from interruptions during receives, commits, and so on. Composition of atomic operations from filesystem operations is difficult but not impossible. I'm sure eventually git will improve in this area, probably getting to good enough. But SQL? It'll never happen. One could bolt-on a metadata-only SQLite3 DB using git hooks, I'm sure, but being external would make it fragile. Nico -- ___ 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-fossil-git does not obtain the same commit hashes.
On Tue, Jun 3, 2014 at 4:15 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jun 3, 2014 at 10:49 PM, Nico Williams n...@cryptonector.com wrote: git rebase... doesn't remove commits from the repo. It only creates new commits and then updates a branch's head to point to the newest of the new commits. Therefore rebase doesn't violate that constraint. Based on that description, that sounds doable, but i'm inherently dubious of rebase because i've broken my git repos more than once when using it. (That said, i'm not the one you'd need to convince ;) You're mixing things up :) Rebase is just a script around new branch starting at given base, cherry-pick all the commits from the base to the head of what's being rebased. It's a script, literally. It can't break your repo. (A rebase of a branch that had been referenced from downstreams will break them, which is why one should not do it to a public branch. And the old commits may be left unreachable from any branch name, so you might think your repo is broken, but you can still find those commits and create branches that refer to them.) git branches are really just symbolic names for commits. And commits not reachable from any branch or tag can be removed if you prune dead branches, but I'm not asking that Fossil have this functionality. Fossil's internals would indeed make it very difficult to do that. Mercurial too had heavy-duty branches only, then they added bookmarks that are very similar to git branches. Since a bookmark is just a symbolic name for a commit... this is just a new table at best, with two columns. Because it was built with that philosophy in mind, it makes optimizations based on that which make undoing it (e.g. so a staged or unpushed commit could be undone) amazingly hard. The index has nothing to do with this. Deltas in the index are not in the repo. They are just the deltas that will be in the next commit, that's all. The index is in the db, along with everything else. Fossil would currently need a separate set of delta tables and algorithms to accommodate that, or some way to say do not consider these artifacts for delta purposes. It could be in the DB, but it doesn't need to interfere with anything. The only requirements: - if the index is not empty, then the user can't change branches - if the index is not empty, then commit should commit only what's in the index Any tools to manage the index could then be totally external (contributed). About 6 months ago or so i investigated what it would take to support undo of popping the top-most change from a repo (be it a tag, wiki change, or whatever), and the checklist of TODOs (and associated complexity) quickly grew longer than my hair :/. Right, and that's just not something I'm interested in. But it would provide a git-like staging area in that you would have one level of undo. And then another level of undo... and another, all the way [...] You misunderstand the index. It's not about undo. It's about capturing a subset of the extant deltas for committing. - for the index all that's needed is a way to apply a commit without referring to the checked out files, and a way to prevent switching to other branches while the index is not empty The commit model in fossil is fundamentally based on the sha1 of the contents of the file. How do we get that without referencing the files? The index captures the content to be committed. It's like having a logical snapshot of the workspace set aside. You add things to the index (copy, if you like) from the workspace, then you commit what's in the index. If your index is empty and you commit, you get the same behavior as today. None of these strike me as in conflict with Fossil principles. Not necessarily the principals, but they would, by and large, require new infrastructure which would be added for the sole sake of 100% fidelity with git, so that Fossil can be used as a git backup/recovery system when git suffers an untimely power outage. That way lies madness. Forget the backup/restore -- that's a different problem set. We're now on the subject of about allowing me to get the workflows I use with git, but with Fossil instead, and with minimal changes to Fossil. Give me the bare primitives I need, and I can build the rest as external components. Nico -- ___ 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 horror story post.
On Sun, Jun 1, 2014 at 5:56 AM, Dömötör Gulyás dognot...@gmail.com wrote: On 1 June 2014 06:43, B Harder brad.har...@gmail.com wrote: http://mikegerwitz.com/papers/git-horror-story An interesting scenario, what is there to be learned from it for fossil? Since fossil doesn't like history rewrites, are we protected to some degree from falsified commits? (I ask as I have not yed had the opportunity to look into fossil's security features extensively) No, this isn't about rewrites, and the blog author specifically addresses that, pointing out that a history rewrite upstream would be noticed by downstream clones. (Also, upstreams are usually configured to reject history rewrites.) This is about compromise of either a local account (where a commit is authored) or a pusher's credentials. Cryptographic signatures help in the latter case, but not at all in the former case. The blog post is all about use of cryptographic signatures, not about protecting against local compromises, nor about any failures of git's. The issue of local and/or pusher credential compromises isn't specific to git. It can't be, for obvious reasons. The blog is specifically about signing commits when using git, not about a failure of git's. All VCSes are equally vulnerable to such compromises, and commit signing addresses only the case of pusher credential compromise, and even then, only if the workflows include validating all commit signatures. Much can be done without signing individual commits anyways, so I'm not sure that I'd recommend only a workflow involving commit signing and verification. Nico -- ___ 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] libfossil www interface: looking for ideas
On Mon, Feb 17, 2014 at 4:26 PM, Stephan Beal sgb...@googlemail.com wrote: In which case I'd strongly urge that the best option here is to pick a third party servlet engine based on its own criteria rather than inventing yet another one --- they're harder than they look and there are too many as it is! (Particularly if you want something session-based; sessions are surprisingly hard to get right.) Can you recommend one in C? i'm self-imposed bound to C here. i might be convinced to write it in C++. If you look aroung in http://github.com/stedolan you'll find a minimal http server, with much of the code you need for building something like this. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scalability limits
On Fri, Feb 7, 2014 at 11:40 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Feb 7, 2014 at 6:15 PM, Ron Wilson ronw.m...@gmail.com wrote: I am guessing this is a limitation of SQLite, which is designed to be light. It would be interesting to see how Fossil would perform when plugged in to, for example, PostgreSQL, MariaSQL or other heavy duty SQL server. Of course, that could require rewriting a lot of SQL queries. When starting on libfossil i actually looked into that and decided against it primarily because so much of the heavy lifting (and a lot of the lighter work) in fossil is done by sqlite, and it would be a tremendous effort to port that SQL logic either to C code or another SQL dialect. The fossil core [...] One of the nice things about all the features that SQLite3 has been growing lately (CTEs, recursive queries, before that recursive triggers, foreign keys, ...) is that the more business logic that can be expressed declaratively and therefore pushed into SQL, the less complexity one has to have in C, Python, ... That makes it much easier to cope with future schema changes, or dataset changes that require re-planning queries (the RDBMS can do it!). And all those new features are great for expressing complex business logic (particularly CTEs). Sticking to a portable subset of SQL, on the other hand, makes it easier to scale up and down the device stack, dataset sizes, and across the network. Which makes improvements in the lowest common denominator very welcome! Now, if only PostgreSQL (and others) had a duck-type option to match (roughly) SQLite3's duck typing... That would bring the lowest common denominator up to a very useful level. Nico -- ___ 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 Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it doesn't. If you're using multiple copies of libsqlite3 to access the same DB file in the same process concurrently then you'll get corruption. In practice this just doesn't happen, but it's important to be on the lookout for this. Consider how that might happen by accident (as opposed to just for demonstration purposes). I imagine a plugin API for some library (think PAM) with multiple plugins... wanting to access the same DB -- or maybe the DB is the interface. That wouldn't happen, one hopes, and by and large it doesn't. Now imagine [wu]tmpx being replaced with a SQLite3 DB file... If [wu]tmpx were accessed using an in-process libsqlite3 and the library providing the [wu]tmpx functionality were itself available for static linking (or if the DB *were* the interface) *then* we'd have a situation ripe for this accident. But one could foresee this problem (hopefully) and act to head it off [various designs elided]. More generally, trying to ensure that a) there's only one copy of every library in the distro/OS, b) all version dependencies match up, is *super* hard, if not impossible. Eventually there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions, but first the distro maintainer ought to make sure that the POSIX file locking disaster you mention can't happen as a result. It's fortunate, for example, that OpenSSL doesn't use POSIX file locking at all. Imagine it using SQLite3 for an OCSP response, CRL, and other caching! It's not such a stretch. Heimdal has an option to use SQLite3 for Kerberos ticket caching, and when used this happens in a library, which is itself used from a pluggable API (GSS) that is used in various operating system moving parts (e.g., LDAP). The problem with POSIX file locking and something like SQLite3 is that it's easy for all the pieces of such an accident to come to exist... by accident. The problem is that POSIX file locking is insane. Nico -- ___ 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 Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 8:50 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. [...] Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it does not. But what does that have to do with static vs. dynamic linkage? Pluggable interfaces + layered software. A perfect example would be nscd (the name service cache daemon), which is pluggable (see the nsswitch.conf man page). One or more plugins might need to share some common resource (e.g., Kerberos ticket caches). If that resource is a SQLite3 DB file... and if each plugin statically links with libsqlite3... and if the nsswitch dlopen()s those plugins... then bad things may happen. Things like the nsswitch generally support loading plugins at run-time, via dlopen(). There's quite a few such plugin interfaces: PAM, nsswitch, SASL, GSS, and probably many more. All it takes is for a confluence of design events to bring two SQLite3s (or other library that uses POSIX file locking) into the same process via such plugin interfaces, locking around the same files. With respect to SQLite3 the simplest thing for you to do is to advise people to... not do that. I.e., what you're already doing. The obvious workaround for anyone wanting to use SQLite3 for things like the examples I gave is to use IPC, having a separate process just for this purpose serving access to the DB. Nico -- ___ 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] Code review (reloaded)
On Tue, May 28, 2013 at 10:25 AM, Richard Hipp d...@sqlite.org wrote: If you forget to do it then, you can always visit a check-in after it is committed and click on the Edit link to do things like revise the check-in comment, update the check-in time, or move the check-in to a different branch (such as experimental or pending-review or mistake). Sometimes somebody will check-in a change to trunk that I don't agree with. When that happens, I just move their check-in off into a branch. Hmm, wait, isn't that re-writing history? I'd expect that instead you'd commit a backout commit (that undoes the changes from the undesirable commit) and possibly cherry-pick the undesirable commit onto a different (likely new) branch. In particular, isn't this a breaking change for downstream clones of the trunk? A tangent: Note that when you edit a check-in, you are not really changing the check-in. You are, instead, adding additional information. Fossil does not erase or modify, it only augments. The original check-in comment, and time, and branch are all still there for anybody to see. By 'editing' the commit, you are adding a new record to the repository that says for display purposes, modify checking XYZ as follows... OK, so editing the check-in is not history re-writing, but what about the moving part? Are you merely creating a new branch headed by that check-in and then resetting trunk to point to a line of check-ins that excludes the bad one? If so, isn't that still a breaking change to trunk? Or did you mean something more like checking-in a backout check-in? Notes also that Fossil allows you to start a new branch named (for example) experimental even if there already exists one or more other branches with the same name. At http://www.fossil-scm.org/fossil/timeline?n=200r=experimental it looks like there are a dozen or more experimental branches currently in the Fossil tree. How does one tell one apart from another? Nico -- ___ 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] Chiselapp.com shutting down
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp d...@sqlite.org wrote: Suppose I did write my own hosting system. What is is required for that. (James, you have the most experience with this question, so your input is especially encouraged!) (1) Some means for people to create accounts There are many schemes. BTW, you should consider Mozilla's BrowserID authentication scheme. (2) Some means for people to upload Fossil repositories to hosted Create empty repos and then push to them. (3) Per-account bandwidth tracking? Would you charge for bandwidth? If not don't bother tracking it. (4) Require advertising (example http://system.data.sqlite.org/) for unpaid accounts? Sure. (5) Require unpaid accounts to be open-source? Other repo hosting sites tend to charge according to how many private repos you have. You could offer 1-3 private repos for free + a size limit on the repos, then charge for anything beyond that. (6) Some mechanism to accept payment for private or add-free accounts? Yes, if you'll charge at all. (7) Procedures to deal with DMCA takedown requests? Speak to a lawyer about that. What else is needed? James, what are your bandwidth, cpu, and disk space requirements? (You can send me that via private email if you prefer.) Egor Homakov had a great blog post[0] about the need to have separate origins for the domain where users login to manage their data, and the domains where user pages can be viewed. I.e., using chiselapp.com as an example, you need two domains: chiselapp.com and chiselapppages.com, with the former hosting only the fossil services and any additional web interfaces, and the latter hosting the web view of user fossil repos. [0] http://homakov.blogspot.com/2013/03/hacking-github-with-webkit.html Nico -- ___ 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] Chiselapp.com shutting down
On Fri, Mar 29, 2013 at 6:55 AM, Richard Hipp d...@sqlite.org wrote: What else is needed? You'll also need: - user and repo mgmt interfaces If you grow you'll want a search facility (search multiple repos), edit via browser UIs, ... Like github, basically. Nico -- ___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere. ___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 3:28 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking These we warned you about at the start of this thread - they are platform-specific limitations which we can do nothing to get rid of. Wel, you could use getenv(USER) and LOGNAME instead of getpwuid(), or fork/exec/spawn id(1) to get the username. And you could use a DNS library to resolve the hostname without the benefit of local caching (unless there's a local caching server). The bigger problem is that this is something you'd risk having to do again and again every time something else in glibc ends up needing dlopen(). It's a losing battle, and even if it isn't (maybe nothing else in glibc will ever need dlopen()), philosophically it is a losing battle. So you have to build an executable per-distro -- welcome to Linux. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Initial patch towards rebase
https://chiselapp.com/user/nico/repository/nico Two branches: rebase, and test-rebase. This adds a --nocommit option to the fossil merge command that does... what it sounds like it does: it applies the patch from a --cherrypick commit and leaves that uncommitted. I applied all the commits from my rebase branch onto my test-rebase branch, each time using --cherrypick and --nocommit, then did a single commit at the end, and the result is that src/merge.c in both branches has the same contents. (www/index.wiki doesn't, and I suspect this is due to fossil automerging silently, which I wish it wouldn't do). An actual, interactive rebase facility like git's can be constructed on top of this, though some things, like interactive patch chunk selection/editing, will require more work here. Cheers, Nico -- ___ 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 Jan 3, 2013 12:13 PM, Richard Hipp drh d...@sqlite.org@d...@sqlite.org sqlite.org d...@sqlite.org wrote: On Thu, Jan 3, 2013 at 12:08 PM, Alaric Snell-Pym alaricala...@snell-pym.org.uk @snell- ala...@snell-pym.org.ukpym.org.uk ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2012 09:33 AM, Nico Williams wrote: I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). That reminds me of a discussion I had with a dyed-in-the-wool git fan, of the make the history beautiful camp, who was a fan of making lots of tiny commits during development but then squashing them into a single neat patch to go onto the trunk. I was nervous about the history-loss this created, and one idea that I suggested as a compromise between our positions was a special kind of merge commit in the history that looked like a single commit containing the entire branch as a single patch in the UI, rather than like a merge of the topic branch containing the work. This would appear like rebasing the topic branch and squashing all the commits, but was actually just a merge in all respects other than how it looked in the timeline. Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. The changes might need to be logically broken up into several commits. So rather than squash everything into one commit the recipe might need to be more involved. For example, in developing the commits on that branch for some feature i might also have fixed bugs that need to be fixed separately upstream so that they can get cherry-picked onto branches for older release maintenance. Nico -- ___ 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] Diff of renamed (and edited) files
There used to be a VCS called PRCS. It had no network support, but aside from that it was awesome, partly because every file was assigned an mnode, which was roughly an analog of inode numbers, and this allowed wonderful rename functionality. The same approach might work equally well for Fossil. Nico -- ___ 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] Diff of renamed (and edited) files
You could just compute throw away mnodes and just cache that. Fossil already has a cache, no? ___ 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.?
[Sorry to break threading, but I unsubscribed, then saw this in the archives and re-subscribed just to answer, but I don't have the Message-ID.] On Sun, Dec 30, 2012, Joerg Sonnenberger wrote: On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote: I repeat: git rebase does not manipulate the pre-existing tree, it does not destroy any history already in the tree. The only destructive action that git rebase does is change the commit that a branch _name_ points to, and from a fossil philosophy perspective this is the only aspect of git rebase that is worth differing on. git rebase is destructive due to a combination of not supporting more than one leave revision for a given named tag and dropping all other revisions on a non-fastforward push. Now a combination of recording what a rebase is based on and just marking the original commit as closed would pretty much serve the purpose of fossil. I'm very glad you mentioned this. I really would like git rebase (and any equivalents in other VCSes) to add an empty commit whose message contains: the old base commit hash, the new base commit has, and the rebase recipe (i.e., the pick/squash/fixup/edit/... instructions, including the commit hashes of dropped commits). Also, I'd like to be able to ask about previous rebasings of a given branch and be able to name them, something like branchname%N, where N is the Nth previous rebasing. This way I could checkout, diff, ... old versions of a branch. And then there'd be no need to create a copy of the victim branch prior to rebasing. This alternative to my first proposal strikes me as particularly useful. Thank you for mentioning it. Nico -- ___ 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 Sun, Dec 30, 2012 at 9:41 PM, Mike Meyer m...@mired.org wrote: 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. I unsubscribed. I resubscribed to answer Joerg's very useful comment, and to address your insinuation that I've been trolling: If I had written a ten-page post explaining in excruciating detail [...] 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. I was going to let you have the last word, and, indeed, I will since I will re-unsubscribe shortly. But I feel I must at least address this insinuation that I was trolling. I think any reasonable human being reviewing this thread will conclude that I've been sincere. I've explained in detail, and I've answered the questions that have been raised, such as here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html and here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html I think those two posts in particular are quite detailed and informative. Nor did I know that bringing up rebase would arouse fury. I knew it was controversial, but not that it was anathema, and I thought I could make an argument for a variant of rebase that should fit within the fossil philosophy (and I still think so; e pur si muove). Thus my wading in here could not be considered trolling. If I were to not give up I might be trolling, but trust me, I give up (unless we hear from the project's principals anything supportive, or if they ask questions that I should answer). Trust me, I feel awful about filling unknown subscribers inboxes with my responses on this thread, and the responses those have elicited. I have found your responses to me to be hostile, and downright silly. I've also briefly reviewed the rm/mv thread and I find similar silliness there by various members of the community. I am frustrated, and I acknowledge that I've am having trouble hiding my frustration. But I do think that you have shown an utter lack of hospitality and open-mindedness. This is why I will now abandon Fossil, even though there are many ways in which I think Fossil is superior to the competition -- your hostility turns me off. 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. These two posts: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10591.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10593.html answer your questions and explain in detail what I need to be able to do and why. Perhaps you missed them. You did respond once with this: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg10602.html but you failed at reading comprehension, and by then I was ready to give up. But let me answer the one question you raise there: | 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? *git* rebase destructively affects ONE branch by making that one branch name point to a new line of commits that are not fast-forwards from the previous commit pointed to by that branch name. The rebase operation does additionally involve (read-only) an old base and new base commits. So, yes, rebase works on one branch. Rebase as a general
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Mon, Dec 31, 2012 at 12:01 PM, Steve Havelka yo...@q7.com wrote: On 12/31/2012 06:21 AM, Jan Danielsson 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. I agree with Jan. I also think this thread and the mv/rm hostility suggest a change in tone for the mailing list which is more than a little embarrassing. I'm sorry you felt compelled to unsubscribe, Nico. I haven't yet re-unsubscribed. Joerg's note added hope that more participants might add something of value. And your and Jan's note provide much appreciated relief: I'm not alone in finding Mike's hostility needs calling out. Thanks! Nico -- ___ 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.?
Thanks Mike, I appreciate this. BTW, I now have a pretty good idea of what fossil rebase would look like; the discussion was a success, largely thanks to Joerg's insight. I've also started looking at src/merge.c to have an idea of how to implement a version of fossil merge --cherrypick that doesn't commit the merged changes (this being necessary to implement the interactive rebase edit-a-commit option, as well as for squashing) -- this is the essential ingredient, after all, and it seems like all that has to happen is we need an option to not update any non-temp tables in merge_cmd(). I think that will be a trivial change, actually, as it'd be a small modification to the fossil merge --nochange logic. I'll stop here. In six months I may have time to actually implement, and in the meantime I'll sketch an implementation. Happy New Year! ___ 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 Sun, Dec 30, 2012 at 7:58 AM, Eric e...@deptj.eu wrote: On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: snip 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. So perhaps all we need is a streamlined way to do multiple cherry-picks (which may even end up with a similar feel to git rebase --interactive). That's the essense of rebase. Glad we agree. Whatever we do we can't call it rebase, because people will then assume that it is just like git rebase, and it won't be because it must not manipulate the pre-existing tree. If you don't believe that the I repeat: git rebase does not manipulate the pre-existing tree, it does not destroy any history already in the tree. The only destructive action that git rebase does is change the commit that a branch _name_ points to, and from a fossil philosophy perspective this is the only aspect of git rebase that is worth differing on. name matters, just read the why does `fossil rm' not do the real thing? thread. Gratuitous terminology differences only burden users. Calling this something else will only placate the anti-git police. Now for a few more general comments (30 messages overnight!!): Depressing, I know. Because upstream wants it is not necessarily a good reason. Upstream can be just as misguided as downstream. Also they should not be making requests that are difficult in their VCS of choice, and likely workflows should have been part of the process of choosing a VCS. Sometimes you don't get to argue with upstream. It's either their way or the highway. But I've also explained in much detail why upstream actually *is* justified in asking for contributions to be nicely organized as a linear sequence of properly ordered commits that applies cleanly to the upstream trunk and where each commit stands alone, etcetera. As for making requests that are difficult in the VCS of their choice... I agree entirely. And that is why Fossil (as it is) cannot be considered for the large projects I've worked with. That commits should do only one thing is a sensible idea (whether the one thing is a one line bug fix or a major feature implementation), but this is about project policy, and developers should work in such a way as to be able to achieve it. You can do it in Fossil, and if something you have to do to achieve it takes too long, then write, design, or ask for functionality to streamline it (in that order of preference!). Agreed. I should show up with code in hand. I just did that for a different open source community (LyX), and I wish I could do it for this one. But I'm out of time for the next six months. What if I had intended response to that 3-paragraph initial post to help me gauge interest levels in a possible contribution of fossil rebase functionality? Why should I spend valuable time and effort on a contribution that will be rejected? The contribution I made to lyx-devel last week was one I weighed carefully through an earlier discussion on lyx-users. Your (that's general your) hospitality, or lack thereof, matters. This goes for me too: obviously I've allowed frustration to show, and this is bad since it only heightens hostility, and for this I'm sorry. One of the things that people seems to miss is that if you are working on several things in parallel (say a nearly finished feature, a feature in early exploration, and a few bugs some of which are on different branches) you should really be doing each in a separate working directory based on the same repository. This is easy in Fossil, and is possible in git (or even CVS!). You will of course have to do various merges, but everything will be fairly clean, and you won't even need stash! I never git stash -- it's a git feature I've yet to internalize (and you all thought I was a git zealot! ha). I generally commit everything, even work in progress, then switch to another branch, then back, and eventually I rebase to squash the work-in-progress commits if need be. Upstream will always have to do some merges! The upstreams I've worked with only ever accept merge-free (fast-forward, in git terms) commits. Occasionally one has such a large project to contribute that it's difficult to ensure that no other commits will slip in while one is updating the project to the trunk, in which case the upstream should lock the upstream so that no commits can be pushed until the project's
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Sat, Dec 29, 2012 at 8:53 AM, Eric e...@deptj.eu wrote: On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote: snip Actually I agree with most of Mike Meyer's reply, but I wanted to pick this paragraph apart: How many times have you submitted a patch to an upstream Well, phrasing it like that says that you are thinking git-style anyway. Let's assume a Fossil push with one commit nominated as this is my current contribution. and then been told to make a bunch of changes, That's only to be expected, so you create a new commit based on your previous nominated one, push it and tell them which is your new commit. re-organize your commits, I don't see why they (the centre) should do that. It's the result that matters, and if they want a pristine tree that includes only approved commits they can do that. (See below.) It matters a great deal. Let's say you submit a patch for the main branch and the maintainers of an older release branch want to pull your patch in for a micro release of that older release. If your patches are broken up into suitable pieces then the maintainers might pull some of your commits (e.g., bug fixes) but not others (e.g., riskier ones, features). But if your commits were badly organized then the maintainers will have to copy/paste or apply chunks of patches -- very manual, risky processes. To me what you say indicates that you have very little experience with *large* projects. I've worked on quite a few large projects. I'd drop names, but to what end. The key is this *happens*. A lot. And it's not just because the VCS supports rebase: I've had to do rebasing with VCSes that don't have explicit support for it, because if that's what the upstream wants, then that's what the upstream gets (or nothing at all, but what if your job -that you're paid for- is to contribute to that upstream?). make specific changes to specific commits, Why, why, why? It's the result that matters, this is just rewriting _your_ history because they feel like it. Because that history is of a PRIVATE branch. PRIVATE. And the way I do it (go look at my github repos) is that I rebase brand new *copies* of the branch in question, so I never actually rewrite any history. (I thought I'd explained this. Hadn't I?) and/or squash commits? Again, this is about them wanting a pristine tree. Their problem. Or my problem: I want my fixes in. Or maybe I get paid to contribute to them. Nico -- ___ 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:20 AM, Lluís Batlle i Rossell vi...@viric.name wrote: (top post, due to the complexity of the previous post) I've found many git-fans that are completely ashamed of how they develop. And they would never make public how they commit things (how they use the VCS), so they don't accept other VCS that hasn't git rebasing capabilities. If yoiu manage a *large* project, something on the order of OS/Net (the core of Solaris), say, then you need a clean tree for various reasons: - so maintenance of older releases is easier The maintainers of older releases can pull and merge specific fixes for specific bugs from the next-release branch. Without clean trees this is a disaster: you've lost organization of history, thus finding specific fixes -complete sets of commits for them- is often then as hard as just re-doing the work of fixing the bug in the first place. - to make it easier for *other* developers to find what happened later, when you're no longer around to ask questions of, or when you've forgotten the details. - to make it easier for reviewers to understand just what the heck your patches are about (this one fixes this one bug, that one adds this minor feature, ...) And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Project repos? Let them have whatever ugly, dirty history. Official repos? No way. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. That's my last word on this for a while. Take. Or leave it. Nico -- ___ 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 5:01 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote: And so on. Really. Large projects need order, they need process. They need clean trees in official repos. Without a way to clean history prior to pushing to / pulling into official repos a VCS is just hard to use effectively. I'm not against that; I understand that teams of projects want to organize what their VCS history looks like. What I meant is that (by now) git has only one way of providing such clean trees: destroying the history. That's a strawman. I very specifically suggested that a fossil rebase operation should *always* copy the branch being rebased and then rebase that copy. Now what on Earth could possibly be objectionable about that? Nico -- ___ 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 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: | 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 have to wonder how so many people missed it. My guess: those who missed it really can't get past the idea that git's rebase is destructive, therefore nothing even remotely like it can be considered, even if it explicitly prevents destruction. But that's not much of an excuse: that was a total of three short paragraphs you could have read before launching into a massive sub-thread. Perhaps we need a word for non-destructive (copying) rebase that -being a different word- fails to arouse such [misplaced] ire. Nico -- ___ 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 5:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: Ah sorry, I was only talking about my objections against git rebase. I don't know the best way to implement a feature that allows creating 'new history' at will (not destroying the old). All I can imagine sounds like a lot of work. :) The basic machinery (cherry-pick) is there. The main piece is the interactive rebase, which is really popping the user into $EDITOR to select the order of various operations, and which those are. So there's a) code to select commits, code to format that into a file the user will edit, spawn $EDITOR, then parse the result, then execute it. The execution part requires keeping state and is a bit tricky. The hardest part, I think would be anything like git add -p. ___ 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:29 PM, Mike Meyer m...@mired.org wrote: Nico Williams n...@cryptonector.com wrote: 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. In git, the rebase command rebases only the current branch. There's one or two other things to specify: upstream and, optionally, newbase, but these two need not be branch names. 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 user) with the rebased contents, leaving the original alone. The new branch should get checked out too (for obvious reasons, as the process of rebasing needs interim points checked out, and anyways, the user is likely to want the new branch checked out. 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. It produces a different set of commits to be sent upstream than I had before the rebase -- that's a change to the tree, though, really, it's a new branch. In git the branch name is then changed to point to the new line of commits, and this change is what we all consider destructive. That you've not experienced this says nothing about the reality of it. For me the lack of rebase in any VCS is near fatal -- it's generally possible to obtain the same effect, even with fossil, but at the cost of much manual labor or much labor spent automating rebase tasks (never as well as git rebase does it anyways). 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 it has documentation I can refer to. I don't want to copy that documentation nor find a way of expressing the same concepts differently -- that would be a waste of my time and would confuse all those users who know what git rebase is. I'd much rather instead offer a description as incremental change to git rebase. Given these command-line synopses from the git-rebase manpage: git rebase [-i | --interactive] [options] [--onto newbase] upstream [branch] git rebase [-i | --interactive] [options] --onto newbase --root [branch] my proposal is for: fossil rebase [-i | --interactive] [options] [--new newbranch] [--onto newbase] upstream [branch] fossil rebase [-i | --interactive] [options] [--new newbranch] --onto newbase --root [branch] if newbranch is not given then newbranch would be derived from the selected branch (or current) by adding a suffix -1 or by incrementing the number if branch ends in -number. Nico -- ___ 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:49 PM, Michael Richter ttmrich...@gmail.com wrote: I'm pretty sure that rebase or its equivalents will never be a part of Fossil. Given that there are tools out there (like Git) that feature this functionality that some (and I stress it's only some) users want, perhaps this following question is to practical but … why not use Git, the tool that has the feature you want? This arguing over whether rebase is good or bad and whether you're a good or bad person for wanting it is futile. I'm pretty damned sure that it's not going to ever be added (given Richard Hipp's philosophical stance on rewriting repository history). 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 shall wait for D. Richard Hipp's word as to any kind of rebase never making it into Fossil. TL;DR version: stop whining and use Git if you want Git. You fail reading comprehension. I do use git, nearly exclusively. And I use rebase. And I use it in a way that is non-destructive (because I always rebase fresh branches that are copies of the ones I want to rebase). I happen to think that Fossil has a superior architecture and design. I'd like to use Fossil, but I can't, and I've explained why. I've also explained why I'm unlikely to be the only user who needs this one feature. Nico -- ___ 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 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: A rebase operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since oldbase then b) creates a new line of commits that consists of newbase plus the commit set computed in (a), each commit in that set applied as a delta onto newbase, merging as needed. So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. In *git* this is a destructive operation because the new-feature branch's HEAD is made to be c', which is not a linear history from c. But if the rebase operation creates a new branch whose HEAD points to c' then there's nothing destructive. Other things that can be redone in a rebase would include: A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) A---B---C---D---a'---c' (drop a commit, not merely change the base of a) A---B---C---D---abc' (merge all three of a, b, and c, into abc') A---B---C---D---ac'---b' (re-order and merge some) A---B---C---D---a1'---a2'---b'---c' (split a and rebase) A---B---C---abc' (no rebase, just merge the top three commits) These are things that upstream maintainers of large projects quite often insist upon. Nico -- ___ 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 11:33 PM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 13:23, Nico Williams n...@cryptonector.com wrote: A rebase operation takes a branch (typically the current one) and two commits (oldbase and newbase) in the repository and then a) computes the set of commits that are in the branch since oldbase then b) creates a new line of commits that consists of newbase plus the commit set computed in (a), each commit in that set applied as a delta onto newbase, merging as needed. And why would I want to do this? Explain as you would to, say, a small child. Short version: because upstream tells you to. Longer version: first because upstream wants patches that apply cleanly, but if you don't have commit D in the new-feature branch and your commits a, b, and/or c require merging with D, then the upstream will tell you to update your patches (it's *your* job to do such merges), second because upstream may want you to re-organize your work (as I've explained before; no need to repeat). So, if we have a branch called trunk with this history: A---B---C---D and a branch called new-feature with these commits A---B---C---a---b---c where commits a, b, and c are in the new-feature branch but not in trunk, and clearly we're missing commit D from trunk in new-feature, we want to end up with: A---B---C---D---a'---b'---c' Where a', b', and c' are each based on commits a, b, and c, but merged onto D. Why not, for example, just merge c into D or vice versa? I really don't see what modifying history does here. Possibly because I lack the imagination to put any concrete examples into A, B, C, D, a, b, c, a', b', c' where this would be a desirable feature. Could you be more specific? Because D is already upstream, therefore to remove D from upstream would be a destructive operation. The goal is to produce new commits that apply cleanly to trunk upstream. Again, if I send a, b, and c upstream and D was missing in my branch then my commits may not apply cleanly. Even if they do the commit hashes will change as in the upstream the parent of a will be D, not C. A---B---C---D---a'---c'---b' (re-order commits, not merely change the base of commit a) Why? Because upstream may ask for it. For example, if I wrote a test first, committed it, then a bug fix -- my mistake, but I should have done it the other way around (though I might not have known the upstream maintainer's order preferences upfront). A---B---C---D---a'---c' (drop a commit, not merely change the base of a) Why? Because it turns out that commit b was lame. Or because upstream decided to reject commit b but commits a and c still stood on their own. A---B---C---D---abc' (merge all three of a, b, and c, into abc') Why? Because upstream thought these three belong as one. (E.g., b might fix a bug introduced by a, and c might fix a typo in b.) A---B---C---D---ac'---b' (re-order and merge some) Why? Commit c might fix a typo in commit a, while commit b might be unrelated. Squashing (git term) c into a then helps keep history clean upstream. Upstream likes clean history in official repos. A---B---C---D---a1'---a2'---b'---c' (split a and rebase) Why? Because commit a did two separable things and upstream wants them separated so that, for example, a1' can be pulled into an older release's bugfix branch without pulling in a2'. A---B---C---abc' (no rebase, just merge the top three commits) Why? Here I'm not contributing abc' just yet. I'm still working but I know upstream wants commits a, b, and c merged. Eventually I'll have to rebase onto D, but I want to do that later. These are things that upstream maintainers of large projects quite often insist upon. And why do they do this? I kinda/sorta get the mechanism. I just don't see the motivation. (And upstream maintainers insist upon this is not motivation, it's just moving the question of motivation around.) Because they want clean history. If commit b fixes a bug introduced by commit a then why should that bug -which had never been upstream to begin with- exist upstream in the middle of the history? Not only is there no reason to want that upstream, but having it upstream will only add to the burden of someone reviewing the history to understand it or specific changes in it. Nico -- ___ 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 Sun, Dec 30, 2012 at 12:09 AM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 14:00, Nico Williams n...@cryptonector.com wrote: Because they want clean history. This is precisely why I maintain that you're not going to see a rebase in Fossil. Quoting from http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01792.html: There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second. There's room for interpretation, and for persuasion. Clearly the history in an official repo must reflect what happened. But the history I choose to present in a contribution is entirely in my hands to decide how it looks (and the upstream may impose their own requirements). If it wasn't in the official repos, did it happen? Fossil didn't always have private branched. It does now. Isn't that a concession that sets precedent? At Sun, for example, we had official repos for products (gates), project repos aiming at eventual integration into product gates, and individual repos. Individuals pushed to either project gates or product gates, depending on what they were working on. Product gates were always archived and available, even for ancient releases of the products. Project gates were generally (but not always) archived and available. Individual repos were generally littered across the place, with no real way for one to find them without asking the developer working on them. History was cleaned prior to pushing to gates higher up the hierarchy, but past history in product gates was never rewritten. This worked spectacularly well. Who wants to see typos made and fixed before the commits landed on the product gates?? Answer: no one, because such things are useless and a burden. The room I see for interpretation and/or persuasion lies in that not all history is equally valuable. Nico -- ___ 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 Sun, Dec 30, 2012 at 12:19 AM, Nico Williams n...@cryptonector.com wrote: There's room for interpretation, and for persuasion. That's one of the things that happen when we build religions: heresy. Is this heresy? You can't say. Maybe not even D. Richard Hipp can say. Unless I'm willing to fork fossil and do it my way (I'm not) and if D. Richard Hipp declares this heresy, then it's all academic. I would recommend a less religious approach though. Our thinking on technical matters evolves. Mine does. I hope yours does too. This isn't *real* religion. There's no moral principles at stake. Society is not at risk, not from this argument anyways. ___ 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 Sun, Dec 30, 2012 at 12:40 AM, Michael Richter ttmrich...@gmail.com wrote: On 30 December 2012 14:19, Nico Williams n...@cryptonector.com wrote: There are differing philosophies here. Some say it is important to present a clean, linear narrative of what took place - a narrative that is easy to follow and easy to understand. Others say that it is more important to present history as it actually occurred, in all its messy detail, not how you wish it had occurred. Git and Hg tend more toward the first view whereas Fossil leans toward the second. There's room for interpretation, and for persuasion. Not really, no. Any interpretation that says anything other than it is more important to present history as it actually occurred isn't interpretation, it's dissembling. But you're coming around, check it: Fossil didn't always have private branched. It does now. Isn't that a concession that sets precedent? I'd say the private branches pretty much eliminate your need for rebasing entirely given what you've described as rebasing. Make your mess in your private branches. Expose the pretty stuff in non-private branches. Problem solved. Sure! You came around, see? Except that it's not easy to clean up history in private branches with fossil. You have to manually cherry-pick each commit from one branch onto another in the order that you want. Either splitting or merging commits (forget which) is harder still. git gives you a nice interface for doing this. At Sun, for example, we had official repos for products (gates), project repos aiming at eventual integration into product gates, and individual repos. Individuals pushed to either project gates or product gates, depending on what they were working on. Product gates were always archived and available, even for ancient releases of the products. Project gates were generally (but not always) archived and available. Individual repos were generally littered across the place, with no real way for one to find them without asking the developer working on them. History was cleaned prior to pushing to gates higher up the hierarchy, but past history in product gates was never rewritten. This worked spectacularly well. Who wants to see typos made and fixed before the commits landed on the product gates?? Answer: no one, because such things are useless and a burden. So … have a public-facing clean repository and a private dirty repository with private branches? Again, I don't see what screwing with the Exactly. Nothing awful about that, is there. DAG of the SCM buys you besides trouble. There... is no playing around with the DAG of the SCM. A rebase is just a new branch in this scheme. New branches are hardly playing around with the DAG of the SCM. This is true even in git -- the old commits in the repo don't change, they're not even deleted -- the only thing destructive git does in a rebase is change commit that a branch name points to. So if you want to go from A---B---C---a---b---c to A---B---C---D---ac'---b' you'll find that a, b, and c are still left behind. In fossil there'd be a new branch name to refer to the line of commits headed by b'. In git c is no unreachable, unless there was some other branch or tag referring to it, but c is still in the repo, and if there's no other way to reach it there's always the reflog. You seem to think that git rewrites history. It does not. The only destructive actions in git are: changing what a branch or tag point to, and pruning unreachable commits. And yes, rebasing private branches is easy, except it's a very manual task in fossil, so it's not easy. ___ 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.?
I should also point out that in the Sun model once every one or two bi-weekly mini-releases of the product gates the project gates would have to catch up. Catching up in a way that leaves project commits ahead of the product gate is effectively rebasing, which breaks child gates, which is bad. So what we did is we... created new project branches that got rebased to the upstream and then the child (individual) repos did the moral equivalent of git rebase --onto onto the new project gate branches. Note that history did not get re-written in the project gates: new branches appeared with similar, but different, history to their predecessors, but all stuck around forever. ___ 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.?
Rebase is one of teh killer features of git; the other killer features of git are in Fossil already, but rebase is not. And fossil adds its own killer features: built-in web service, JSON RESTful API, wiki and tickets integrated (and versioned, natch). 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. 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 would love to see rebasing along these lines in fossil. With rebase I could seriously consider leaving git behind, using a fossil-git gateway when contributing to upstreams that use git. Nico -- ___ 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 design error and possible ways to fix it
IMO this should be resolved per-server configuration. Consider the risk of XSS attacks: simply treating all comments as text/plain automatically mitigates any past XSS attack attempts. Granted, XSS attacks are not very likely given that few users can be expected to have commit access... I would prefer that the UI allow the user to select between HTML, wiki, and text/plain, thus allowing for future markup types (e.g., asciidoc); the default (for new comments) should be text/plain. The format of old comments should be given by a server-side configuration parameter. The available formats for new comments should be constrained by a server-side config param. Nico -- ___ 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 as DLL?
IIUC the main reason to want a DLL instead of having to spawn a new process for every operation is iOS. I hear that the dearth of excellent git (and other) SCM clients for iOS has to do with the constrained nature of the run-time environment. ___ 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 10:48 AM, Lluís Batlle i Rossell vi...@viric.name wrote: I think that the git 'rebase' history rewriting could be stated different. Maybe the graph could be altered with fossil cards, the same way commit logs are changed. Then, graph reworking would not imply history rewriting (and thus history loss) as git does. git rebase is one of git's various app killers. And no, rebase need not equal history re-writing. When I rebase I almost always do it in a branch new branch that starts with the same HEAD as the previous one. I use rebase for: - splitting commits - merging commits into one (squash, not three-way merge) - amend commit messages - re-order commits I do such things for either a) cleanup (I want the master branch to be as clean as possible) b) or in response to code review comments from an upstream I'll be contributing commits to Being able to do (b) is critical for some upstreams I contribute to. Since I can't write perfect code the first time I absolutely need rebase. Again, rebase need not be seen as destructive: ideally git rebase should require a new branch name argument and it should make the new branch refer to the rebased contents while leaving the previous branch alone. Nico -- ___ 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] API?
On Fri, Aug 17, 2012 at 7:03 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Is there any kind of RESTful API for accessing Fossil repositories? https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view That's very nice. Thanks! That's about the closest thing there is. It's not REST, but it's REST-ish (JSON-over-(HTTP-or-file). What's not RESTful about it? At first glance I see it uses GET and POST appropriately, not using GET to create things, using POST to create/modify things. It doesn't use DELETE, but then that's because Fossil deletes nothing, right? As for PUT... POST for creating resources seems to be more popular now. That leaves the non-use of HTTP status codes, IIUC. But I do think that HTTP status codes should be used, and it's OK to deliver more application-specific status codes in the response entity. Nico -- ___ 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] API?
On Fri, Aug 17, 2012 at 11:24 PM, Stephan Beal sgb...@googlemail.com wrote: Let's put it this way. To return 200 for a POST that actually failed is very strange -- the response entity had better, at the very least, not be cacheable if you'll do that. Arg, I meant 201 code. i would hope that no POSTs are cacheable :/. If the HTTP POST itself 201s should be cacheable though, since a new entity is returned. ___ 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] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 11:26 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 15, 2012 at 12:22 PM, Nico Williams n...@cryptonector.com wrote: Is there any way to request that the changes from a commit be merged into the workspace but not committed? fossil merge will only merge changes into the local checkout. You always have to do a separate fossil commit to add the merge results back into the repository. --cherrypick does not change this in any way. Ah, so, then the sequence to do a git-like rebase would be to make a list of commits, create a new branch, then for each commit run fossil merge --cherrypick each commit, review changes, fossil commit if desired (or not, if one wants to squash the next commit). Good! How would I get the list of commits that fossil merge D --baseline A would merge in? Point your webbrowser to http://project-domain/project/timeline?from=Ato=D. For example: http://www.sqlite.org/src/timeline?from=1e6f5eato=6954fe Is there any way to do this on the command-line? Nico -- ___ 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] Rebase is NOT fundamentally incompatible with Fossil
On Wed, Aug 15, 2012 at 5:48 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 15, 2012 at 12:03 AM, Nico Williams n...@cryptonector.com wrote: There is a cherrypick command? Oh, it's an option to the fossil merge command. I had missed that entirely! The --cherrypick option has been around for a long time. But formerly, if you did one or more --cherrypick merges into your checkout, then you would not be allowed to commit only some of the changes in your checkout using fossil commit FILE1 FILE2 When you commit just some of the files, we call that a partial commit. The recent change was to drop the restriction on partial commits following a cherry-pick merge. Is there any way to request that the changes from a commit be merged into the workspace but not committed? This would be necessary to implement some of the git interactive rebase options. Note that the merge command also includes the --baseline option. The --baseline option can identify the start of a sequence of checkins that you want to merge. Suppose there are some sequence of changes in another branch A-B-C-D. If you do fossil merge D --baseline A, that would be the equivalent of doing three separate cherry-pick merges of B, C, and D, in that order. How would I get the list of commits that fossil merge D --baseline A would merge in? Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Rebase is NOT fundamentally incompatible with Fossil
Provocative Subject: line, I know. But it's true, git-like rebase is not incompatible with Fossil's principles *provided* that the result of a rebase is a new branch, or provided that the branch being affected has no children (i.e., that it's a private branch). I use git a lot, and I like it. I also like the ideas behind Fossil. I'm only really missing git cherry-pick and git rebase (which is based, really, on cherry-pick). Why rebase? I'd like to give you three example use cases where git cherry-pick and git rebase have been important to me. I hope that there are Fossil-specific alternatives, but if not then I hope that these examples will be useful to the Fossil community. Example #1: Rebasing commits in response to code reviews prior to upstream integration. Upstreams rarely ever want their canonical history polluted by a developer's typical missteps (typos, etcetera). See http://github.com:nicowilliams/krb5/branches, look for branches named kadm5_polic_exts*. Each one of these represents a rebase of another. That is, when I use git rebase I mostly do it in brand new branches so as to not be destructive of the original, even when all these branches are private as in this case. Each rebase was in response to code review comments. Some rebases I did in various sequences, first one to re-organize some commits (e.g., reorder, split, or squash them), then another to fix minor issues. Example #2: Cherry-picking from site-local feature branches onto site-local release branches. One SCM workflow I like involves maintaining sets of local patches to open source projects, with each patchset kept as local feature branches based on upstream release branches. To make a new site-local release from a new upstream release we first create a new site-local release branch for each site-local feature based on the new upstream release, cherry-pick/merge the given feature patches onto the new feature branches, test, then finally merge all the site-local feature branches onto a site-local release branch based on the new upstream release branch. git cherry-pick isn't essential here: git merge would suffice. But the cherry-pick concept allows more control over the merge metadata. Note that these site-local feature branches and site-local release branches are not always shared with the upstream (some hold patches that upstream does not want or which would be obviously of no interest to the upstream community), but they're not necessarily private in the sense of not being shared with other site-local repositories (e.g., developers'). Example #3: Intermediate upstreams (project gates). This example is very much based on how development was done at Sun Microsystems, and in all certainty still is at Oracle in groups acquired via the acquisition of Sun, and is how I do some development today for some customers. In this model we have upstream gates, project gates, and developer repositories. Developers branch off of project gates and push commits to the project gates. Project gates track upstream gates until the projects complete, at which point they push their changes upstream. You can surely see the problem though: as commits from multiple projects get pushed upstream each remaining downstream project gate has to rebase, and that breaks all their further downstream developers. Clearly this is broken. But there's a way to make this work, and we did this at Sun all the time: the rebases are done on new gates based on the old gates. In git this works as follows. First, the root upstream has a single canonical branch (master), the project gates are either branches off the canonical upstream branch, possibly in distinct repos, ditto the developer gates. Second, the project gates rebase periodically, each time creating a *new* branch and closing the previous project gate branch to new commits. Third, developers periodically rebase their branches onto (think of git rebase --onto=...) the new, rebased project gates. At Sun periodically meant specifically that we had build schedules that resulted in build releases, at which point a snapshot branch was created of the upstream root. Thus the periodic rebasing for the project gates was scheduled and the branch names had build numbers in them. One nice aspect of this model is that it allows project and developer gates to keep their commits on top of the upstream base branch: it's always clear what local patches there are relative to the upstream. Note that all these example use cases involve at least two individuals (upstream and downstream), and examples #2 and #3 scale to very large communities (experience at Sun certainly backs this up). That is, these models scale all the way from two individuals to thousands. I would like
Re: [fossil-users] Rebase is NOT fundamentally incompatible with Fossil
On Tue, Aug 14, 2012 at 8:28 PM, Matt Welland estifo...@gmail.com wrote: I like the idea of cherry picking to a new branch. This would have nicely solved a few problems I've faced. I suppose you can kind of do this now using fossil cherrypick and manually creating the new branch but the There is a cherrypick command? Oh, it's an option to the fossil merge command. I had missed that entirely! The changes wiki page mentions something about allowing partial commits of cherrypick merges, but no details are given. How does this work? equivalency to the original edits is not preserved and merging back into a stream with the original edits will probably not work correctly in many cases. Cherry-picking is not destructive like rebase -- commits are only added. There's no need to make a cherry-pick operation create a new branch. The rebase operation is the one that is destructive in such a way that a new branch should be created as a result. As you note, a cherry-pick operation, and in particular one that has an option to leave the picked changes uncommitted, is the only building block necessary to implement rebase. After all, a rebase is just this series of steps: - make a list of commits from the old base to the current tip (or whatever Fossil calls HEAD/tip) - give the user a chance to edit the commit list (for interactive rebases only) - checkout the new base - create a new branch off the new base --- git doesn't do *this* - cherry-pick the commits from the list in the first step, merging as necessary (note that this can require user interaction, and note that the merge and interaction is really part of the cherry-pick operation) Of course, this would be best done in the fossil binary rather than in a script. Still, give me the cherry-pick operation as described above and I can script rebase. I'd give two thumbs up to this idea. Thanks. Anyone else I've failed to offend today? :) (I wasn't trying to offend... I'm really hoping that the idea of a COW rebase is as inoffensive as I think it is.) Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
