New branch created accidentally

[Eric Siegerman]

On Wed, 2011-01-26 at 14:41 -0600, John Arbash Meinel wrote:
> On 1/26/2011 2:33 PM, John Arbash Meinel wrote:
> > [...] instead of using '/' to denote hierarchy they use sibling
directories
> > and redundant naming. (2.3-feature rather than 2.3/feature).

> > Is there sufficient momentum in that space that bzr should *enforce*
> > that policy? I've gone from "no" to "maybe". I don't think I'm at
> > "definitely" yet.

I think not.  I see your point that branches within branches are
a valid setup -- and by definition they'll be essential for a
some-day nested-tree facility.  So banning them seems pointless
and not very future-proof.  They're not what I'm asking about,
though.

A shared-repo that's also a branch ("SR+B" for short) is a
special case of that, and it might also be useful (now that I
know it's possible); I can use it to avoid the directory level
that, in my current setup, sometimes holds the shared repo and a
branch or two, but not much else, and is annoying to have to
traverse all the time.

That said, the question remains: should *push* be able to put
what was a simple SR into that SR+B state?  That is, given:
	bzr init-repo repo
	cd repo
	bzr init branch
	cd branch
	# populate and commit

what should this do?:
	cd .../repo/branch
	bzr push ..

Having found a use for the SR+B configuration, I now see a use
for turning a simple SR into one -- it's one way to migrate from
an existing SR to this new way of organizing things.

The question is, is "bzr push" a good place for that?  I submit
that "bzr reconfigure" would be a lot less, um, surprising.  And
even if "push" should be able to do it, IMO --use-existing-dir
should be required; without that option, the attempt should fail.

Thoughts?

  - Eric