Very glad you like it.
On Aug 10, 2013 10:55 PM, "Sam Sellars" <[email protected]> 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 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 useful info.
>> Missing (currently) is multi-dev collaboration, hacking on an aeroplane,
>> events, wiki, and more...
>>
>> (Proof reading: "excuse the brevity"... Ha ha. Zzzzzzzzzz.)
>>
>> On Aug 7, 2013 4:34 PM, "Sam" <[email protected]> wrote:
>> >
>> > 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
>> > [email protected]
>> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>> >
>>
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
