On Sep 19, 2015, at 9:16 PM, Ron Aaron <[email protected]> wrote: > > So the next obvious solution is to fork the repo. But now I have repo and > repo-custom, where the latter contains just the 'branch' of the customer. > > What I'm looking to do is have the ability to do merges using fossil, between > the two repos. Obviously I can use a tool like 'Beyond Compare' but using > fossil makes it so much easier. If it's possible, that is…
Fossil itself won’t be much help here because it doesn’t offer subtree-level permissions. If you can see some files in the tree, you can see all of them. (If it were otherwise, it would greatly complicate clone, doc URLs, etc.) I think you’ve already got the solution: create a customized private repo for your special customer, then occasionally run Beyond Compare (or rsync, or…) to copy current work over from the main repo to the private one. When you check the changes in, it will only include changes to files known to the private repository, so if there are files in the main repo that aren’t published to your special customer, Fossil’s checkin mechanism won’t include them. You might therefore want to run “fossil extra” or “fossil clean” on the private repo occasionally to make sure the build isn’t depending on files that your customer can’t see. I would recommend not actively developing on the private customer repo any more than you have to. Try to do as much work as you can on the main repo, so that you don’t need to backport work from the private repo to the main repo. But, should backporting be necessary, the same sync process should work just as well in reverse: private customer files won’t be checked into the public tree even though your sync tool copies them into the tree because you didn’t “fossil add” them there. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
