Hi Nicolas,

On 05/17/2013 09:20 AM, Nicolas Dechesne wrote:
>
> On Wed, Apr 3, 2013 at 2:24 PM, Christopher Covington <cov@codeaurora.org
> <mailto:cov@codeaurora.org>> wrote:
>
>     >> I notice you've created a number of shell scripts to manage checking out
>     >> multiple git repositories, specific revisions of git repositories for a
>     >> release, etc. Repo [1] does this stuff pretty well that you might want to
>     >> consider as an eventual alternative.
>     >
>     > I was considering repo few times but jenkins-setup scripts are used not
>     > only to fetch/update/freeze git repositories but mostly to handle build
>     > jobs (at CI or any other machine).
>
>     I'm glad to hear that you've looked into it. There's certainly a lot more to
>     automation than revision control, although Repo does seem to play well with
>     others in my experience. Anyhow, I just figured if there was an unexplored
>     possibility to make things easier for developers and users, I'd try to
>     mention it.
>
>
> hi.
>
> even before that discussion started i was using 'repo' to manage my own
> (currently private) OE based distro, and I thought I would share my own
> conclusions too.. so i am currently using repo with a OE 'manifest' that
> describe the set of all 'layers' (trees) which i need to build my distro. I am
> not using gerrit at all, I am just using repo as a tool to manager multiple
> 'git trees' in a somehow synchronous manner.
>
> and as surprised as i was... i have to say that I like this setup very much.
> The main advantages i can see are:
>  - ability to checkout the entire 'distro' at once, as well as update all tree
> at once: repo sync
>  - ability to easily track and switch 1 or more stable versions, as well as
> master: repo init -b dylan && repo sync
>  - we could potentially use the 'smartsync' feature of repo to provide an
> 'always' working environment for our downstream users
>  - ability to create 'static' manifest with the commit of each sub project to
> easily regenerate 'releases' (repo manifest -r)
>
> and the *most* interesting feature by far to me, is 'repo grep' that is
> equivalent to 'git grep' but in all *projects*. For OE work 'git grep' is a
> very useful command, so ability to grep in all layers at once is a killer feature.
>
> since a picture is worth a thousand words... and since I cannot show my
> current distro trees for, i have made a sample manifest for review.
>
> https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git
> <https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=summary>
>
> This is a simple manifest that pulls oe-core, meta-oe, bitbake, meta-linaro
> and meta-beagleboard, see:
>
> https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=blob;f=default.xml;h=8ff267206ad36b5ded032aa15d313fa19af6e0a5;hb=refs/heads/master
>
> the workflow is the following:
> - for someone who needs to setup the build env:
> repo init -u   git://git.linaro.org/people/ndec/oemanifest.git
> <http://git.linaro.org/people/ndec/oemanifest.git>
> repo sync
>
> - to switch from master to dylan:
> repo init -b dylan && repo sync
>
> - to grep the entire set of layers:
> repo grep SRC_URI
>
> - and 'release manifests' can be checked out in the tree as well, see:
> https://git.linaro.org/gitweb?p=people/ndec/oemanifest.git;a=shortlog;h=refs/heads/release

I like this use of pinned revisions on a branch, and I wonder if it might be
useful to do this for last-known-good revisions too. Assuming a project is to
the point where LKGR info is worth the hassle of implementing something, if
automation could just run `repo manifest -r` and commit and push the output to
an "lkgr" branch of the manifest.git repository, that might make the hassle a
bit less than setting up an XML-RPC manifest-server to do the same job.

> Initially i was hoping to get a similar setup with git submodule instead of
> repo, but submodule won't let us track a 'branch' to 'updating' all trees
> isn't as simple, and also i had some troubles because 'bitbake' is in
> oe-core/.gitignore, and that would prevent me from adding the bitbake
> submodule... anyways, i think 'repo'
>
> feel free to respond if you have any feedback. but basically it looks like we
> might use a similar setup for one of our next projects here.

It looks to me like a good setup. I hope to hear more about it in the future.

Regards,
Christopher

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev