[fossil-users] Crazy request: How to maintain a fossil repo of my iTunes collection?
Hi all, Anyone here using fossil to manage your iTunes collection? Recently I decided to step away from relying on Time Machine (on MacOSX) for backing up my iTunes collection of about 70GB. I want my collection to be stored on two hard disks in sync and with complete history. I use fossil for my personal projects by default, so that first thing that occurred to me was to bundle it into a fossil repo and put it on one hard disk and put a checkout on another. That didn't work, since my files exceed the max blob size that fossil can store. I'm currently using git, which works fine with these files. Should I even be expecting this to work? The nice bit about the fossil file is that periodically, I can just hand it over to Amazon deep freeze cold storage, whereas with git I would need an additional packaging step. Thoughts? Am I crazy? -Kumar ___ 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] Please test the new stash command
Just reporting - so far stash has been fine with my normal usage pattern - where I use stash to save little bits that I may eventually throw out of the repo. (fossil version = This is fossil version [35a3c6] 2010-12-19 02:09:28 UTC) Some missing pieces that I'm sure will soon be filled - 1. fossil help stash not implemented. 2. stash doesn't have a UI. Not important, just convenient to view the stash and the diffs visually. Regards, -Kumar On Sun, Dec 19, 2010 at 6:48 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Dec 18, 2010 at 10:45 PM, Richard Hipp d...@sqlite.org wrote: Please test the stash and let me know about the problems you find. Not really a bug, per se, but an annoyance to long-time fossil users who are set in their ways: step...@ludo:~/cvs/fossil/whio/pfs$ f st f: ambiguous command prefix: st f: use help for more information step...@ludo:~/cvs/fossil/whio/pfs$ f sta f: ambiguous command prefix: sta f: use help for more information step...@ludo:~/cvs/fossil/whio/pfs$ f stat repository: /home/stephan/cvs/fossil/whio.fsl ... (This doesn't need to be changed, i'm just whining.) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
Hi, I'll say a few things since I was one of those who said git stash in a post :) git stash, I think, is not a necessity but a convenience. There is nothing that you can do with git stash that you can't do with branches. Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. One way to look at the git stash is as a private infinite undo tree. Despite the equivalence of actions of the scm systems, my mind thinks differently with git stash vs any step requiring undo. With stash, it is very obvious to me that absolutely nothing is lost, not even temporarily. If there were infinite undo in fossil, thoughts of disaster can be put to rest very easily. However, with only one level of undo, I don't feel comfortable about relying on undo to not lose work. Sometimes I type commands mechanically and so can't recall what exactly fossil undo will do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a I'd never used commit --private, so I just tried it. After the commit, the state of the checkout is the latest code. Whereas after a stash, the state of the checkout is that of the code *before* your changes. So a stash is a commit followed by a checkout of the earlier version. Again .. that stash combines the two steps in one command is a convenience, not a necessity. As for scenario (3), you're right. Fossil doesn't need stash to do this. Regards, -Kumar On Wed, Dec 15, 2010 at 9:09 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. I've been reading up on git-stash to see if Fossil needs a similar feature. So far I don't see the need, since stash doesn't do anything that Fossil doesn't already handle more or less automatically. Please enlighten me if I'm missing something obvious Several cases where the git-stash manpage and other resources recommend using git-stash are shown below, together with how you would do the same thing in Fossil (without a stash). Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a private unpushable branch to store your incomplete change. I don't see how git-stash is any easier than fossil commit -private. In fact, it seems that commit -private is a little easier since it does not require learning a new mechanism (stash versus commit) but rather just a variation on an existing mechanism (commit) which presumably you already know very well. Scenario (3): You start out making changes but later decide that you want to put those changes on a branch, so you git-stash, then git-branch-new to create the new branch, then git-stash-pop, then git-commit. In Fossil, all that extra work is not necessary. You can commit to a branch at any time simply by adding the --branch argument to the fossil commit command line. And, you can even move a check-in that is already committed into a new or different branch using the check-in-edit feature of the fossil ui command. Fossil treats all check-ins as belonging to a single global DAG. Branches are designated using tags, which can be changed and rearranged after-the-fact. Git, on the other hand, appears to keep a separate DAG for each branch, meaning that checkins cannot be so easily move from one branch to another, necessitating tricks like the use of stash. So in summary - Fossil appears to already do everything that git-stash does and do it at least
Re: [fossil-users] How should Fossil handle this merge conflict...
Would that be equivalent to something like git stash? For the same situation in git, I stash my uncommitted local changes before merging in and then pop the stash to resolve any merge conflicts. -Kumar On Tue, Dec 14, 2010 at 3:03 AM, Jeff Rogers dv...@diphi.com wrote: Local edits being lost seems the wrong thing to do, even if they are recoverable with an undo action - undo doesn't always do what I expect, which is probably user error, but since undo is only one level deep st also seems that if they are not recovered immediately, they would be lost forever. What if an implicit check-in was done to any files that would be affected by the merge (whether deleted or merely edited) imediately before the merge? Local edits would then be a fork preserved in the repository, and undo wouldn't actually be undoing anything, but rather reverting to that forked version. -J Richard Hipp wrote: Suppose you have the trunk branch checked out and you have made changes to file xyz.txt locally, but have not checked them in. Then you do a merge of branch other-branch: fossil merge other-branch The file xyz.txt has been deleted in other-branch. What should fossil's response be? Should it retain the locally edited copy of xyz.txt, or should it delete file xyz.txt? If you have not made any local edits to xyz.txt when you do the merge, then Fossil will delete the file. That seems like the right thing to do. But I'm less clear on what the right thing to do is if you have made local edits. Suggestions are appreciated. Please remember that by delete the file you are not really losing any information. Historical versions of the file remain in the repository forever. And even if your local edits are deleted, they can be recovered using fossil undo. ___ 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] A large repo import suceeded!
I've been using fossil for my personal work for a few months now, but never had the chance to try it on a large project. After seeing the new git import feature, I decided to give it a shot and .. whoa! My work git repo is 2.8GB in size. During the first stage of the import, the fossil file went to about 8.4GB, but after the vacuuming, it shrank to the same 2.8GB. Sweet! Some questions - Q1: Rgd git import - my repo has git-svn branch references of the form svnroot/BranchName. These have now been imported into fossil as branches with name BranchName. Is the svnroot/ info preserved somewhere in the repo? Q2: fossil ui is nice. However, I'm missing search - like what git gui gives. What do fossil-ites use for searching the repo? Just straight database search? Cheers, -Kumar ___ 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] A large repo import suceeded!
:D I knew someone would ask that! Its not all source (as if I had to say that). There are some media files tracked as well (images, audio clips and video clips) that are part of the shipping product .. and about 3 years worth history of those. -Kumar On Thu, Dec 2, 2010 at 5:08 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Thu, Dec 02, 2010 at 05:06:03PM +0800, Kumar wrote: My work git repo is 2.8GB in size. During the first stage of the import, the fossil file went to about 8.4GB, but after the vacuuming, it shrank to the same 2.8GB. Sweet! Ok, I gotta ask, what is *in* your repo that it's 2.8 GIGABYTES in size? Is it really 2.8 thousand 1M git repos all screaming to get out? :-) -- Zed A. Shaw http://zedshaw.com/ ___ 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] A large repo import suceeded!
fossil import git fossil import svn fossil import hg And so forth Thoughts? If the format of the input stream can be auto-detected, then it can simply be fossil import can't it? You'll only need to specify format explicitly for the export I think. Q1: Rgd git import - my repo has git-svn branch references of the form svnroot/BranchName. These have now been imported into fossil as branches with name BranchName. Is the svnroot/ info preserved somewhere in the repo? I was not real clear what should be done with those tags, so I stripped off all but the last component of the tag. Is that not the right thing to do? Please explain Oh! In my case, the git branches named BranchName were tracking the branches named svnroot/BranchName and so I didn't have a problem, but in the general case I can imagine a collision if you just use the last term. As long as both branches are pointing to the same commit, there is no collision issue and you can drop one, but if they aren't then it'll help if the full branch name is retained - like svnroot/BranchName itself. So, ok, fossil-git is not an exact inverse of git-fossil. SQLite has a great full-text search engine built in. I've long thought that it would be great to add an interface to this in Fossil. We could index diffs for all check-ins, all wiki, all tickets, all Blog entries, etc, and then have a Google-like interface for searching for things. Of course, the full text index would likely double the size of the repository file, but in this era of TB-size disk drives, is that really an issue? Such a search interface would be awesome! I don't think the size increase is an issue at all. The only case may be backups, but even they can be done using cloning - that would mean that the search index shouldn't sync. Cheers, -Kumar ___ 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] A large repo import suceeded!
David Shinn wrote: Because fossil stores artifacts as zlib compressed deltas, full text searching using the existing fossil SQLite database is not possible. One would either have to create a separate database containing the full set of artifacts or create a program to reconstruct each artifact of the database and do a search on each artifact separately. Does anybody have a better idea? Repo search is really two problems I think - a) Search the artifacts - i.e content - with revision specified. This can be equivalent in cost to checking out a version and running a file grep. b) Searching the commit logs. Maybe only the commit logs can be stored uncompressed (maybe indexed as well) in order to enable some searching. That'll get us search by text/author/date/files-changed. Thots? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
