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
