For a very nice (IMHO) model on how to handle forks take a look at monotone. Forking is natural, you just want to take precautions to keep your data safe. A fork is just a branch you haven't given a name to and didn't necessarily intentionally create. In the case of monotone it just lets you know you have a fork and you can just merge or keep on working, your choice.
On Thu, Mar 10, 2011 at 11:29 AM, Eric Junkermann <e...@deptj.eu> wrote: > > On Thu, March 10, 2011 12:38 am, Ron Wilson wrote: >> On Wed, Mar 9, 2011 at 3:52 PM, Eric <e...@deptj.eu> 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 > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
