bzr push to an extant non-branch directory fails horribly

[Wouter van Heyst]

 mkdir /tmp/mirror
 bzr: ERROR: File exists: u'/tmp/mirror': [Errno 17] File exists: '/tmp/mirror'

This at the very least needs a better error message. Push help also isn't very clear on the issue. Further discussion of desired behaviour below.

If you would try to do this with a precious directory like ~/public_html/ I appreciate not nuking it. Just adding .bzr without workingtree might work, although fuzzy, but with a workingtree refusing seems the right thing to do. In this specific case, I prepared the empty branch directory, should push work in that case?

[Martin Pool (mbp)]

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?

[Wouter van Heyst (larstiq)]

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.

[Robert Collins (lifeless)]

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.

[Aaron Bentley (abentley)]

-----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-----

[Robert Collins (lifeless)]

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>.

[John A Meinel (jameinel)]

-----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-----

[Aaron Bentley (abentley)]

-----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-----

[Ace Suares (acesuares)]

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

[Wouter van Heyst (larstiq)]

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

[Martin Pool (mbp)]

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

[David Allouche (ddaa)]

Is that a dup of bug 53340?

[David Allouche (ddaa)]

Or maybe bug 45504?

[John A Meinel (jameinel)]

Bumping to 0.11

[Wouter van Heyst (larstiq)]

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.

[John A Meinel (jameinel)]

Bumping to 0.12

[John A Meinel (jameinel)]

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

[John A Meinel (jameinel)]

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