Oops, I messed up. I would like the new empty/unused project 'dvln' to instead be a project group.

A single Launchpad project can contain many Bazaar and Git repositories. Are you sure you need a project group? Can you explain your use case in more detail?

Thanks for the response William, appreciate it.

Let me revisit the interface/docs and see if I can get a bit more of a clue and figure out what I missed before. Hosting multiple git and bzr repo's is, indeed, what I would like to do (along with giving access/etc to other folks as needed over time). I made some assumptions that were, apparently, wrong after reading about groups a bit (thought they might be similar to an organization on something like github). Clearly it is time for me to do some deeper RTFM'ing.

Anyhow, if I can't figure it out after banging my head on things a bit more then I'll be back with more silly questions. ;) Cheers and sorry for the noise.

OK, I've perused docs and the website further but I think some more info would hep me. I might just have a terminology/concept block or grokking issue, but let me try and explain.

My understanding is that a Launchpad project seems to map to a single bzr shared repository and that this can contain <N> branches. It seems like a branch in bzr is often thought of as sort of a standalone repo of sorts based on what I've read (or comparisons to, say, git). My local clones are clones of branches (if using 'bzr branch'). So when you say a single Launchpad project can contain many Bzr repo's do you mean, effectively, many Bzr branches?

You also indicate it can contain many git repo's ... and looking at the git beta docs I see these possible URL's (as well as a single default git repo that can be associated as the project level:

  https://code.launchpad.net/~OWNER/PROJECT/+git/REPOSITORY
    -This identifies a repository for an upstream project.
  https://code.launchpad.net/~OWNER/DISTRIBUTION/+source/SOURCE/+git/REPOSITORY
    -This identifies a repository for a source package in a distribution.
  https://code.launchpad.net/~OWNER/+git/REPOSITORY
    -This identifies a "personal" repository with no particular connection to any project or package.

So it seems that 1st form sort of ties into associated <N> git repo's with a Launchpad "project"... so seems like git is, indeed, covered.

But for bzr it seems like if my codebase has 20 or 30 separate Go packages (each in separate repo's currently, each individually branched and versioned so I can work on 'master' or 'rel1' or any other branch in any of them with full independent naming of branches in each repo and such so I can use the same branch name no problem/etc). If I wanted to emulate that with bzr+launchPad project ... could I do that with a single regular Launchpad project? Or would I need a project group so that I could have <N> projects with each project mapping to a shared repo, each standalone project's shared repo available to house any branch name with no chance of having naming conflicts with my other projects in my overall project group, etc? Or am I still not quite "getting it" for bzr? Brick well, meet head. ;)

For my current needs I can get by with a single project and just use differently named branches to import different Go packages into one project... and then use branch naming conventions so that I have testbzrpkga-trunk, gopkgx-trunk, gopkgx-subbranch1 and then gopkgy-trunk, gopkgy-subbranch1 for another package. Just seems sort of "off" to me since gopkgx and gopkgy are totally separate projects/code-bases and they will never by merged and have no ancestral relationship... so having them in the same "shared repo" (project) using a branch namespace together seems "off" to me. Hence the thought about a package group still seeming cleaner (but, again, my mindset is more that of Git, SVN, ClearCase, Hg, etc).

Anyhow, I'll add this as "just a comment" so any followup answer would be optional as this is a bit verbose and since I think, for now, I can make things work with a single project. I'm just looking to get a better grip as I continue to read up and grapple with new systems (launchpad+bzr) and terminology and such.

Thanks much again!
Erik

On 23/09/15 11:02, Erik wrote:
> Question #271550 on Launchpad itself changed:
> https://answers.launchpad.net/launchpad/+question/271550
>
> Erik posted a new comment:
> OK, I've perused docs and the website further but I think some more info
> would hep me. I might just have a terminology/concept block or grokking
> issue, but let me try and explain.
>
> My understanding is that a Launchpad project seems to map to a single
> bzr shared repository and that this can contain <N> branches. It seems
> like a branch in bzr is often thought of as sort of a standalone repo of
> sorts based on what I've read (or comparisons to, say, git). My local
> clones are clones of branches (if using 'bzr branch'). So when you say
> a single Launchpad project can contain many Bzr repo's do you mean,
> effectively, many Bzr branches?

When I mentioned "Bazaar and Git repositories" I should have instead
said "Bazaar branches and Git repositories". The term "branch" is
conceptually similar in Git and Bazaar, but a Bazaar branch is a
first-class object that can be manipulated as its own entity, while a
Git branch exists only as part of its repo. Launchpad doesn't use Bazaar
shared repos (an alternate mechanism known as "branch stacking" is used
to share data between branches), so each branch is effectively independent.

The general guideline is that one project corresponds to one codebase,
though this isn't enforced and many projects violate it in small ways
(eg. having a separate branch containing the website or documentation).
So most of a project's branches tend to be of the same codebase, and
they are mergeable. But there may also be branches of other codebases or
non-code trees in the same project.

> You also indicate it can contain many git repo's ... and looking at the
> git beta docs I see these possible URL's (as well as a single default
> git repo that can be associated as the project level:
>
> https://code.launchpad.net/~OWNER/PROJECT/+git/REPOSITORY
> -This identifies a repository for an upstream project.
> https://code.launchpad.net/~OWNER/DISTRIBUTION/+source/SOURCE/+git/REPOSITORY
> -This identifies a repository for a source package in a distribution.
> https://code.launchpad.net/~OWNER/+git/REPOSITORY
> -This identifies a "personal" repository with no particular connection to any project or package.
>
> So it seems that 1st form sort of ties into associated <N> git repo's
> with a Launchpad "project"... so seems like git is, indeed, covered.
>
> But for bzr it seems like if my codebase has 20 or 30 separate Go
> packages (each in separate repo's currently, each individually branched
> and versioned so I can work on 'master' or 'rel1' or any other branch in
> any of them with full independent naming of branches in each repo and
> such so I can use the same branch name no problem/etc). If I wanted to
> emulate that with bzr+launchPad project ... could I do that with a
> single regular Launchpad project? Or would I need a project group so
> that I could have <N> projects with each project mapping to a shared
> repo, each standalone project's shared repo available to house any
> branch name with no chance of having naming conflicts with my other
> projects in my overall project group, etc? Or am I still not quite
> "getting it" for bzr? Brick well, meet head. ;)
>
> For my current needs I can get by with a single project and just use
> differently named branches to import different Go packages into one
> project... and then use branch naming conventions so that I have
> testbzrpkga-trunk, gopkgx-trunk, gopkgx-subbranch1 and then gopkgy-
> trunk, gopkgy-subbranch1 for another package. Just seems sort of "off"
> to me since gopkgx and gopkgy are totally separate projects/code-bases
> and they will never by merged and have no ancestral relationship... so
> having them in the same "shared repo" (project) using a branch namespace
> together seems "off" to me. Hence the thought about a package group
> still seeming cleaner (but, again, my mindset is more that of Git, SVN,
> ClearCase, Hg, etc).
>
> Anyhow, I'll add this as "just a comment" so any followup answer would
> be optional as this is a bit verbose and since I think, for now, I can
> make things work with a single project. I'm just looking to get a
> better grip as I continue to read up and grapple with new systems
> (launchpad+bzr) and terminology and such.

It's perfectly possible to have Bazaar branches at lp:~wgrant/dvln/foo
and lp:~wgrant/dvln/bar containing unrelated "subproject" codebases. But
it's difficult to split out which branches are for which "subproject",
as Launchpad only knows about the real project.

If you really have 20 or 30 separate repositories that are versioned
separately and potentially useful standalone, a project for each
definitely makes sense, and therefore so does this project group
request. Let me know if you want to proceed down that path, and I'll set
the project group up for you.

Thanks for the clarification William. I'm beginning to grok things and your input is definition helping with that.

If you wouldn't mind setting up a project group that would be great as I think that provides a cleaner solution with more flexibility, separation of concerns and scalability. Anyhow, whenever is convenient for you is fine. Aside: do not worry about the 'dvln' project test branch that I've created, you don't need to save it if it's easier to blast it (I can recreate trivially). Anyhow, once you create the project group then I'll look towards migrating a number of separate repo's to it.

I will look to begin migrating some packages into the project group over the coming weeks although I will probably only start with 5 or 10 until I get the hang of it a bit further. Anyhow, that should scale over time (I have around 40+ separate packages currently versioned but will not be moving all of them, only some...as the goal of my tool is to support various VCS services so I'll be spreading them out and, of course, growing those dependencies as well as I version a web site as well as the tooling itself, etc).

Anyhow, appreciate your time and willingness to help. Cheers!

Erik

https://launchpad.net/dvln is now a project group. The old project is gone.

Very cool, thanks much William, appreciate your help!