Bazaar should cleanly handle added files that are identical to existing unversioned files

Bug #90569 reported by Mark Shuttleworth
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned
Breezy
Triaged
Medium
Unassigned

Bug Description

I saw this today:

lrwxrwxrwx 1 mark mark 32 2007-03-08 06:48 mechanize -> ../sourcecode/zope/src/mechanize
lrwxrwxrwx 1 mark mark 32 2007-03-03 15:16 mechanize.moved -> ../sourcecode/zope/src/mechanize

the backstory is that I needed to add that symlink to make things work on Feisty so I did, but left it unversioned then someone added an identical symlink to the tree when i merged, i got a conflict. i would understand that if the unversioned symlink I added was different to the new, versioned one, but in fact they are identical.
imo this should "Just Work" - bzr should see the added symlink is identical to the unversioned one there, and "merge cleanly"

Tags: conflicts
Revision history for this message
Aaron Bentley (abentley) wrote : Re: [Bug 90569] Bazaar should cleanly handle added files that are identical to existing unversioned files

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

Mark Shuttleworth wrote:

> the backstory is that I needed to add that symlink to make things work on Feisty so I did, but left it unversioned then someone added an identical symlink to the tree when i merged, i got a conflict. i would understand that if the unversioned symlink I added was different to the new, versioned one, but in fact they are identical.
> imo this should "Just Work" - bzr should see the added symlink is identical to the unversioned one there, and "merge cleanly"

This is certainly possible in principle. It probably requires a new way
to get the SHA1 or symlink target of mechanize, i.e.
TreeTransorm.get_content_hash()

We should also consider whether reverting in your scenario should delete
the symlink, and, if not, how to prevent it.

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

iD8DBQFF8Bti0F+nu1YWqI0RAp9fAJ0bTsCY/0ztqHYKub6yWZQFVWzwWgCfZX4p
qiWRQ4xEMUFtPkJcbuV1uAc=
=dcCx
-----END PGP SIGNATURE-----

Aaron Bentley (abentley)
Changed in bzr:
importance: Undecided → Medium
John A Meinel (jameinel)
Changed in bzr:
status: Unconfirmed → Confirmed
Revision history for this message
Stefan Monnier (monnier) wrote :

Actually we could generalize this idea and do a 2-way merge: if the two files are identical, it behaves as the OP wants, and otherwise you get a new file with some conflicts.
It may not always be a good idea, but at least in my use case, it would DTRT in 99% of the cases since conflicts between new versioned files and pre-existing unversioned files are almost always due to a change where a file becomes versioned.

Revision history for this message
Torsten Bronger (bronger) wrote :

What about the case if both files are versioned? I merged an SVN branch into an identical Bazaar branch and got tons of conflicts. I think such conflicts should be handled automatically as well.

Jelmer Vernooij (jelmer)
tags: added: conflicts
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.