bzr push to an extant non-branch directory fails horribly

If I understand correctly the desired behaviour is:

 - if the destination does not exist at all, push creates it (works)
 - if the destination exists but is not an empty directory, an error is raised (works but the error is clear)
 - if the destination exists and is an empty directory, push makes a new bzrdir there

Some questions:

Is it ok to have a .bzrdir and nothing else? Should it be OK to push to a nonempty directory if we're not building a checkout?

I'd like there to be an option (also for sftp) to create a checkout, but it is fine to not do that by default, even for local paths.

I suppose that answers your .bzrdir question? If there is already a .bzrdir present in the target the normal have-these-branches-diverged code would kick in. Not sure what that does if you just mkdir .bzr and don't add any control files.

Pushing to a nonempty directory when not building a checkout is an interesting question. It might make for a fun way to bzrize a new upstream tarball, you can go straight on to running status and diff. That is the only use case I can think of sanely supporting, having a .bzr that has nothing to do with your working tree could wreak havoc with old revert behaviour, although it looks safe now. Still makes for confusing diff/status output.

This is affecting a growing number of users who ctrl-c the initial push to the supermirror, and it cannot be corrected by them as they cant remove the directory on the supermirror. That fact that leaves a non-branch dir is a separate bug, but this is likely easier and quicker to fix. I think an empty dir, and a dir with .bzr or .bzr/repository existing should all be treated equally.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> This is affecting a growing number of users who ctrl-c the initial push
> to the supermirror, and it cannot be corrected by them as they cant
> remove the directory on the supermirror.

(unless they use an sftp client)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEpYo30F+nu1YWqI0RAs3DAJ45qNFlOb3j8OUMIx7u0VgcXmgVkwCggs9h
ygqgDSJ/VbRFL55IkCXfW0o=
=MKmo
-----END PGP SIGNATURE-----

On Fri, 2006-06-30 at 20:31 +0000, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> > This is affecting a growing number of users who ctrl-c the initial push
> > to the supermirror, and it cannot be corrected by them as they cant
> > remove the directory on the supermirror.
>
> (unless they use an sftp client)

Even with an sftp client they cannot remove the directory.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Fri, 2006-06-30 at 20:31 +0000, Aaron Bentley wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Robert Collins wrote:
>>> This is affecting a growing number of users who ctrl-c the initial push
>>> to the supermirror, and it cannot be corrected by them as they cant
>>> remove the directory on the supermirror.
>> (unless they use an sftp client)
>
> Even with an sftp client they cannot remove the directory.
>
> -Rob

Can they move it out of the way? Most nice clients I know of do provide
some sort of recursive remove, though.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEpZYZJdeBCYSNAAMRArSvAJ48Pr4AxbEYkj57boWQqsLVUk6+zwCbB+TP
iqprOrzkd64OuRqZnEmTZmE=
=COE4
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:

> Even with an sftp client they cannot remove the directory.

Then there's more than one bug. :-)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEpchg0F+nu1YWqI0RAu5lAJ4nLBqt0MhZPLzQZNaEK5/Ss8IcFgCfUOuO
JtrLfo0fGgrQC77+3kaWRtw=
=RIyX
-----END PGP SIGNATURE-----

Indeed, this is biting me right now... all files are owned like this:

drwxr-xr-x 3 1001 1001 4096 Jul 04 20:05 xxxxx

and I can't delete, or rename, xxxxx

I've touched this area trying to factor out create-prefix for remote-init, will try to tackle this this week.

Wouter, how did you go with this? It'd be good to get it in 0.10.

Is that a dup of bug 53340?

Or maybe bug 45504?

Bumping to 0.11

I've been hogging this long enough, it is better to release it and let someone else work on it. I'm happy to answer any questions to get up to speed.

Bumping to 0.12

Taking this out of the queue until someone decides to step up to work on it.

supply --use-existing-dir as of bzr 0.15