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

Bug #90569 reported by Mark Shuttleworth on 2007-03-08
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned
Breezy
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"

-----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) on 2007-03-13
Changed in bzr:
importance: Undecided → Medium
John A Meinel (jameinel) on 2007-05-22
Changed in bzr:
status: Unconfirmed → Confirmed
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.

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) on 2011-02-01
tags: added: conflicts
Jelmer Vernooij (jelmer) on 2017-11-08
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2019-01-28
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  Edit
Everyone can see this information.

Other bug subscribers