On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow <st...@bstage.com> wrote:
>
> On Apr 22, 2016, at 11:34 PM, Ron W <ronw.m...@gmail.com> wrote:
>
> My team's wrapper for Fossil does the following (from memory, so might not
> be exactly right):
>
> On "branch new":
> fossil commit --allow-empty --branch $bname -m "$comment (Issue
> [$issue])"
> fossil tag add --propagate issue $bname $issue
>
> On "commit":
> $issue=`fossil tag ls $revision|perl -n -e 'if /issue=(\w+)/ { print
> $1; }`
> fossil commit -m "$comment (Issue [$issue])" $args
>
>
>
> I have been perusing all the docs all evening, I can’t actually see any
> way to tell fossil which branch to commit to, so there must be some
> implicit behavior here that I am overlooking. I can see that “checkout” is
> the command that checks out a workspace to a given VERSION, which exists on
> either the trunk or some branch.
>
> When you do the
>
> commit —branch
>
> does that change the workspace implicitly to be checked out to that branch
> instead of the trunk? Does the workspace then become tied implicitly to
> the branch unless specifically checked out back to the trunk or another
> branch?
>
Yes.
> and thus a subsequent commit would be to the end of that branch rather
> then the trunk? Am I right to conclude that at this point if the dev
> issues a checkout command again against a VERSION on the trunk, then
> subsequent commits would go to the end of the trunk rather then the branch?
>
> Do I have that about right?
>
> if so, not a big deal then, just have to use wrapper scripts to make sure
> to follow your work flow, always create a new branch on the first commit
> for any ticket. I will probably use a cookie or something to make sure
> while working on a ticket, all commits go to that branch, and tag the
> commit with the [nnnnnnnnnn] number as well.
>
> If they need to work on more than one ticket concurrently, then no big
> deal, create another branch and switch to that one for a while.
>
An even better idea (I think): Have two workspaces. One ticket lives on the
branch in the first workspace, the other ticket lives on the branch in the
second workspace. This assumes you never get confused about where you are,
but I don't think the question "which workspace am I in" vs "what is the
current branch" is any more difficult. And it saves the whole "I have to
stash my current state so I can switch branches and do some work then
switch back and unstash and so on".
--
Scott Robison
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
