참고 : 내 대답은 Aptana와 관련이 없으며, 대신 귀하의 문제가 무엇인지에 대해 설명합니다.
주된 문제는 Mercurial이 변경 사항을 저장하는 방법에 대한 오해이며 Subversion 배경에서 오는 것이 완전히 합리적이라고 생각합니다.
Subversion에서는 변경 기록이 파일별로 저장되는 것으로 간주 될 수 있습니다. 즉, 두 파일을 변경하고 커밋하면 작업 복사본의 파일이 서로 다른 버전에있는 상황을 쉽게, 때로는 할 수 있습니다.
Mercurial에서 변경 기록은 전체 저장소에 저장됩니다. 커밋하면 그 당시 전체 저장소의 상태를 저장하는 새로운 "변경 집합"이 만들어집니다. push을 다른 저장소로 변경하면 모든 변경 사항 (또는 추가 또는 삭제 또는 ...)이 해당 변경 사항과 함께 푸시됩니다.
저장소에 새로운 변경 집합 commit을 선택하면 파일을 선택적으로 포함하거나 제외 할 수 있습니다. 포함되지 않은 파일은 새 변경 집합에서 커밋 될 수있는 보류중인 수정으로 작업 복사본에 남아 있습니다.
나는 그것이 당신을 이해할 수 있기를 바랍니다. 만약 당신이 이미 그것을 이해한다면 그것은 논리적 인 개념이지만, 설명하기가 까다 롭습니다.
그럼, 문제가 있습니다.
저장소에 두 개의 파일, file1 및 file2 (그 또는 foo 및 bar)이 있다고 가정 해 보겠습니다. 당신은 그들 모두를 변경했습니다,하지만 그들은 다른 문제와 관련 - 서로 다른 변경 집합으로 최선을 다하고 할 수 있습니다
다음
$ hg log
changeset 0:....
summary: First commit
$ hg st
M file1
M file2
$ hg commit -I file1 -m "Changed file1"
$ hg log
changeset 1:....
summary: Changed file1
changeset 0:....
summary: First commit
$ hg st
M file2
우리가 저장소에 하나 개의 파일 만 약속 한 것을 볼 수 있습니다, 그것을 새로운을 만들어졌다 그 때 리포지터리 (repository)의 완전한 상태와 함께 변경 세트 -을 변경하면 file2가됩니다. 이제 우리는 동일한 변경 작업을 수행 할 file2 커밋을 할 수 있습니다. 이 접근 방식의 문제점은 변경 집합이 부모에 따라 정렬된다는 것입니다. 따라서 file2으로 변경하는 것만으로도 부모를 밀어 넣지 않고도 push을 쉽게 변경할 수는 없지만 나중에 변경 한 것일 수 있습니다.
TL : DR : SVN은 개별 파일의 상태를 저장하며, Mercurial은 저장소 전체의 상태를 저장합니다.
나는 매우 독서하는 것이 좋습니다 Mercurial: The Definitive Guide.구식 이라기보다는 구식이긴하지만 개념을 이해하는 것이 훨씬 더 효과적 일 것이라고 생각합니다.