On 4/29/2017 7:30 PM, The Tick wrote:
OK, I think I've figured it out!
You're supposed to do a fossil >open< with a version name being
"trunk" (default) or "branch name". When finished, do a fossil close.
You could do it this way, but open and close are more overhead than you
really need.
For most things (and especially for my work on fossil itself) I keep a
single working folder that was originally populated by "fossil open". I
use "fossil update branch-name" to change that folder to a specific
branch where I want to work, and "fossil update trunk" to change to the
trunk. Either way, the next "fossil commit" (without a -branch option)
commits the changes to whatever branch ("trunk" is just the default
branch) the working directory is currently on. (Also, read up on "fossil
bisect" for a command that moves the working folder to a different
revision, effectively allowing a binary search for what version
introduced a bug.)
If I notice that the changes I've made are risky, need further review,
are a mistake, or otherwise belong to a different branch that the
workspace is currently at, "fossil commit --branch new-branch-name"
creates a new branch for the changes I just made. Note that this is
truly a new branch. If the name was previously used, the timeline will
not connect this fragment to any other prior fragments with the same
name. The name "mistake" is used by convention in the fossil project to
be the branch that holds work the turned out to not be useful. Although,
it is a name usually applied by editing an existing checkin to move it
from "trunk" to "mistake" rather than by "fossil checkin --branch mistake".
For some projects where I am maintaining a version already in the hands
of users at the same time as developing new features, I occasionally
open several work folders on different branches. That allows work in
progress to be left partially finished when the urgent phone call comes
in, and for related detritus such as build artifacts to be left alone so
that you don't end up needing to do a complete clean build as punishment
for looking back at a past release just to attempt to reproduce a bug,
and then another clean build when you get back to your ongoing work.
The command I personally never use is "fossil close". It exists at all
for symmetry with "fossil open", and to clean up a database entry in
your master list of open repositories that will be subject to "fossil
all". But I've never found that to be a compelling reason to use it, and
most of the benefits of being able to say "fossil all rebuild" also
disappear if "fossil close" is used too often.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
