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
