what you’re suggesting will not work unless I turn off auto-sync. the authors
of fossil have been very influential in convincing me to leave auto sync on.
With auto sync on, then there is no way for me to remotely code review unless
they commit to their repo, which would auto sync to the main repo. So it has
to be on a branch until it can be code reviewed.
I will be working with only a few contributors, most of whom have never used
any version control ever. I want it dummy proof. In the rare instance when we
may need to work around that paradigm I can get involved and help work with
fossil commands directly.
Also I want to find a way to automate the copy and pasting of the ticket uuid
into the commit comments. So that will end up in the wrapper scripts also
unless I can figure out a way to handle that through TH1.
If you have dot or graphviz, here is a small diagram showing what I think is
probably the workflow.
digraph featurebranch {
rankdir="LR";
node [shape=box];
trunk->DeveloperA[color=red];
DeveloperA->A2[weight=5,color=red];
trunk->2[style=dotted,weight=8];
A2->merge[weight=8,color=red];
2->merge[style=dotted,color=red];
merge->3[color=red];
2->3[weight=8];
trunk->developerB[style=dotted,color=blue];
developerB->2[style=dotted,color=blue];
}
On Apr 30, 2016, at 10:56 PM, Barry Arthur <barry.art...@gmail.com> wrote:
> The distributed/shared repository doesn't just hold trunk... it holds all
> non-private branches too. So when your developers are ready for you to review
> their work, they commit it to their task branch and then you (remotely)
> checkout/update to that branch (preferably into a fresh directory) and
> test/inspect their code. When you're happy with it, they (or you) can then
> merge their branch into trunk.
>
> Private branches are not the default type of branch, so your devs would have
> to go out of their way to get this wrong.
>
> I wonder if your team has previously been using git...? I mean, is that the
> reason why you want to create wrapper scripts instead of just letting your
> devs learn to use the much simpler (compared to git) fossil commands
> themselves?
>
> Instead of wondering in thought space about how all these scenarios might
> play out, you'd be much better off setting up a test repo and playing through
> them until you and your team are comfortable with the tools and your workflow.
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
