Mark Michelson <[email protected]> writes: > On 2/27/19 10:14 AM, Aaron Conole wrote: >> Hi Mark, >> >> Mark Michelson writes: >> >>> Hi everyone, >>> >>> I have completed a *rough* POC of an OVN/OVS code split. You can find it >>> at https://github.com/putnopvut/ovn.git >>> >>> Please take a look at the README file since that highlights how the >>> split was done, as well as some known issues. >>> >>> My attitude towards this repo is that it is a throwaway prototype. It >>> essentially proves the concept that OVN can include OVS as a git >>> subtree, while not really attempting to do a production-ready job of >>> doing so. There is a lot of unfinished work. >> >> Thanks for starting this. >> >> As others have noted, the git subtree is a strange sort of requirement. >> Do you think it makes sense to have the ovs makefile install the >> requisite utilites and man-page templates in known locations instead? >> In that fashion, there's no need to have a separate clone of ovs, we can >> just ensure that we've done an install of OVS and the build system can >> search for the dependencies. >> >> I think it might just be as simple as adding the needed pieces to the >> various existing automake variables (scripts_SCRIPTS, scripts_DATA, >> maybe MAN_FRAGMENTS, etc). If that is acceptable and works, you could >> include it as a temporary patch in the OVN split directory until it gets >> merged to OVS mainline. That way, we could apply to our tree, rather >> than needing a separate clone of the ovs repo, and when other downstream >> projects build there's no need to clone the repo again. rpms and debs >> could have -dev(el) versions that install those files. >> > > OK I see what you're saying. The idea would be that an installation of > OVS would put the parts OVN depends on into specific locations on the > filesystem, and OVN could then use those "installed" files as needed. > > I suppose that there would be some default locations for these > files. If the files are installed to custom locations, then OVN could > be told these custom locations at configure time. > >> I'm looking forward to the next spin, and hope that it will be based off >> a newer cut of the openvswitch repository. >> >> Have you thought about using the `git filter-branch` facility to try and >> preserve history, as well? I don't know how important you think it is >> to try and keep the history, but it could be a way to take an existing >> OVS repository and cut out all the non-OVN commits (which is a huge >> number of them, true). It might be a lot of work for not enough gain, >> though. Just a fleeting thought. > > Jiri Benc had brought up git filter-branch back during the early > planning stages as a mechanism for maintaining history. One issue he > had brought up, IIRC, is that with git filter-branch, you're forced to > maintain the same directory structure.
I think it's possible to do. See, https://gist.github.com/emiller/6769886 for an example. > In my POC, I moved the ovn/ > subdirectory to the top level. Also, I think the amount of work to > filter out all of the non-OVN commits would not be worth it, > especially since classifying commits as being related to OVN vs. not > related to OVN can be murky at times. Agreed. Probably not worth it. >> >>> Please let me know your thoughts on this. >>> Thanks, >>> Mark Michelson >> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
