Listing a project twice in the same manifest

[Brad Larson]

It would be nice to list a project twice in one manifest, which the
listings pointing to different git branches. This would allow me to
work on a branch of an app and still have the master code checked out
and easily viewable. It would also make it easier to have both
versions of the app run and debug on the Android emulator.

Does this seem like a reasonable thing to do? Currently repo fails
with:

error.ManifestParseError: duplicate project platform/build in /home/
larson/work/droid/.repo/manifest.xml

I don't know much about python, so unless this is a trivial change I
won't be much help.

Thanks,
Brad

[Shawn Pearce]

Its not really going to be a trivial change.  There's code in lots of parts of repo that assumes that the project name is unique.  Hence, mapping in the same project at different locations in the client (and with different revisions) isn't going to work well.

Also, repo sort of uses the "git contrib workdir" trick to symlink .git/ back to a hidden repository.  If two working directories were mapped back to the same repository it gets really funky when you check out the same local branch in both working directories.  There's only one branch, but two different indexes.

I'm not saying its unreasonable, just that there are *many* assumptions that have be fixed first.

[Brad Larson]

Thanks for your explanation!

One other option I was considering is to symlink the repository on the
server... so I would have platform/packages/apps/customized-calculator
-> ../calculator

This would allow separate project names in the manifest, so I could
check out both branches at once, but would still allow me to merge
between branches. Would I run into the same problems with the git
contrib workdir?

Thanks Shawn!
-Brad

On Feb 2, 2:05 pm, Shawn Pearce <s...@google.com> wrote:
> Its not really going to be a trivial change.  There's code in lots of parts
> of repo that assumes that the project name is unique.  Hence, mapping in the
> same project at different locations in the client (and with different
> revisions) isn't going to work well.
>
> Also, repo sort of uses the "git contrib workdir" trick to symlink .git/
> back to a hidden repository.  If two working directories were mapped back to
> the same repository it gets really funky when you check out the same local
> branch in both working directories.  There's only one branch, but two
> different indexes.
>
> I'm not saying its unreasonable, just that there are *many* assumptions that
> have be fixed first.
>

[Shawn Pearce]

Nope, if you symlink on the server then repo can't tell the difference between a "real" project and the "symlink" project.  So it will work just fine.

[Otto Linnemann]

I have a similar problem which I consider a more general issue. My project needs multiple instances of different releases of a library which are maintained as branches in one git repository. Obviously this use case is not really covered by the android repo script since the tag "project name" which specifies the git repository to be used can only be declared once in the manifest file.

I found out the following workaround to be able to handle two instances of the given library which are checked out from the same git repository "ltenad/apps_proc/peiker/libeXosip2.git":

manifest.xml ---->

...

  <project path="apps_proc/peiker/libeXosip2-v2.4-4.0.0" name="ltenad/apps_proc/peiker/libeXosip2"

     revision="refs/heads/v2.4-4.0.0" />

 <project path="apps_proc/peiker/libeXosip2-v2-3.5.0" name="ltenad/apps_proc/peiker/libeXosip2.git"

     revision="refs/heads/v2-3.5.0" />

But this is obviously not a decent and clean solution. It is furthermore limited to only two instances of the given library.

I believe that this is a general shortcoming of the current implementation of the repo script system which might require a change request.

Any help is welcome.

Best Regards,

Otto

[David Pursehouse]

On 06/26/2013 03:54 PM, Otto Linnemann wrote:

[...]

> I believe that this is a general shortcoming of the current
> implementation of the repo script system which might require a change
> request.
>

A feature request already exists for this [1]. I didn't search the
mailing list for previous discussion about it before I submitted that.

Unfortunately it doesn't seem like it's trivial to implement it, which
is I guess one of the reasons it hasn't been done yet...


[1] https://code.google.com/p/git-repo/issues/detail?id=141

[Jean-Baptiste Queru]

One of the problems is that repo commands allow to specify projects both by name and by path. If multiple projects have the same name, things won't work as well.

In good news, things are stored by path in .repo/projects, so that part it ready to have multiple paths on the same name.

At some point in the past, it wasn't possible to run repo commands by path if the project hadn't already been checked out. Specifically, it wasn't possible to run repo init [...]; repo sync <path>. This might have been fixed.

Syntax-wise, we could make repo commands fail when specifying an ambiguous name, or work on all matching projects.

This feature would be very useful for Android, as it'd allow to sync the kernel trees as part of the platform. Right now we can't do that, because we have cases where we use multiple branches from within a single remote project.

A trick we've used in the past was to use a symlink on the server side. I wouldn't recommend it if you need to have Gerrit as well.

JBQ

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

--- You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[Otto Linnemann]

Thank you for this clarification. Since we also use Gerrit we obviously cannot use the symlink workaround. At the moment my approach of using one name with the extension ".git" and one without seems to work correctly. At least I have not yet observed any problems with it. Is there any further problem with this approach?

Would it be possible to introduce another xml-tag e.g. "repo" to annotate the git-url within the manifest file in further repo versions? Per default repo would get the same content as specified by the name tag but if specified it would allow to address the same repository from different projects with different name AND path.

On Wednesday, June 26, 2013 4:52:10 PM UTC+2, JBQ wrote:

One of the problems is that repo commands allow to specify projects both by name and by path. If multiple projects have the same name, things won't work as well.

In good news, things are stored by path in .repo/projects, so that part it ready to have multiple paths on the same name.

At some point in the past, it wasn't possible to run repo commands by path if the project hadn't already been checked out. Specifically, it wasn't possible to run repo init [...]; repo sync <path>. This might have been fixed.

Syntax-wise, we could make repo commands fail when specifying an ambiguous name, or work on all matching projects.

This feature would be very useful for Android, as it'd allow to sync the kernel trees as part of the platform. Right now we can't do that, because we have cases where we use multiple branches from within a single remote project.

A trick we've used in the past was to use a symlink on the server side. I wouldn't recommend it if you need to have Gerrit as well.

JBQ

On Wed, Jun 26, 2013 at 1:41 AM, David Pursehouse <david.pu...@sonymobile.com> wrote:

On 06/26/2013 03:54 PM, Otto Linnemann wrote:

[...]

> I believe that this is a general shortcoming of the current
> implementation of the repo script system which might require a change
> request.
>

A feature request already exists for this [1].  I didn't search the mailing list for previous discussion about it before I submitted that.

Unfortunately it doesn't seem like it's trivial to implement it, which is I guess one of the reasons it hasn't been done yet...


[1] https://code.google.com/p/git-repo/issues/detail?id=141

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

--- You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[sushan ray]

Hi,
I guess now the "multiple branches for same project" feature is available as part of repo. However does it have any 
adverse effect on the "repo download" functionality?

Now it seems, for a project mapped to multiple branches and paths, if a patch commit is made to any one of the branches 
and then trying to use the "repo download" from gerrit to apply the patch, produces random results. This might be 
because the repo has no idea which path the patch should be downloaded to.

Please refer to Issue 173: https://code.google.com/p/git-repo/issues/detail?id=173

Any opinion or solution for this problem is welcome.

Regards, Sushan.