Hi Dave, Thanks! The file operations that I'm referring to is the <copyfile> node for projects in the manifest files. This node tells repo to copy a file during its sync operation. This is a true copy and not a symlink or hard link. The nice thing is that repo makes the copy read only, which should remind you not to edit that copy.
To edit the file you would have to edit the one in b2g-scripts then run repo sync. I could write a simple script which parses the manifest and does the copy operations again without having to do a full repo sync operation. We could add symlink/hard link support to repo, but because we use the upstream copy of repo, we'd be dependent on Google accepting the patch. Forking repo does not seem like a good idea, given that one of our goals here is to increase interoperability with our partners and that would decrease it. Does that address your concerns? John On Aug 8, 2014, at 12:22 PM, Dave Hylands <dhyla...@mozilla.com> wrote: > Hey John, > > Sounds like a good plan. > > I'm not familiar with "repo file operations" and couldn't find any > documentation on this. > > If I wanted to make a change to the flash.sh script, can I edit the copy in > the B2G directory? Or do I have to edit the one in b2g-scripts? > > Would it be possible to have the script in B2G be symlinks rather than copies > (at least for linux)? > > Dave Hylands > > From: "John Ford" <jhf...@mozilla.com> > To: dev-b2g@lists.mozilla.org > Sent: Tuesday, August 5, 2014 12:51:52 PM > Subject: Proposal: Manage B2G.git scripts in a versioned repo > > [bcc: dev-gaia] > > Hi, > > We store Firefox OS source code in various git repositories. We use the > 'repo' tool written for the Android project to manage all of these > repositories other than the top level B2G.git repository. B2G.git has a few > helper scripts to simplify setting up a tree, building a tree as well as > other tasks. > > A problem we have is that the B2G.git repository needs to be updated > separately from the repo-managed repositories. Because B2G.git changes > infrequently, it's often not updated and that can lead to unexplained > breakage for developers. We and our partners have a lot of infrastructure in > continuous integration systems which can't easily make full use of the tools > stored in B2G.git without a lot of special code. > > My proposal is to move nearly all of the scripts and tools in B2G.git into a > repo managed repository. The only things left in B2G.git would be a modified > config.sh script and the repo stub script. I have a plan which should > maintain the existing workflow while also letting people use the standard > repo work flow. > > My plan is to: > > 1) create b2g-scripts repository, containing the B2G.git/scripts directory > 2) create b2g-tools repository, containing the B2G.git/tools directory > 3) move all scripts in the root of B2G.git into b2g-scripts > 4) use repo file copy operations (like we do for the root Makefile) to copy > those scripts back into the root of the source tree > 5) remove the device configuration part of config.sh > 6) create a new script, config-device.sh in b2g-scripts that has the device > configuration steps. > 7) have config.sh call config-device.sh after the source tree is initialized > > I will use Git history editing facilities to ensure that both b2g-scripts and > b2g-tools maintain their respective histories. > > Once this is done, you would still be able to set up a fresh tree with the > existing method: > > $ git clone https://github.com/mozilla-b2g/B2G.git > $ cd B2G > $ ./config.sh emulator > $ ./build.sh > > This will continue to work as expected and will give the same entry points > into the build system as we have now. Additionally, a new optional method > matching the standard way of using repo is available: > > $ mkdir B2G > $ cd B2G > $ repo init -u http://github.com/mozilla-b2g/b2g-manifest.git -m > emulator.xml > $ repo sync > $ ./config-device.sh emulator > > Please let me know if you have any thoughts on this issue. I would like to > make sure that there is consensus about these changes before I start because > testing will take some time. I will be doing as much as possible using > scripts to make sure that the changes are repeatable and easy to verify. > > Thanks, > > John > _______________________________________________ > dev-gaia mailing list > dev-g...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-gaia >
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
