Can I get source with specified tag of manifest.git when I do repo init ?

[lingy...@gmail.com]

Shawn,

I have following issue.

My default.xml in manifest.git needs to update according to different
tags.

For example,
In tag v1.0, I only have android source code.
In tag v2.0, one new project A is added, source code include android
+ project A.
In tag v3.0, project A is removed, project B is added, source code
include android + project B.

Is there a way that people can get source code with specified tag from
my repo easily ? The function likes "repo init -u git://host/manifest.git
-v2.0" ? Or is there an easy way to do this ?

Thanks,
Emily

[Shawn Pearce]

Easy, maybe not.

Create 3 branches in your manifest repository:  m1.0, m2.0, m3.0 and have each XML file be different as necessary, including which projects are included/excluded and which revisions to use.

Clients can use "repo init -u ... -b m1.0" to select the 1.0 tree, etc when their client is being created.

Switching a m1.0 client to m2.0 or m3.0 isn't easily supported.  It depends on the sorts of differences between them.  "repo init -b m2.0" is *supposed* to work, but people have already reported that it doesn't.

[lingy...@gmail.com]

Oh...

My release will be very frequently, maybe apply one new tag per 1~2
days. It would be very difficult to maintain so many branches.

I think using tag on one branch (master branch) may be an more easier
way ...
1. modify default.xml, commit. Then apply tag.
2. When do a new release, update default.xml, commit. Then apply a new
tag.
Do you agree with me ?

Can "-b" parameter in "repo init -u ... -b m1.0" be set to one tag ?

Thanks,
Emily

On Feb 11, 11:39 am, Shawn Pearce <s...@google.com> wrote:
> Easy, maybe not.
>
> Create 3 branches in your manifest repository:  m1.0, m2.0, m3.0 and have
> each XML file be different as necessary, including which projects are
> included/excluded and which revisions to use.
>
> Clients can use "repo init -u ... -b m1.0" to select the 1.0 tree, etc when
> their client is being created.
>
> Switching a m1.0 client to m2.0 or m3.0 isn't easily supported.  It depends
> on the sorts of differences between them.  "repo init -b m2.0" is *supposed*
> to work, but people have already reported that it doesn't.
>

> On Tue, Feb 10, 2009 at 19:30, lingyan....@gmail.com
> <lingyan....@gmail.com>wrote:

>
>
>
>
>
> > Shawn,
>
> > I have following issue.
>
> > My default.xml in manifest.git needs to update according to different
> > tags.
>
> > For example,
> > In tag v1.0, I only have android source code.
> > In tag v2.0, one new project A is added, source code include  android
> > + project A.
> > In tag v3.0, project A is removed, project B is added, source code
> > include android + project B.
>
> > Is there a way that people can get source code with specified tag from
> > my repo easily ? The function likes "repo init -u git://host/manifest.git
> > -v2.0" ? Or is there an easy way to do this ?
>
> > Thanks,

> > Emily- Hide quoted text -
>
> - Show quoted text -

[Shawn Pearce]

On Tue, Feb 10, 2009 at 20:00, lingy...@gmail.com <lingy...@gmail.com> wrote:

My release will be very frequently, maybe apply one new tag per 1~2
days. It would be very difficult to maintain so many branches.

I think using tag on one branch (master branch) may be an more easier
way ...
1. modify default.xml, commit. Then apply tag.
2. When do a new release, update default.xml, commit. Then apply a new
tag.
Do you agree with me ?

Yes.  But make sure the tags are available in the other projects *before* you push the updated XML in the manifest.  This removes any race condition where a client starts to sync, gets a new manifest with a new tag name in it, but can't find the tag in the other project(s) as you didn't get there yet.
 

Can "-b" parameter in "repo init -u ... -b m1.0" be set to one tag ?

No, only to a branch.
 

[Rex Tener]

On Tue, Feb 10, 2009 at 8:06 PM, Shawn Pearce <s...@google.com> wrote:
> On Tue, Feb 10, 2009 at 20:00, lingy...@gmail.com <lingy...@gmail.com>

>> Can "-b" parameter in "repo init -u ... -b m1.0" be set to one tag ?
>
> No, only to a branch.

Thanks for clarifying, I was trying to do that last night.

--
Rex Tener
rex....@gmail.com

[lingy...@gmail.com]

Shawn,

I have another question, in my manifest.xml, I specify to get source
of tag v2.0.

When I do repo sync, it shows that not only tag v2.0, but also tags
v1.0, v3.0 are gotten at the same time.

I want to build on source code with tag v2.0. How can I ensure current
source code I'll build are all with tag v2.0, not v1.0/v3.0 ?

Thanks,
Emily

[Shawn Pearce]

The tags are downloaded at the same time because they are possibly "free".  E.g., getting v2.0 probably implies you have all of the data needed for v1.0, so getting the v1.0 tag at the same time costs nothing.  Its just the way git behaves by default.

You just need to ensure you specify the right version when do the checkout.  Which with repo can be done by setting the revision attribute in your default.xml.

If you really want to verify it, run a git describe in the project, e.g.:

  repo forall -c 'if [ "`git describe 2>/dev/null`" != v2.0 ]; then echo $REPO_PROJECT bad; fi'

[lingy...@gmail.com]

Shawn,

Thank you ! I tried follow steps,

1. $ repo forall -c 'git checkout v2.0'
HEAD is now at 6d6c82c... auto import from //branches/
cupcake/...@125939
HEAD is now at e8a868f... Code drop from //branches/cupcake/...@124589
HEAD is now at a2bb8bf... Code drop from //branches/cupcake/...@124589
HEAD is now at 928d471... auto import from //branches/
cupcake/...@125939
HEAD is now at 7b92f48... Updated the INFO to not have a conditional
within the definition.
HEAD is now at 97ef525... Initial commit.
HEAD is now at cc05ad2... auto import from //branches/
cupcake/...@125939
HEAD is now at 95cf464... auto import from //branches/
cupcake/...@125939
HEAD is now at 17e798f... Code drop from //branches/cupcake/...@124589
...
2. $ repo forall -c 'if [ "`git describe 2>/dev/null`" != v2.0]; then
echo $REPO_PROJECT bad; fi'
platform/bionic bad
platform/bootable/bootloader/legacy bad
platform/bootable/diskinstaller bad
platform/bootable/recovery bad
platform/build bad
codesourcery/toolchain bad
platform/dalvik bad
platform/development bad
platform/external/aes bad
platform/external/apache-http bad
platform/external/bison bad
platform/external/bluez bad
platform/external/bsdiff bad
platform/external/bzip2 bad
...

Did I miss anything ?

Thanks,
Emily

On Feb 11, 11:35 pm, Shawn Pearce <s...@google.com> wrote:
> The tags are downloaded at the same time because they are possibly "free".
> E.g., getting v2.0 probably implies you have all of the data needed for
> v1.0, so getting the v1.0 tag at the same time costs nothing.  Its just the
> way git behaves by default.
>
> You just need to ensure you specify the right version when do the checkout.
> Which with repo can be done by setting the revision attribute in your
> default.xml.
>
> If you really want to verify it, run a git describe in the project, e.g.:
>
>   repo forall -c 'if [ "`git describe 2>/dev/null`" != v2.0 ]; then echo
> $REPO_PROJECT bad; fi'
>

> On Tue, Feb 10, 2009 at 23:55, lingyan....@gmail.com
> <lingyan....@gmail.com>wrote:

>
>
>
>
>
> > Shawn,
>
> > I have another question, in my manifest.xml, I specify to get source
> > of tag v2.0.
>
> > When I do repo sync, it shows that not only tag v2.0, but also tags
> > v1.0, v3.0 are gotten at the same time.
>
> > I want to build on source code with tag v2.0. How can I ensure current
> > source code I'll build are all with tag v2.0, not v1.0/v3.0 ?
>
> > Thanks,

[Shawn Pearce]

What type of tag did you use?  Was it "git tag v2.0" or "git tag -a v2.0"?

If it was "git tag v2.0" (no -a) you'll need to use "git describe --tags" in the command I gave, but even then you need a pretty recent version of Git...

This is a better test.  It resolves both the tag and the current head to be a commit, and then tests that they are the same.  I'm not really sure why I didn't offer this before:

repo forall -c 'if [ "`git rev-parse v2.0^0 2>/dev/null`" != "`git rev-parse HEAD^0`" ];then echo $REPO_PROJECT bad;fi'

[lingy...@gmail.com]

I used "git tag v2.0".

There're two tags v1.0 and v2.0 applied to bionic project on same
commit id. Why "git describe --tags" only shows the old tag v1.0.
"git describe --tags --all" only shows v1.0, too.

I need to dig into git much more. :)

Thanks,
Emily

On Feb 12, 10:17 am, Shawn Pearce <s...@google.com> wrote:
> What type of tag did you use?  Was it "git tag v2.0" or "git tag -a v2.0"?
>
> If it was "git tag v2.0" (no -a) you'll need to use "git describe --tags" in
> the command I gave, but even then you need a pretty recent version of Git...
>
> This is a better test.  It resolves both the tag and the current head to be
> a commit, and then tests that they are the same.  I'm not really sure why I
> didn't offer this before:
>
> repo forall -c 'if [ "`git rev-parse v2.0^0 2>/dev/null`" != "`git rev-parse
> HEAD^0`" ];then echo $REPO_PROJECT bad;fi'
>

> On Wed, Feb 11, 2009 at 18:13, lingyan....@gmail.com
> <lingyan....@gmail.com>wrote:

> > > - Show quoted text -- Hide quoted text -

[Shawn Pearce]

I fixed git describe --tags in git 1.6.1 to output the lightweight tags more often:

  commit 7e425c4fbbe9affffa822f154d8bb2d0da6699ef
  Author: Shawn O. Pearce <spe...@spearce.org>
  Date:   Mon Oct 13 07:39:46 2008 -0700

    describe: Make --tags and --all match lightweight tags more often

    If the caller supplies --tags they want the lightweight, unannotated
    tags to be searched for a match.  If a lightweight tag is closer
    in the history, it should be matched, even if an annotated tag is
    reachable further back in the commit chain.

    The same applies with --all when matching any other type of ref.

Read the git tag manpage, there are two classes of tags.  When making software releases, the annotated form is preferred.  When making short-lived temporary tags for your own use, the default lightweight kind is often used.  git describe prefers the annotated form.

[lingy...@gmail.com]

Shawn,

Thank you for your information ! We need to upgrade git to 1.6.1 or
newer.

Thanks,
Emily

On Feb 13, 12:21 am, Shawn Pearce <s...@google.com> wrote:
> I fixed git describe --tags in git 1.6.1 to output the lightweight tags more
> often:
>
>   commit 7e425c4fbbe9affffa822f154d8bb2d0da6699ef

>   Author: Shawn O. Pearce <spea...@spearce.org>

>   Date:   Mon Oct 13 07:39:46 2008 -0700
>
>     describe: Make --tags and --all match lightweight tags more often
>
>     If the caller supplies --tags they want the lightweight, unannotated
>     tags to be searched for a match.  If a lightweight tag is closer
>     in the history, it should be matched, even if an annotated tag is
>     reachable further back in the commit chain.
>
>     The same applies with --all when matching any other type of ref.
>
> Read the git tag manpage, there are two classes of tags.  When making
> software releases, the annotated form is preferred.  When making short-lived
> temporary tags for your own use, the default lightweight kind is often
> used.  git describe prefers the annotated form.
>

> On Thu, Feb 12, 2009 at 01:17, lingyan....@gmail.com
> <lingyan....@gmail.com>wrote: