A commercial company is interested in productizing one of my open source apps. The thought is to keep all existing pieces as open, but to change the app's name, and to add in various proprietary code designed to tap into their own services. Even so, development on the open code will continue, and occasionally changes will be pulled from the open codebase into the closed one.
I'd like to stick with using Fossil for both projects, but I'm wondering how to manage this case where these two repositories aren't truly in sync. I'd like to keep closed code completely outside of any open repositories to avoid accidentally tainting open code, so private branches wouldn't seem to be an option. My current thoughts are to clone the open project's repository, deliver that to the company as something they can host on their server. Any open development happens in the open repository, then when I want to merge in changes, I cd to the closed project and run: fossil pull --once http://open.project.url/ My guess is that this would just pull in open changes and won't try to push closed code (I.e. just one side of sync.) Is this going to complain about anything, though? I.e. will it complain if the repositories aren't exact copies before the pull? Also, ideally the changes won't introduce conflicts, since the closed code will be in an entirely separate package. There will be changes in at least one file in the closed branch, though, the AndroidManifest.xml which changes the app name and such. Will Fossil be OK with merging changes that don't cause conflicts, even if the repositories aren't strictly in sync? I hope I can use Fossil in this scenario, as it would vastly ease the pain of trying to keep the proprietary version in sync with the open version. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
