> I have a fossil repo with two branches: trunk and features. My thinking > was to develop the new features requested on the features branch, > keeping the trunk branch unchanged unless something happened with the > application that required an immediate change. Then once some set of > features was done, I'd merge it back it into the trunk, which I expected > to do with something like: > > fossil checkout trunk > fossil merge features > > But I note that the merge documentation says that it will not move files > in trunk if they've been moved in features, only merge in the changes. > That will cause my application to break. How can I merge the entire set > of changes? Or is this wrong-headed in fossil? Should I be merging any > small changes from trunk into features instead, closing "trunk", and > making features the new trunk? (Can I change the name?) > > -- > Joshua Paine
Having a features branch for new development is a perfectly reasonable SCM pattern, with the advantage that there will never be any spurious branches (forks) on trunk. I think your problem is in how you look at a merge. The SCM software should not be deciding which parent should win in a merge conflict, and that is what a moved file is, a conflict. There is no single behaviour that Fossil could have in this situation that would be right for everyone (or for the same person every time!), so you will have to sort it out for yourself. I would identify the moves that had happened in Features, do them in Trunk, then do the merge. It doesn't change anything about the merges, but it is sometimes useful to merge trunk into features one or more times during development, to make it less likely that new development will break a fix. Doing the merge the other way round is "branch per release", where you would be merging last-release-plus-fixes into current-release, then creating a new branch for next-release, retaining current-release for fixes. I think in this case the branches should be named after the releases (even if only something like rel2010-01), and trunk should be ignored. But it doesn't make resolving conflicts any easier. Regards, Eric _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
