Re: [fossil-users] New user request
Very glad you like it. On Aug 10, 2013 10:55 PM, Sam Sellars philosopher@gmail.com wrote: Thank you sir! This is exactly the type of thing I am looking for. I appreciate the time you put into this. — Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*. h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each
Re: [fossil-users] New user request
Thank you sir! This is exactly the type of thing I am looking for. I appreciate the time you put into this. — Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each feature as necessary. OK, says your boss, a glob of post it notes trying to break out of their pocket as
Re: [fossil-users] New user request
Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each feature as necessary. OK, says your boss, a glob of post it notes trying to break out of their pocket as they head back to the bosses computer to key in tickets... I could go on (I think I will, later), but I'm tired and I'm wearing a hole in my touch screen. I sure hope this provided some
[fossil-users] New user request
Hello Fossil Users, I'm new to fossil and getting more involved in software development work after a significant break doing non-development IT work. I've started using fossil for some professional work and all my personal projects. I love the design and simplicity of fossil. If a few of you could take the time to summarize your workflow with fossil, from starting a new project in a green field to the first production release, I would highly appreciate it. I know there is not one supreme workflow, I'm just looking for examples. I understand fossil's basics, but the meaning and function of some commands are still illusive to me. I would also like examples of what you do through the project's lifecycle, including the creation of branches (like a test or experimental branch). If you think of any things that confused you or you changed over time, please share that. If you know of a blog post or another write-up that fits this description, please point me to it. Thanks everyone. Regards, Sam ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
