EOL filter only applied to files when first checked out

Bug #385879 reported by Adrian Wilkins
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Martin Pool
2.0
Fix Released
High
Ian Clatworthy

Bug Description

The initial checkout applies the content filtering (and you run into https://bugs.launchpad.net/bzr/+bug/362030, but that's fixed).

Subsequent updates to the branch do not apply the content filter.

Reproduce (possibly not the most streamlined way of doing this)

# On Linux
bzr init one --1.14
cd one
echo -e "one\ntwo" > test.txt
bzr add
bzr commit -m "One"

# On Windows
Edit %appdata%\bazaar\2.0\rules to contain
[name *.txt]
eol = native

bzr co bzr+ssh://linux_box/one
cd one
bzr st
# "text.txt" is listed as changed ; #362030 - already known and fixed
# open file in notepad2 or other modern editor and you see it has CRLF endings

# Linux
echo -e "three\nfour" > test2.txt
bzr add
bzr commit -m "Two"

# Windows
bzr up # test2.txt is added
bzr st
# Still only test.txt is changed
# open test2.txt and it has LF endings

Related branches

Changed in bzr:
assignee: nobody → Ian Clatworthy (ian-clatworthy)
Changed in bzr:
importance: Undecided → High
status: New → Confirmed
Changed in bzr:
status: Confirmed → In Progress
Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

Adrian,

If you get a chance, please give the linked branch a *quick* test and let me know if it improves things. (I've done next to no testing on the branch but I think/hope it's in the right direction.)

If it proves successful, I'd be curious as to how many edge cases it solve. As well as update, it might also fix similar problems with merge and pull? And for good measure, hopefully it does the "right thing" w.r.t. generation of conflict-related files (x.THIS, x.OTHER, x.BASE)?

Revision history for this message
Matthew Fuller (fullermd) wrote :

(note that I'm testing keywords, not EOL)

Compared to bzr.dev, the linked branch makes the keywords update on 'pull' (and so presumably on operations like 'update' too). However, rm'ing the file and revert'ing still leaves them collapsed, and committing leaves them completely untouched (so now they're expanded, AND wrong).

Martin Pool (mbp)
tags: added: content-filtering
Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

The linked branch now has a fix for revert. It also has explicit tests for pull, merge, switch and revert.

Up until now at least, it's been an explicit design choice that commit:

* would apply 'read' filtering to get the content to be committed
* wouldn't apply 'write' content filtering and update the working tree.

The feeling was that content filters requiring the latter ought to register a post-commit-hook. I'll look at adding one of those to the keywords plugin.

Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

Bug 408841 covers the keyword expansion issue.

Changed in bzr:
milestone: none → 2.0
status: In Progress → Fix Committed
Changed in bzr:
milestone: 2.0 → 2.0rc2
Martin Pool (mbp)
Changed in bzr:
assignee: Ian Clatworthy (ian-clatworthy) → Martin Pool (mbp)
Changed in bzr:
milestone: 2.0 → none
status: Fix Committed → In Progress
Revision history for this message
Martin Pool (mbp) wrote :

I want to reclassify this as not a blocker for 2.0 because it seems likely there will be more bugs here, necessitating either individual squashing or a larger systematic change. That's worth doing, and worth doing in the 2.0 series, but not something I want to block 2.0 on.

Changed in bzr:
status: In Progress → Fix Released
John A Meinel (jameinel)
Changed in bzr:
milestone: none → 2.1.0b4
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.