<blabbing> I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil.
In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. </blabbing> For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google "your project name". The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say "hey folks check out fossil hack, it's up on a cloned repo at url abc". Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a "public private branch" in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
