transaction: use the standard transaction mechanism to backup branch
Branch is a bit special : - It currently does not collaborate with the transaction (or any scoping) for writing (this is bad) - It can change without the lock being taken (it is protected by `wlock`) So we rely on the same mechanism as for the backup of the other dirstate file: - we only do a backup if we hold the wlock - we force a backup though the transaction We have to do horrible things to the transaction in the meantime. This could go away once we integrate `setbranch` with the transaction. A Task that does not seems too complicated, but this is not the right time to do it. This regress the warning message for the legacy fallback introduced in 2008 when issue902 got fixed in dd5a501cb97f (Mercurial 1.0). I feel like this is fine as issue 902 remains fixed, and this would only affect people deploying a mix of 15 year old Mercurial and modern mercurial, and using branch and rollback extensively.
Showing
- mercurial/localrepo.py 10 additions, 17 deletionsmercurial/localrepo.py
- mercurial/transaction.py 7 additions, 1 deletionmercurial/transaction.py
- tests/test-fncache.t 0 additions, 2 deletionstests/test-fncache.t
- tests/test-hardlinks.t 0 additions, 2 deletionstests/test-hardlinks.t
- tests/test-inherit-mode.t 0 additions, 2 deletionstests/test-inherit-mode.t
- tests/test-rollback.t 3 additions, 13 deletionstests/test-rollback.t
Loading
Please register or sign in to comment