##// END OF EJS Templates
transaction: actually delete file created during the transaction on rollback...
transaction: actually delete file created during the transaction on rollback Transaction currently has two modes: - one where file created during the transaction are deleted on rollback, - one where file created during the transaction are truncated to 0 on rollback. Before this change, `hg rollback` and `hg recover` are using the "delete" mode and transaction abort is using the "truncate" option. This difference is never really explained. A long time ago, there was two code paths, with this divergence existing for unclear reasons. When the two code paths got merged into a single one, a boolean argument have been added to preserve this divergence, mostly probably as a cargo cult. The divergence is weird and induce bad surprises, and the truncate behavior is a bit odds, introducing other bad surprises (e.g. 08ecbdba186f) So solve this, we stop using the "truncate" behavior and unify on the "delete" behavior. Despite being currently more "common", the truncate behavior seems less natural, resulting in the transaction leaving empty file around. This is landed on default, early in the cycle, to help us catch problems that could emerge.

File last commit:

r46195:426294d0 default
r51703:5c3d0795 default
Show More
runcommand.rs
66 lines | 2.4 KiB | application/rls-services+xml | RustLexer
// Copyright 2018 Yuya Nishihara <yuya@tcha.org>
//
// This software may be used and distributed according to the terms of the
// GNU General Public License version 2 or any later version.
//! Functions to run Mercurial command in cHg-aware command server.
use bytes::Bytes;
use std::io;
use std::os::unix::io::AsRawFd;
use tokio_hglib::codec::ChannelMessage;
use tokio_hglib::{Connection, Protocol};
use crate::attachio;
use crate::message::{self, CommandType};
use crate::uihandler::SystemHandler;
/// Runs the given Mercurial command in cHg-aware command server, and
/// fetches the result code.
///
/// This is a subset of tokio-hglib's `run_command()` with the additional
/// SystemRequest support.
pub async fn run_command(
proto: &mut Protocol<impl Connection + AsRawFd>,
handler: &mut impl SystemHandler,
packed_args: impl Into<Bytes>,
) -> io::Result<i32> {
proto
.send_command_with_args("runcommand", packed_args)
.await?;
loop {
match proto.fetch_response().await? {
ChannelMessage::Data(b'r', data) => {
return message::parse_result_code(data);
}
ChannelMessage::Data(..) => {
// just ignores data sent to optional channel
}
ChannelMessage::InputRequest(..)
| ChannelMessage::LineRequest(..) => {
return Err(io::Error::new(
io::ErrorKind::InvalidData,
"unsupported request",
));
}
ChannelMessage::SystemRequest(data) => {
let (cmd_type, cmd_spec) = message::parse_command_spec(data)?;
match cmd_type {
CommandType::Pager => {
// server spins new command loop while pager request is
// in progress, which can be terminated by "" command.
let pin = handler.spawn_pager(&cmd_spec).await?;
attachio::attach_io(proto, &io::stdin(), &pin, &pin)
.await?;
proto.send_command("").await?; // terminator
}
CommandType::System => {
let code = handler.run_system(&cmd_spec).await?;
let data = message::pack_result_code(code);
proto.send_data(data).await?;
}
}
}
}
}
}