Mercurial - kembalikan ke versi lama dan lanjutkan dari sana


249

Saya menggunakan Mercurial secara lokal untuk sebuah proyek (itu satu-satunya repo yang tidak mendorong / menarik ke / dari tempat lain).

Sampai saat ini punya sejarah linier. Namun, hal yang sedang saya kerjakan sekarang saya sadari adalah pendekatan yang mengerikan dan saya ingin kembali ke versi sebelum saya memulainya dan menerapkannya dengan cara yang berbeda.

Saya agak bingung dengan perintah branch/ revert/ update -Cdi Mercurial. Pada dasarnya saya ingin kembali ke versi 38 (saat ini di 45) dan memiliki komitmen saya berikutnya memiliki 38 sebagai orang tua dan melanjutkan dari sana. Saya tidak peduli jika revisi 39-45 hilang untuk selamanya atau berakhir di cabang jalan buntu mereka sendiri.

Perintah / set perintah apa yang saya butuhkan?


6
Bagi siapa pun yang tertarik, ini telah muncul di bilah sisi terkait yang merupakan penjelasan bagus tentang pengembalian vs pembaruan: stackoverflow.com/questions/2506803/...
Paolo

Jawaban:


150
hg update [-r REV]

Jika nanti Anda berkomitmen, Anda akan secara efektif membuat cabang baru. Maka Anda mungkin terus bekerja hanya pada cabang ini atau akhirnya menggabungkan yang sudah ada ke dalamnya.


6
komit selanjutnya akan membuat cabang baru. Jika Anda tidak yakin, cukup buat cadangan repositori Anda (dengan copy pekerjaan), cobalah - jangan suka hasilnya -> mulai dari awal tanpa biaya
van

Ini adalah jawaban yang meragukan karena menggabungkan perubahan Anda saat ini dengan revisi lama yang mungkin bukan yang ingin Anda lakukan. Jawaban yang benar harus hg dikembalikan.
Trevor de Koekkoek

Jawabannya baik-baik saja, kecuali sedikit tentang penggabungan (Saya tidak berpikir si penanya ingin menggabungkan).
ctrl-alt-delor

3
@NeonWarge REV hanyalah pengganti untuk revisi. Ini bisa berupa nomor, hash, bookmark, dan sebagainya. Trevor: ini tidak meragukan karena tidak menggabungkan apa pun. Tidak perlu untuk.
DanMan

401

Berikut lembar contekan pada perintah:

  • hg updatemengubah revisi induk copy pekerjaan Anda dan juga mengubah konten file agar sesuai dengan revisi induk baru ini. Ini berarti bahwa komit baru akan melanjutkan dari revisi yang Anda perbarui.

  • hg reverthanya mengubah konten file dan membiarkan revisi induk salinan yang berfungsi saja. Anda biasanya menggunakan hg revertketika Anda memutuskan bahwa Anda tidak ingin menyimpan perubahan yang tidak dikomit yang Anda buat ke file dalam copy pekerjaan Anda.

  • hg branchmemulai cabang bernama baru. Pikirkan cabang bernama sebagai label yang Anda tetapkan untuk perubahan. Jadi jika Anda melakukannya hg branch red, maka perubahan berikut ini akan ditandai sebagai milik pada cabang "merah". Ini bisa menjadi cara yang bagus untuk mengatur perubahan, terutama ketika orang yang berbeda bekerja di cabang yang berbeda dan Anda kemudian ingin melihat dari mana asal set perubahan itu. Tetapi Anda tidak ingin menggunakannya dalam situasi Anda.

Jika Anda menggunakan hg update --rev 38, maka perubahan 39–45 akan dibiarkan sebagai jalan buntu - kepala menggantung seperti yang kita sebut. Anda akan mendapatkan peringatan saat Anda menekan karena Anda akan membuat "banyak kepala" di repositori yang Anda dorong. Peringatan itu ada di sana karena itu agak tidak sopan untuk meninggalkan kepala seperti itu karena mereka menyarankan seseorang perlu melakukan penggabungan. Tetapi dalam kasus Anda, Anda bisa melanjutkan dan hg push --forcekarena Anda benar-benar ingin membiarkannya menggantung.

Jika Anda belum mendorong revisi 39-45 di tempat lain, maka Anda dapat merahasiakannya. Ini sangat sederhana: dengan hg clone --rev 38 foo foo-38Anda akan mendapatkan klon lokal baru yang hanya berisi hingga revisi 38. Anda dapat terus bekerja foo-38dan mendorong perubahan baru (baik) yang Anda buat. Anda masih memiliki revisi lama (buruk) di fooklon Anda . (Anda bebas untuk mengganti nama klon sesuai keinginan Anda, misalnya fooke foo-baddan foo-38ke foo.)

Akhirnya, Anda juga bisa menggunakan hg revert --all --rev 38dan kemudian melakukan. Ini akan membuat revisi 46 yang terlihat identik dengan revisi 38. Anda kemudian akan terus bekerja dari revisi 46. Ini tidak akan membuat garpu dalam sejarah dengan cara eksplisit yang sama seperti yang hg updatedilakukan, tetapi di sisi lain Anda tidak akan mengeluh tentang memiliki banyak kepala. Saya akan menggunakan hg revertjika saya berkolaborasi dengan orang lain yang telah membuat karya mereka sendiri berdasarkan revisi 45. Jika tidak, hg updatelebih eksplisit.


2
Jawaban yang mengagumkan. Saya menggunakan hg revert --all --rev ## dan itu menyelamatkan saya: D
Van Thoai Nguyen

1
Bukankah lebih baik juga menutup cabang kepala yang menggantung? Ini akan mencegah peringatan di masa depan pada repositori. Lihat stackoverflow.com/a/3688320/900130
Zoltán

catatan: hg revert --all --rev xxx akan mengubah file lokal yang diperlukan untuk kembali dari tempat Anda berada di repo lokal Anda. Jadi, Anda perlu memperbarui sebelum ke tempat Anda ingin kembali.
Vincent

Untuk membatalkan versi sebelumnya, pertama-tama saya harus melakukan pemulihan, lalu pembaruan. Yang sedang berkata, penjelasan yang kurang buram dari kebanyakan.
CodeLurker

30

Saya baru saja menemukan kasus perlu mengembalikan hanya satu file ke revisi sebelumnya, tepat setelah saya melakukan komit dan tekan. Sintaks singkatan untuk menentukan revisi ini tidak tercakup oleh jawaban lain, jadi inilah perintah untuk melakukannya

hg revert path/to/file -r-2

Itu -2akan kembali ke versi sebelum komit terakhir, menggunakan -1hanya akan mengembalikan perubahan yang tidak dikomit saat ini.


1
Saya menemukan ini sangat berguna. Tentu saja untuk opsi -r Anda cukup memberikan nomor revisi
Alex

Anda juga dapat memilih revisi tertentu. misalnyahg revert path/to/file -r478
Matt

7

IMHO, lebih hg strip -r 39cocok dengan case ini.

Ini membutuhkan ekstensi mq untuk diaktifkan dan memiliki batasan yang sama dengan "metode replikasi kloning" yang direkomendasikan oleh Martin Geisler: Jika perubahan tersebut entah bagaimana diterbitkan, itu akan (mungkin) kembali ke repo Anda pada suatu saat karena Anda hanya mengubah repo lokal Anda.


Tidak tahu tentang yang ini. Lebih mudah dan bersih daripada menghapus dan mengkloning ulang repo. Terima kasih.
Pasang kembali Monica - notmaynard

6

Setelah menggunakannya hg update -r REV, tidak jelas dalam jawaban tentang bagaimana melakukan perubahan itu sehingga Anda bisa mendorong.

Jika Anda hanya mencoba melakukan setelah pembaruan, Mercurial tidak berpikir ada perubahan.

Saya harus terlebih dahulu membuat perubahan pada file apa pun (katakan dalam README) agar Mercurial mengakui bahwa saya membuat perubahan baru, maka saya bisa melakukan itu.

Ini kemudian menciptakan dua kepala seperti yang disebutkan.

Untuk menyingkirkan kepala lainnya sebelum mendorong, saya kemudian mengikuti langkah No-Op Merges untuk memperbaiki situasi itu.

Saya kemudian bisa mendorong.


Anda dapat melakukan commit --close-branchdi cabang lama. Anda juga push -fdapat mendorong kepala baru, tetapi ini dapat menyebabkan kebingungan yang mana kepala saat ini.
ctrl-alt-delor

5

Jawaban di atas sangat berguna dan saya belajar banyak. Namun, untuk kebutuhan saya, jawaban singkatnya adalah:

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

di mana ${1}nomor revisi atau nama cabang. Dua baris ini sebenarnya adalah bagian dari skrip bash, tetapi mereka bekerja dengan baik jika Anda ingin melakukannya secara manual.

Ini berguna jika Anda perlu menambahkan hot fix ke cabang rilis, tetapi perlu membangun dari default (sampai kami mendapatkan alat CI kami dengan benar dan dapat membangun dari cabang dan kemudian menghapus dengan cabang rilis juga).


1

Saya akan menginstal Tortoise Hg (GUI gratis untuk Mercurial) dan menggunakannya. Anda kemudian dapat klik kanan pada revisi yang Anda mungkin ingin kembali ke - dengan semua pesan komit ada di depan mata Anda - dan 'Kembalikan semua file'. Jadikan itu intuitif dan mudah bergulir ke belakang dan ke depan di antara versi fileset, yang bisa sangat berguna jika Anda ingin memastikan kapan masalah muncul pertama kali.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.