도움말:문서 역사 합치기

최근 편집: 2017년 11월 1일 (수) 20:18
번역 중 이 글은 번역 중입니다. 번역을 도와주세요.

복사 붙여넣기로 문서 이름을 바꾼 것을 고치기

번역 원본은 https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves&oldid=807452901#Using_the_MergeHistory_special_page 입니다

복사와 붙여넣기를 이용하여 문서를 이동할 경우 문서의 역사와 토론 문서 등이 여럿으로 찢어지는 결과를 가져올 수 있습니다. 또한 저작권 표시를 위해서도 이런 방식은 적절하지 않습니다.

이런 상황에서 관리자는 종종 아래에 나와 있는 것과 같은 순서로 문서 역사를 합쳐야 합니다.

문서 역사 합치기를 위해 태그 달기

  1. {{Histmerge|(내용을 가져온 문서 이름)}}을 새 문서에 추가하십시오
  2. 토론 등을 통해 이를 알리는 것을 고려해 보십시오.

In cases where additional edits were made to the original version after the copy-and-paste and which the additional edits can all be safely discarded (e.g. WP:WPAFC-related templates, edits which were reverted, etc.), place {{Histmerge|NAME OF PAGE THE ARTICLE WAS CUT FROM|reason=|details=}} at the new location as described above. Fill in the two parameters as needed for this particular situation (see {{histmerge}} for an example).

만약 복사된 시점으로부터 원본 문서와 붙여넣어진 문서의 리비전 모두 변경 사항이 없다면 임시 삭제를 위해 붙여 넣은 페이지에 {{db-copypaste}}를 이용하여 태그하는 것을 고려하고, (WP:Speedy deletion#G6 참조) 문서를 적절히 이동하십시오. Special:ComparePages or a similar tool should be used to verify that no changes have been made.

교정 과정(관리자를 위한)

역사 합치기 특수 문서를 이용하기

관리자는 문서 역사를 합치기 위해 특수:역사합치기를 사용할 수 있습니다. 이 방법은 수작업과는 다음과 같은 차이가 있습니다.

  1. It automatically detects the latest version of the source page which is older than the oldest version of the target page, and won't allow the user to move later revisions. This feature is good if the source page eventually became something else, but can be bad if the target page had started out as a redirect to the source.
  2. The user can, however, tell it to only move earlier revisions than that – it is possible to select the latest revision it should move.
  3. It doesn't mix deleted and non-deleted versions of the target page.
  4. It retains any protection the target page may have.
  5. It doesn't create a new revision of the old page.
  6. If the user moves all non-deleted revisions of the source, a hard redirect is automatically created. This can't be overridden.
  7. The logs for this action aren't in the move log - they're in a separate log.

수작업

Warning: this procedure may only be undone by spending quite silly amounts of time. To undo a merge, see below. Do not do this if you're not sure what you're doing.

간단한 경우

Steps for a simple case
Steps for a simple case

The following procedure merges the page histories in the case of a hypothetical example:

Suppose Alabama/History (old title) was the only article on that subject, and that the article developed in the course of a number of edits, until a decision that History of Alabama (new title) was a better style of name for the article. Suppose further that for whatever reason, the contents of the old article were

  • cut from the old article,
  • replaced in it with a redirect to the new title, and
  • pasted into a newly created article bearing the new title.

(That is, the move tool was not available or not used to simultaneously transfer the Wiki text and the history of edits to the new title.) And suppose this replacement (new-title) article develops further and reflects the new history of these further edits. Our goal is to graft the (old) edit history from Alabama/History (article with old title) onto the new history in History of Alabama (article with new title) where those partial histories can complement each other. The process is as follows:

  1. Move Alabama/History to History of Alabama, using the move tool. The admin approves deletion of History of Alabama to allow the move. (Now the old versions are the whole of the new title's history.)
  2. Undelete the History of Alabama article, by
    1. Viewing the Page history,1
    2. Linking via "View or restore ... deleted edits?", and
    3. Clicking on "Restore". (Now the new title's history has both the old and new versions, including an extra copy of the most recent version of Alabama/History, created by the move tool.)
  3. At this stage, History of Alabama will only show the text "#redirect History of Alabama" (assuming a redirect was the most recent version of Alabama/History, the History of Alabama page will now be showing whatever the most recent version of Alabama/History was). The last step is to revert to the last version of History of Alabama from before the move, by
    1. Linking via "Page history" on History of Alabama.
    2. Make a hard reload (Shift+Control+R in Mozilla or Opera, Ctrl+F5 in Internet Explorer, and Ctrl+R in Firefox) to see an up-to-date history reflecting the undeletion.1
    3. Reverting to the last pre-move version.

Merging page histories of pages with many revisions

Suppose that the page History of Alabama had too many revisions to be deleted or deleting it may cause other disruption. The following procedure can be used to merge page histories in this situation:

  1. Move History of Alabama to Alabama/History with a move summary like "history merge, will be back at correct title soon". Answer yes when asked to delete the Alabama/History page.
  2. Undelete the revisions of Alabama/History containing the page history.
  3. Move Alabama/History back to History of Alabama.
  4. If needed, undelete the remaining revisions at Alabama/History.

좀 더 복잡한 경우

Sometimes, after a cut-and-paste move is performed, the article at the old title is then edited for some other purpose (e.g., turning it into a disambiguation page). That causes the article now at NewTitle to have part of its history there, and part at OldTitle, but the history at OldTitle also contains the history of NewMeaning. Use of the selective deletion function allows these to be repaired as well.

Steps for a complex case
Steps for a complex case

To select more than one revision for undeletion, click on the tick box of the first revision to be undeleted, then shift-click on the last revision to be undeleted. Every intermediate revision will then be selected.

An example of this was Military of Japan; the original was moved to Japan Self-Defense Forces with a cut-and-paste move, and the article Military of Japan was then turned into a disambiguation page. This was repaired with the following procedure:

  1. Military of Japan is deleted.
  2. Selective undelete is used to undelete only those versions of Military of Japan which belonged to "Japan Self-Defense Forces".
  3. The versions of "Japan Self-Defense Forces" at Military of Japan are moved to Japan Self-Defense Forces, using the normal page-move function. For this to happen, Japan Self-Defense Forces must be deleted, although this can be done as part of the move.
  4. Undeletion of Japan Self-Defense Forces restores the rest of the versions of that article to its history.1
  5. However, the most recent version in the history of Japan Self-Defense Forces is now the most recent version of the old history from Military of Japan (it's a copy of that version, created by the page-move function). So, go into the history of Japan Self-Defense Forces, select the next-most-recent version, click on it, and when it appears, click on "Edit this page", ignore the "WARNING: You are editing an out-of-date revision" message, type something suitable (e.g., "restoring most recent version after merging histories") in the edit summary, and hit "Save page". That article is now restored to its condition prior to this procedure, and now also has its complete history.
  6. Step 3 above (the move) will have left a history containing just a redirect at Military of Japan. Delete the redirect.
  7. Undeletion of all the other versions of Military of Japan restores the more recent history of that article; no additional steps are needed, as the most recent version should now be the current version.1

문제가 되는 경우

However, the examples just described only work well if the two pieces of the history of one 'article' are disjoint; i.e. one ends before the other begins. These procedures are inadequate if this condition does not apply, e.g., if the copy of the article at the old title has been edited after the pasting of its contents into the new title. For example, it is not uncommon for:

  1. an article at (old) page A to be cut and pasted into (new) page B, and
  2. page A later to be reverted to an article on the same topic, with a sequence of edits there as well.

In this case, the time periods of the two series of edits will overlap.

If someone then page-history merges pages A and B using the method described above, the result will sequence the versions of A and B strictly by time, with the result that various versions of A will be interleaved between versions in the page history of page B (and/or vice-versa). Inspecting this merged history without means of distinguishing between the two overlapping progressions (since nothing in this history indicates which version belongs to which sequence) invites severe confusion.

An appropriate procedure for such a case is to forego the history merge, and instead handle the situation much like a normal merge; put a note pointing to the other version of the page on the article's talk page. If it is inappropriate to leave the second copy in the main article space, you can archive the duplicate page to Talk: space (i.e. by moving it to some suitable title, such as Talk:RandomArticle/OldVersion).

Parallel versions

Users sometimes send in an ill-advised history-merge request after the two pages involved have been text-merged. If the two pages have separate origins and simultaneous separate parallel histories before they were text-merged, they should not be history-merged, as that would shuffle the parallel editing histories together in one list and make a mess. There is an example in this edit of page Clemson Tigers football. There is an example with 5 incoming pages in this edit of page Wikipedia talk:WikiProject Emo. The best thing to do would be to use the {{Copied}} template and place it on the source and/or destination's talk page.

Also, if page A is to be history-merged into page B, before the process, make sure that there are no deleted edits in page B, as then deleting B will shuffle the deleted and non-deleted edits attached to the page together. The deleted history should first be rescued from under B by some process such as this: Move B to some other name, say B_zxcvbnm (without making a redirect). Undelete B. Move B to some other name, say B/old_version . If necessary, re-delete B/old_version . Move B_zxcvbnm back to B (without making a redirect).

Likewise, if a page must be deleted and then partly undeleted for a history-split, first check in case it is sitting over a deleted parallel history.

History splitting

Over time, articles may change from one underlying topic to a completely separate topic. Normally this should be accomplished through moves and disambiguation pages. However, if a user is unfamiliar with those processes they may simply change the topic of an article (overwriting the old) and continue editing. If this is not caught immediately it is very easy for the new topic to build up a substantial edit history of its own. Admins can use the following steps to fix this problem and maintain separate histories for the separate topics:

  1. Delete the article (original article name)
  2. Restore previous revisions up to (but not including) the point where the topic was changed.
  3. Move [without redirect] the restored versions (old topic) to a new name (see also disambiguation)
    • If there is already an article under the new name and you wish to histmerge into it:
    a) select the "delete the existing article" option, while moving;
    b) restore deleted revisions of new name.
  4. Restore new revisions of new topic (still at original article name)
  5. Revert to latest good versions as needed
  6. Establish a disambiguation page for the different topics

How to handle the left-over redirect

In most cases, you will be moving all non-redirect versions of one page into the history of another and leaving a redirect. Please keep the following situations in mind when deciding what to do with the redirect:

  • Is the resulting redirect eligible for speedy deletion (see WP:SPEEDY#General and WP:SPEEDY#Redirects)? As with regular page moves, consider waiting a few days before deleting the leftover redirect even if it is eligible for speedy deletion.
  • Are all incoming links to the leftover redirect fixed? If not, don't delete the redirect until they are.
  • Is it likely the most recent editors of the moved revisions are watchlisting the page? Consider notifying them of the change.
  • Is the leftover redirect in User: or User_talk: space? If you do delete it, notify the affected user unless there is a good reason not to. Consider leaving the redirect unless doing so would cause problems, such as in the case of:
    • A redirect from the "main" user page or "main" user talk page to somewhere other than another page in that user's userspace.
    • A redirect to another user's pages or non-user space in a way that may cause confusion or is otherwise inappropriate.

History-merging a transcluded page

If page X is transcluded in page Y, and page X is marked to be the recipient in a history-merge, then page X and page Y will both appear in Category:Candidates for history merging, and both pages will display the request to perform a history-merge. An admin should not try to perform a history-merge on page Y, but only on page X. This is most likely to happen if page X is a template, but it may happen to any page that is transcluded. To avoid this, {{histmerge}} should be placed in <noinclude> tags on page X.

문서 역사 합치기를 되돌리는 방법

If a history merge should not have been performed, then it may be undone. Note, however, that it can be quite tedious, especially if the article has a very long history. The following procedure is listed:

  1. Suppose A has been history merged into B.
  2. We want to get A's former history back into A.
  3. Delete B.
  4. Selectively undelete the revisions of B that made up the history of A before the history merge.
  5. Move B to A.
  6. Undelete the rest of the revisions of B.
  7. If A and/or B is now a redirect to itself or the other article, then revert or change the redirect target, as deemed appropriate.

An example of a successful history merge and undo is available at User:King of Hearts/Sandbox/6 (the A article) and User:King of Hearts/Sandbox/7 (the B article).

Bugs

Note: Due to some minor bugs in the MediaWiki code, article histories may seem to contain anomalies after performing some of the procedures listed below. They are not actual database errors, the underlying data is correct; they are just problems with the information displayed. See #Lost history bug for information about these seeming anomalies, and how to deal with them.

Lost history bug

After a history merge, the following peculiarity may be observed: after a successful undeletion, article histories may seem either:

  • to be missing the recently restored versions, or
  • to show the complete original history after a deletion/partial-restoration cycle, including versions which are actually still deleted.

These errors persist even if the browser's "Refresh" button is clicked. These do not seem to be actual database errors, and the underlying data is correct; they are just problems with the information displayed. Note that there seems to be no consistency as to which (if either) of these bugs will appear—expect to see either, or neither.

For some users, however, the bug can be cleared with a combination of purging and bypassing browser cache.

Work around

To see the correct, current, history of the article, select a different history length, e.g., "last 20" or "last 100", instead of the default 50. (Note that this trick only works once; if you do another restore, and the history is messed up again, you will need to select a different, previously unused length, to see the correct, current, history.)

Also, making an edit on the page just moved will force the correct history to be shown, so if you have to perform an edit on the target page for some other reasons (e.g., to restore the most recent version, step 4.3 above), this will make the correct history appear. Alternatively, if you don't want to leave things so that a naive user will be confused, make a dummy edit to the page, which will update the history.

Former bugs

Previous versions of the Wikimedia software displayed other, similar issues:

  • The success of the undeletion may be announced, but its results not be observable for a while, until the slave servers catch up to the master.
  • The merged history may have all the versions of the two formerly separate articles, but without the most recent being shown at the top of the history list, and without the most recently edited version being delivered by the server, until a further edit is made to the article.
  • It sometimes happens that viewing the history in step 3.1 shows the history of the just deleted page, not the history of the page just moved.

These bugs do not seem to be happening any more, but it's worth keeping an eye out for them.