bzr push to an extant non-branch directory fails horribly

Bug #30576 reported by Wouter van Heyst on 2006-02-05
16
Affects Status Importance Assigned to Milestone
Bazaar
High
John A Meinel

Bug Description

 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) wrote :

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?

Changed in bzr:
status: Unconfirmed → Needs Info
Wouter van Heyst (larstiq) wrote :

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

Changed in bzr:
importance: Low → High
status: Needs Info → Confirmed

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

Aaron Bentley (abentley) wrote :

-----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) wrote :

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) wrote :

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

Changed in bzr:
assignee: nobody → larstiq
Martin Pool (mbp) wrote :

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

David Allouche (ddaa) wrote :

Is that a dup of bug 53340?

David Allouche (ddaa) wrote :

Or maybe bug 45504?

John A Meinel (jameinel) wrote :

Bumping to 0.11

Wouter van Heyst (larstiq) wrote :

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.

Changed in bzr:
assignee: larstiq → nobody
John A Meinel (jameinel) wrote :

Bumping to 0.12

John A Meinel (jameinel) wrote :

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

John A Meinel (jameinel) wrote :

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

Changed in bzr:
assignee: nobody → jameinel
status: Confirmed → Fix Committed
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers