Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On 2012-12-18 22:50, j. v. d. hoff wrote: On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer m...@mired.org wrote: well-balanced assessment. On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Well, since no one else has answered publicly, I'll take a stab at it. Fossil has been my goto SCM for over a year now. I use mercurial for things I want to share publicly via GoogleCode (yes, I know about chiselapp, but that's a different discussion). I've used git for client projects for months at a time over the past couple of years, including a week-long project this month. I also have years of experience with subversion, perforce (I am, or was, a PCP), CVS, RCS and a proprietary precursor to perforce. Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? I'd say no. The three are different enough to notice, but whether or not the differences make them a better solution depends more on the organization that's using them than about their fundamental behavior. For example, the major difference is how they handle using rebase to rewrite history. For git, it's a feature. Mercurial provides it as an extension, but the community generally discourages it. Fossil doesn't have it. None of these is universally right, but each is right for some organization. Aside from rebase, the major differences are in things external to their behavior as a SCM, and those tend to be the ones that drive the decision as to which one you want to use if you don't care about rebase. Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work from my recent experience , `autosync' seems to be _the_ feature making the move to DVCS tolerable for some die-hard `svn' users. spaces checked out of the same repository. However, the fossil mail list sees regular though infrequent issues with people who've stumbled over a problem caused by them putting the fossil repo in a work space. could you please elaborate on this? I came to fossil only very recently and, for now, have decided to keep the repo in the checkout directory (just like `hg', say). if I don't won't to have multiple checkouts from the same repo what's potentially bad about this setup? what kind of problems do you have in mind? j. For a single user not having to push/pull merges between multiple work spaces is a win, though you can do that if you want to. For small teams, the self-contained binary means it users fewer resources to deploy if you need a version not in the package manager (or on a system without a package manager). I don't know of anyone using it for a large team. I don't know of any reason not to, except for the risk of being the first to try that. the NetBSD example seems to indicate that fossil's has performance problems for such projects with a massive code base. is this still the state of affairs? not that this would matter for 99.9% of all projects. j. Mercurial: it's strong point is the plugin system. If you need it to do something that's not in the base, there's a good chance there's a plugin that does it. With no extensions, it's a good, vanilla DSCM with a you can't change history philosophy, except for the rollback command that lets you undo the last commit. I use rollback to undo commits that didn't include the right set of files. People regularly show up on the hg users mail list having problems getting it to find the correct versions of all the parts after doing an install or upgrade. Git: I don't like git, because I think mutable history is anathema to what a SCM should be. That said, it's strong point is it's popularity. As a DSCM, what sets it apart is using rebase to rewrite history, and the staging area. The staging area provides the kind of brain fart protection you get from the hg rollback command. On the other hand, I do an empty commit in git because I forgot to set up the staging area far more often than I use the hg rollback command. mike To me, in small projects (1 to 10 persons), the biggest advance of fossil is the use of http, ssh and single binary. If you are in a big company and you need to set up shop then port 80,22 is most of the time open. Asking for firewall changes can be a major problem. Getting access to the scm system can be a major problem to. As to the BSD repositories. I don't think that they represent a normal development work flow. But joerg's work has delivered, important, enhancements to fossil (syncing big repositories) I'm glad he took the time to do that. Better example might be TCL/Tk, sqlite, -- Rene ___ fossil-users mailing list
[fossil-users] Possibility to change commit timestamp?
Hi! I'm wondering whether it is possible via command line (or simple enough SQL) to change the commit time of a specific commit (the most recent one). I have a special need of combining several repositories (non-fossil) into one new fossil repository, maintaining the chronological timeline (at least of trunk, not sure about the branches yet). Therefore I cannot go the git import route but have to build my own xyz2fossil script. The idea is to reconstruct a working copy, made up of the state of the various repositories at a specific time and then do fossil addremove and fossil commit and time-warp the working copy through the time from the past to the present. However with this approach, all commit dates are the ones of the repository conversion and not the original ones. Therefore my question whether there is an easy way to change the commit date directly after the commit. TIA. Greetings, Stefan -- Stefan Bellon ___ 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 Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. It stands in stark contrast to Fossil's everybody has a copy of everything. In almost all the projects I've seen this is realized by another thing that you don't see in the big names: developers autocommit to a central repository. This renders Fossil basically a modern reincarnation of Subversion, what is appealing to a lot of people. As a bonus you get, a little dumbed down, installation of (distributed) Trac for free with every repository. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Wed, Dec 19, 2012 at 12:06:05PM +0100, Remigiusz Modrzejewski wrote: On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. It stands in stark contrast to Fossil's everybody has a copy of everything. In almost all the projects I've seen this is realized by another thing that you don't see in the big names: developers autocommit to a central repository. This renders Fossil basically a modern reincarnation of Subversion, what is appealing to a lot of people. As a bonus you get, a little dumbed down, installation of (distributed) Trac for free with every repository. This is related to having to keep in mind multiple graph HEADs. In fossil, shared with two computers, you have as important references: - computer 1: - checkout - branch head - computer 2 - checkout - branch head But any fossil sync makes branch heads equal in both computers. So, basically, 3 easy points to take into account. In git, you have as important references for two computers: - computer 1 - index - checkout - branch head - remote computer 2 head - computer 2 - index - checkout - branch head - remote computer 1 head There are many commands to propagate from one ref to the other, but I find it very cumbersome (fetch, pull, push, ...). No 'sync' available' to make things easy. Not to mention that it needs also special operations to propagate the 'other' branches to the remote places. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Writing Linux kernel-style commit messages in Fossil
Hello, Is there a way to have Linux kernel-style commit logs display the way they should be in the Fossil web UI? By Linux kernel-style commit logs I mean the way Tim Pope described it below: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html At the moment, multiple-line commit messages show up shortened in Fossil (see http://www.fossil-scm.org/index.html/info/64868f2b98 for an example). What we would like to see is to have only the summary line be displayed on the Timeline page, and to have both the summary line and the rest of the commit message after the blank line show up on the specific commit page instead (when you click on the hash in the Timeline page). If there's no way to currently do so , we'd like to make a feature request for it. Thanks! --Arnel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Safe to build fossil from trunk for production use?
Hello, I see that fossil-scm.org isn't running the release version of fossil. Is that mostly for testing prior to a release or is it safe to build the binary from trunk and use it in production? - Max ___ 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] Safe to build fossil from trunk for production use?
On Wed, Dec 19, 2012 at 11:44 AM, Maxim Khitrov m...@mxcrypt.com wrote: Hello, I see that fossil-scm.org isn't running the release version of fossil. Is that mostly for testing prior to a release or is it safe to build the binary from trunk and use it in production? I routinely rebuild the Fossil on www.fossil-scm.org from trunk and run it. www.sqlite.org is the same server, and hence runs the same Fossil instance. We work really hard to make sure that the trunk is stable. Also, many aspects of safety are designed into Fossil - see http://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for further information. These safety checks have do a good job of containing the bugs so that they cannot corrupt a repository. - Max ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] scrub --private doesn't remove new private branch
Hello, I was trying to remove a private branch from the repository, but the scrub --private command didn't work as expected. The following commands are executed on Windows 7 using fossil 1.24 (renamed to fs): D:\fs clone https://www.fossil-scm.org/ fossil-scm.fossil D:\mkdir fossil-scm D:\cd fossil-scm D:\fs open ..\fossil-scm.fossil D:\fs branch new --private private trunk D:\fs scrub --private Scrubbing the repository will permanently delete information. Changes cannot be undone. Continue (y/N)? y fs: SQLITE_ERROR: no such table: main.delta fs: no such table: main.delta CREATE INDEX IF NOT EXISTS delta_i1 ON delta(srcid); CREATE TABLE IF NOT EXISTS shun( uuid UNIQUE, mtime INTEGER, scom TEXT ); CREATE TABLE IF NOT EXISTS private(rid INTEGER PRIMARY KEY); CREATE TABLE IF NOT EXISTS concealed( hash TEXT PRIMARY KEY, mtime INTEGER, content TEXT ); If you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. D:\fs ui The private branch that I created is still there in the timeline. I'm also not sure what causes the errors about missing tables. Running rebuild doesn't seem to help. Am I doing something wrong? - Max ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Wed, 19 Dec 2012 12:06:05 +0100 Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Dec 18, 2012, at 14:42 , Gilles wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), I was wondering how Fossil compares to them, for a single user, a small team (up to 20-30), and big teams (thousands). http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model Besides the fact that Fossil includes a wiki and a bug tracker, does it offer features that would make it a better solution than the big names? Maybe I missed it skimming the thread, but I didn't notice anyone telling about the big point. There is an attitude difference between Fossil and the other two, which put in database terms would be: Fossil does replication, Git and Mercurial do sharding. A lot of the things you discussed have been touched on, but not this central point: The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. This is a description of workflows, not SCM properties. I've never used that workflow with either git or mercurial (part of my believing that history is sacrosanct). I've pretty much always pushed pulled everything no matter which DSCM I use. In SCM terms, this boils down to fossil not having an easy way to cherry-pick changes to move between repositories. The default push/pull for mercurial is the same as fossil - everything. For git, it's more complicated, but I believe it can be configured so you get the exchange everything behavior if you want it. The bottom line is that if your organization needs fine control over which changes gets exchanged between repositories, fossil isn't for you. At least not yet. It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Dec 19, 2012, at 19:56 , Mike Meyer wrote: The big names have been created for huge teams, where people generally don't want to be overwhelmed by tentative work done by others. Therefore they work in isolation, issuing pull requests once the thing is done. Especially in Git it's popular to compress all the commits to be pulled into one big commit. But the important thing is the isolation. This is a description of workflows, not SCM properties. Of course. But bear in mind that the tools are optimized for certain cases that creators had in mind. Fossil was created for a team of (IIRC) three employees of a single company. Git was created for a fuzzy community of some few thousands people. It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. Private branches are a pretty recent addition. I believe that the fine grained pushing/pulling will also come sooner or later, once one of folks involved with Fossil feels a need for it. Kind regards, Remigiusz Modrzejewski ___ 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 12/19/12 22:57, Remigiusz Modrzejewski wrote: It stands in stark contrast to Fossil's everybody has a copy of everything. Except for private branches. There's been some discussion about adding more control over push/pull to fossil, but I don't believe it's happened yet. Private branches are a pretty recent addition. I believe that the fine grained pushing/pulling will also come sooner or later, once one of folks involved with Fossil feels a need for it. Oh, there's definitely a need for it. Like I have mentioned several times before; the full NetBSD fossil repository is unusable for regular source management work. If one could check out individual branches, then perhaps it would become usable (though that's pure speculation at this point). A while back I did some preliminary work to see how one would implement branch-specific pulls, but before moving along with it I (obviously) asked on the mailing-list to see if anyone else was working on it. And at the time, someone was. And last I heard, there had been some significant progress done, but with a few issues to be resolved. Unfortunately, I haven't seen anything on this for quite a while now, so I get a feeling it was abandoned. And currently I don't have the time to pick it up myself. ..the proper solution would be to look into the scalability issues without looking into limited clones -- but there's also a point in limiting the size of the transfer, so the limited clone feels like a better first try project, since it *definitely* solves one issue, and _may_ solve another one. -- Kind regards, Jan Danielsson ___ 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] Possibility to change commit timestamp?
On Wed, 19 Dec, Stefan Bellon wrote: I'm wondering whether it is possible via command line (or simple enough SQL) to change the commit time of a specific commit (the most recent one). I just found out that the --date-override switch - although only documented for fossil init - also works on fossil commit. As it takes real ISO 8601 date format as argument, that's just exactly what I was looking for. Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
