On Thu, March 10, 2011 12:38 am, Ron Wilson wrote: > On Wed, Mar 9, 2011 at 3:52 PM, Eric <[email protected]> wrote: >> Finally, I don't think there is any way to safely have automatic merging >> of forks. > > This I agree with and never intended to suggest that forks should ever > be automatically merged. > >> And, as Richard said, what is a fork? > > Something I want to avoid like the plague. Your workflow seems, > strictly followed, should (somewhat) minimize the risk of an > accidental fork, however, you imply that you do intentionally start > forks.
No, it's just that working that way means I will inevitably find myself on a fork from time to time. > I suppose if you make sure to either close the fork by merging, > or tag it as a branch, before pushing your changes, then that should > be ok. Which is exactly what I think should be done. > It seems to me that forks are something that are all too easy > to "loose". The "leaves" page in the web UI (no longer on the menu) is actually very useful for finding them, especially if you close them after dealing with them appropriately. > I do not see any advantages to creating a fork rather than a branch. > If anything, all this discussion just reinforces the advice (from some > people) that creating a branch for each and every task/change package > is the right thing to do - especially when using a DVCS. Task Branch, Feature Branch, Release Branch, Private Branch - which all look much the same, except which other branches they merge to and from, and when; also whether they get closed or not. You don't need to have a "branch policy", but it's useful to know what your branch is for and how you plan to use it. If you create a fork on purpose it's meant to be a branch - put some hint of the purpose in the name of the branch. > I do realise that accidental forks are inevitable, so anything that > the tool does to help find forks will help the overall development > process. Just for forks, I think it's enough to look at the timeline frequently (in Checkins Only mode), but some path stuff seems to be going into Fossil, so we shall see. Eric _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
