revert breaks hard links in the same tree

[Christian Faulhammer]

Commit does support hard links and keeps them, but when using revert the linking just vanishes.

This is what I did in detail. In the last diff you can see that the hard links disappeared.

fauli@sol /tmp/test $ touch test
fauli@sol /tmp/test $ ln test test.1
fauli@sol /tmp/test $ ln test test.2
fauli@sol /tmp/test $ ln test test.3
fauli@sol /tmp/test $ bzr init .
Created a standalone tree (format: 2a)
fauli@sol /tmp/test $ bzr add test*
adding test
adding test.1
adding test.2
adding test.3
fauli@sol /tmp/test $ bzr commit -m "Add"
Committing to: /tmp/test/
added test
added test.1
added test.2
added test.3
Committed revision 1.
fauli@sol /tmp/test $ bzr status
fauli@sol /tmp/test $ echo Test > test
fauli@sol /tmp/test $ bzr diff
=== modified file 'test'
--- test 2010-08-18 10:42:10 +0000
+++ test 2010-08-18 10:42:23 +0000
@@ -0,0 +1,1 @@
+Test

=== modified file 'test.1'
--- test.1 2010-08-18 10:42:10 +0000
+++ test.1 2010-08-18 10:42:23 +0000
@@ -0,0 +1,1 @@
+Test

=== modified file 'test.2'
--- test.2 2010-08-18 10:42:10 +0000
+++ test.2 2010-08-18 10:42:23 +0000
@@ -0,0 +1,1 @@
+Test

=== modified file 'test.3'
--- test.3 2010-08-18 10:42:10 +0000
+++ test.3 2010-08-18 10:42:23 +0000
@@ -0,0 +1,1 @@
+Test

fauli@sol /tmp/test $ bzr commit -m "Test"
Committing to: /tmp/test/
modified test
modified test.1
modified test.2
modified test.3
Committed revision 2.
fauli@sol /tmp/test $ echo Test >> test
fauli@sol /tmp/test $ bzr diff
=== modified file 'test'
--- test 2010-08-18 10:42:30 +0000
+++ test 2010-08-18 10:42:34 +0000
@@ -1,1 +1,2 @@
 Test
+Test

=== modified file 'test.1'
--- test.1 2010-08-18 10:42:30 +0000
+++ test.1 2010-08-18 10:42:34 +0000
@@ -1,1 +1,2 @@
 Test
+Test

=== modified file 'test.2'
--- test.2 2010-08-18 10:42:30 +0000
+++ test.2 2010-08-18 10:42:34 +0000
@@ -1,1 +1,2 @@
 Test
+Test

=== modified file 'test.3'
--- test.3 2010-08-18 10:42:30 +0000
+++ test.3 2010-08-18 10:42:34 +0000
@@ -1,1 +1,2 @@
 Test
+Test

fauli@sol /tmp/test $ bzr revert
 M test
 M test.1
 M test.2
 M test.3
fauli@sol /tmp/test $ echo Test >> test
fauli@sol /tmp/test $ bzr diff
=== modified file 'test'
--- test 2010-08-18 10:42:30 +0000
+++ test 2010-08-18 10:42:45 +0000
@@ -1,1 +1,2 @@
 Test
+Test

$ bzr --version
Bazaar (bzr) 2.2.0
  Python interpreter: /usr/bin/python2.6 2.6.5
  Python standard library: /usr/lib/python2.6
  Platform: Linux-2.6.34-gentoo-r1-i686-AMD_Athlon-tm-_X2_Dual_Core_Processor_BE-2400-with-gentoo-2.0.1
  bzrlib: /usr/lib/python2.6/site-packages/bzrlib
  Bazaar configuration: /home/fauli/.bazaar
  Bazaar log file: /home/fauli/.bzr.log

[Robert Collins (lifeless)]

This is a feature, in a few ways.

One is that we're as close to transactional as we can get on the
revert, which involves writing new files and renaming them into place.
Secondly, we create backup files in the most efficient way we know of
- we rename the existing file to the backup file name.
Lastly, w e don't disrupt other checkouts which are hardlinked
together (that can be create using branch --hardlink if I remember
correctly).

We could perhaps add an option for folk that don't want these guarantees.

-Rob

[Martin Pool (mbp)]

Interesting bug.

When we commit them, we don't remember that they're hard links to each
other in the way we do with symlinks. As far as bzr is concerned this
is just a quirk of your working tree. In a fresh checkout, would you
want to get them back as hardlinks? Or do you just want revert not to
break the links?

[Christian Faulhammer (fauli)]

Thank you for the explanations. At least I want revert not to break the hard links, for my local use case this is enough as it is my personal repository that will not get cloned by anybody. But in general I would really love to keep hard links, although this can be hard for file systems that don't support hard links.

[John A Meinel (jameinel)]

I'm not entirely sure that this isn't won't fix, but in the short term, someone certainly does want this.

I think the main problem is that it changes the code from "write the new content, rename into place" into "truncate the existing content, overwrite it with new content".

Note that lots of other commands also do the rename dance. "bzr merge" for example. It seems a bit surprising that you want to actually change the content in another tree when you change the content in this one. How are you specifically using the --hardlink feature?

[Christian Faulhammer (fauli)]

There is a file in my root directory of the clone, whose contents I want in several subdirectories. So a change from the root should propagate to all subdirs by using a hard link, this way I only have to edit one file and not 20. A workaround would be an \input from root (it is a TeX file).

[Andrew Bennetts (spiv)]

John A Meinel wrote:
> Note that lots of other commands also do the rename dance. "bzr merge"
> for example. It seems a bit surprising that you want to actually change
> the content in another tree when you change the content in this one. How
> are you specifically using the --hardlink feature?

They don't want to change the content in other trees: these are intra-tree
links, not inter-tree links.

[Vincent Ladeuil (vila)]

Your use case *screams* symlinks to my ears. Why are you using hard links here ? Or even \input the right file ?
(Supporting intra-tree hard links will be non-trivial so I'd like to better understand the use case here).

[Christian Faulhammer (fauli)]

Why I use hard links? Because I can. Moving the files around does not change their contents, they are not as fragile as symlinks or input via path statements. So if you cannot support them easily, warn the user about it.

Sorry for the inaccurate bug summary.