bzr resolve should automatically resolve conflicted directory deletion

Bug #344013 reported by Martin Pool on 2009-03-17
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Bazaar
High
Martin Packman

Bug Description

bzr merges conflict if a deleted directory contains unversioned files, which is probably fair enough. (Arguably they should not conflict if the files are all ignored, like .pyc files, but that's a separate bug.)

If I manually resolve the conflicts by deleting the directories, bzr resolve should agree that they've been resolved. At present it does not and you apparently have to manually specify them.

Example:

mbp@grace% bzr st
unknown:
  .ccache/
  bzrlib/tmp.diff
  bzrlib/tests/interversionedfile_implementations/
  bzrlib/tests/revisionstore_implementations/
conflicts:
  Conflict: can't delete bzrlib/tests/interversionedfile_implementations because it is not empty. Not deleting.
  Conflict: can't delete bzrlib/tests/revisionstore_implementations because it is not empty. Not deleting.
mbp@grace% ls -la bzrlib/tests/interversionedfile_implementations/ bzrlib/tests/revisionstore_implementations/
bzrlib/tests/interversionedfile_implementations/:
total 40
drwxr-xr-x 2 mbp mbp 4096 2009-03-17 11:40 ./
drwxr-xr-x 19 mbp mbp 20480 2009-03-17 11:40 ../
-rw-r--r-- 1 mbp mbp 3573 2008-05-02 16:10 __init__.pyc
-rw-r--r-- 1 mbp mbp 10959 2008-05-02 16:10 test_join.pyc

bzrlib/tests/revisionstore_implementations/:
total 36
drwxr-xr-x 2 mbp mbp 4096 2009-03-17 11:40 ./
drwxr-xr-x 19 mbp mbp 20480 2009-03-17 11:40 ../
-rw-r--r-- 1 mbp mbp 3099 2008-05-02 16:10 __init__.pyc
-rw-r--r-- 1 mbp mbp 5608 2008-05-02 16:10 test_all.pyc
mbp@grace% rm -r bzrlib/tests/interversionedfile_implementations/ bzrlib/tests/revisionstore_implementations/
mbp@grace% bzr st
bunknown:
  .ccache/
  bzrlib/tmp.diff
conflicts:
  Conflict: can't delete bzrlib/tests/interversionedfile_implementations because it is not empty. Not deleting.
  Conflict: can't delete bzrlib/tests/revisionstore_implementations because it is not empty. Not deleting.
mbp@grace% bzr resolve
0 conflict(s) auto-resolved.
Remaining conflicts:
Conflict: can't delete bzrlib/tests/interversionedfile_implementations because it is not empty. Not deleting.
Conflict: can't delete bzrlib/tests/revisionstore_implementations because it is not empty. Not deleting.
mbp@grace% bzr bzrlib/tests/interversionedfile_implementations/ bzrlib/tests/revisionstore_implementations/

Related branches

Martin Pool (mbp) on 2009-03-17
Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Kevin Hjelden (fryguy) wrote :

This issue can be reproduced a slightly different way when switching branches. I think this is the same issue, but if not it might need to be a separate issue:

It's really annoying when creating a folder in a branch, and then switching back to a branch without that folder.

C:\dev>bzr init bug
Created a repository branch (format: unnamed)
Using shared repository: C:/dev/

C:\dev>bzr checkout bug bug-working

C:\dev>cd bug-working

C:\dev\bug-working>bzr ignore *.tmp

C:\dev\bug-working>bzr commit -m "ignoring temp files"
Committing to: C:/dev/bug/
added .bzrignore
Committed revision 1.

C:\dev\bug-working>mkdir temp

C:\dev\bug-working>echo testing > temp\123

C:\dev\bug-working>bzr add
adding temp
adding temp/123

C:\dev\bug-working>bzr commit -m "adding some working files"
Committing to: C:/dev/bug/
added temp
added temp/123
Committed revision 2.

C:\dev\bug-working>echo "binary output files from a compiler" > temp\123.tmp

C:\dev\bug-working>bzr branch \dev\bug \dev\bug-error -r1
Branched 1 revision(s).

C:\dev\bug-working>bzr switch \dev\bug-error
Conflict: can't delete temp because it is not empty. Not deleting.
Updated to revision 1.
Switched to branch: C:/dev/bug-error/

C:\dev\bug-working>bzr st
unknown:
  temp/
conflicts:
  Conflict: can't delete temp because it is not empty. Not deleting.

C:\dev\bug-working>del temp\123.tmp

C:\dev\bug-working>rmdir temp

C:\dev\bug-working>dir
 Volume in drive C has no label.
 Volume Serial Number is 5CF1-4A0D

 Directory of C:\dev\bug-working

08/06/2009 11:26 AM <DIR> .
08/06/2009 11:26 AM <DIR> ..
08/06/2009 11:19 AM 6 .bzrignore
               1 File(s) 6 bytes
               2 Dir(s) 98,402,717,696 bytes free

C:\dev\bug-working>bzr resolve
0 conflict(s) auto-resolved.
Remaining conflicts:
Conflict: can't delete temp because it is not empty. Not deleting.

C:\dev\bug-working>bzr st
conflicts:
  Conflict: can't delete temp because it is not empty. Not deleting.

Vincent Ladeuil (vila) wrote :

<poolie> i think that's a sore point for jml, and some other users

<poolie> vila: i think most ignored files are safe to delete
<poolie> i think most of the time that's what people want

<poolie> possibly the other cases could be handled by moving them to either a backup file in a parent directory

<poolie> or say .bzr/trash

<spiv> poolie: I actually think a dir in the working tree root, rather than in .bzr, would be good
<spiv> I'm not sure that hidden-by-default is even necessary, why hide the junk? I don't, though...

There are still some points to address like:
- How to name the files moved in the trash.
  We can remove the parent part of the path and add a ~n suffix not yet used there.
  That allows one to list either by name or by date to find a backup more quickly
- Maintain a file in append more listing full path/backup path associations,
- Have a trash specific filter saying things like: don't even think about keeping .pyc files !

Kevin Hjelden (fryguy) wrote :

That's a separate issue you are trying to resolve. This bug is purely that if a directory is conflicted in the manner described, and you manually delete it, it should be automatically resolved by "bzr resolve" rather than "bzr resolve path". More specifically, from my cursory look, it seems that the function workingtree:auto_resolve() should handle conflict.typestrings of type 'path conflict' (generated by Merge3Merger:cook_conflicts()), as well as 'text conflict'.

If I had more python experience, I would do it myself :(

Jonathan Lange (jml) wrote :

This bug makes bug 323111 more painful.

Jelmer Vernooij (jelmer) on 2011-02-01
tags: added: conflicts
Martin Pool (mbp) on 2011-04-01
Changed in bzr:
importance: Medium → High
assignee: nobody → canonical-bazaar (canonical-bazaar)
Alexander Belchenko (bialix) wrote :

This bug affects me as user of bzr-colo: while working with bzr colo I switch between feature branches all the time. Therefore I often get this problem with conflicted directory deletions because my editor of choice configured to left special config file in the current directory where I've invoked it. So after I've invoked my editor in newly created directory which exists only in one branch and then I switch to antoher branch in my colo workspace I get this conflict on switch. So I have to delete the directory manually and then `bzr resolve --all`. I'd happy if `bzr resolve` without options or arguments can do the right thing in my case.

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

On 4/14/2011 10:00 AM, Alexander Belchenko wrote:
> This bug affects me as user of bzr-colo: while working with bzr colo I
> switch between feature branches all the time. Therefore I often get this
> problem with conflicted directory deletions because my editor of choice
> configured to left special config file in the current directory where
> I've invoked it. So after I've invoked my editor in newly created
> directory which exists only in one branch and then I switch to antoher
> branch in my colo workspace I get this conflict on switch. So I have to
> delete the directory manually and then `bzr resolve --all`. I'd happy if
> `bzr resolve` without options or arguments can do the right thing in my
> case.
>

Do you know about Vincent's change to conflict handling?

You can set:

 bzr.transform.orphan_policy = move

And it will move those temp files that have nowhere to go into
bzr-orphans instead of leaving the directory and marking it conflicted.

You can configure it based on location/branch.conf, or just set it
globally in bazaar.conf (AFAICT).

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

iEYEARECAAYFAk2m1SEACgkQJdeBCYSNAANR7QCeNCh4uH5leMASbwaZlHP2pi/6
pjkAn3t9tieSOFPc42hPEbimCp8llHox
=lj4z
-----END PGP SIGNATURE-----

Alexander Belchenko (bialix) wrote :

John Arbash Meinel пишет:
> Do you know about Vincent's change to conflict handling?
>
> You can set:
>
> bzr.transform.orphan_policy = move
>
> And it will move those temp files that have nowhere to go into
> bzr-orphans instead of leaving the directory and marking it conflicted.
>
> You can configure it based on location/branch.conf, or just set it
> globally in bazaar.conf (AFAICT).
>

No, I wasn't aware of this improvements. Does it work with bzr 2.3?

John A Meinel (jameinel) wrote :

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

On 4/14/2011 1:13 PM, Alexander Belchenko wrote:
> John Arbash Meinel пишет:
>> Do you know about Vincent's change to conflict handling?
>>
>> You can set:
>>
>> bzr.transform.orphan_policy = move
>>
>> And it will move those temp files that have nowhere to go into
>> bzr-orphans instead of leaving the directory and marking it conflicted.
>>
>> You can configure it based on location/branch.conf, or just set it
>> globally in bazaar.conf (AFAICT).
>>
>
> No, I wasn't aware of this improvements. Does it work with bzr 2.3?

release-notes says it was introduced in bzr-2.3b2. So it should be in
all the 2.3 finals.

John
=:->

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

iEYEARECAAYFAk2m1zEACgkQJdeBCYSNAAOE6QCgxCm0MMWF9Lfq91xh53IJVffW
d2wAoLg9sCEupo3UsGcuEHsd0E/HmlUd
=YCRv
-----END PGP SIGNATURE-----

John A Meinel пишет:
>
> release-notes says it was introduced in bzr-2.3b2. So it should be in
> all the 2.3 finals.

Oh, thanks!

Martin Pool (mbp) wrote :

Of course the existence of that option doesn't fix this bug, it just makes it somewhat less likely to hit it, if you happen to know about the option.

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

On 4/15/2011 4:16 AM, Martin Pool wrote:
> Of course the existence of that option doesn't fix this bug, it just
> makes it somewhat less likely to hit it, if you happen to know about the
> option.
>

Sure, I still think this bug is open, and useful to fix. Just helping
ease Alexander's discomfort.

John
=:->

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

iEYEARECAAYFAk2n7I0ACgkQJdeBCYSNAANwdACgpPxosgpSUvVuAOtP/Dir8Ca8
b0MAoMnVlHnc/2OsDbozqgHMD+IJLzP4
=JRPU
-----END PGP SIGNATURE-----

Matthew Fuller (fullermd) wrote :

See also bug 138803.

Martin Packman (gz) on 2012-07-27
Changed in bzr:
assignee: canonical-bazaar (canonical-bazaar) → Martin Packman (gz)
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers