때때로 발생하는 질문은 Perforce에서 마지막으로 동기화 한 변경 목록을 결정하는 가장 좋은 방법입니다. 이는 자동 빌드 시스템에 의해 개정 정보에 변경 목록 번호를 삽입하는 것과 같은 작업에 종종 필요합니다.
답변
자동 빌드 시스템의 경우 반대를 권장합니다. 먼저 다음을 사용하여 서버에서 최신 변경 목록을 가져와야합니다.
p4 changes -s submitted -m1
그런 다음 해당 변경 사항을 동기화하고 개정 정보에 기록하십시오. 그 이유는 다음과 같습니다. Perforce 는 작업 영역이 동기화되는 변경 목록을 결정하기 위해 다음 을 권장 하지만 :
p4 changes -m1 @clientname
몇 가지 문제점이 있습니다.
- 이것은 문제의 작업 공간에서 아무것도 제출하지 않은 경우에만 작동합니다.
- 클라이언트 작업 영역이 특정 변경 목록과 동기화되지 않을 수도 있습니다.
그리고 그들이 언급하지 않은 추가 문제가 있습니다.
- 동기화가 발생한 가장 높은 변경 목록이 작업 공간에서 파일을 엄격하게 삭제 한 경우 다음으로 높은 변경 목록이보고됩니다 (엄격하게 삭제 된 파일도 제외).
먼저 동기화하고 나중에 기록해야하는 경우 Perforce는 다음 명령을 실행하여 위의 문제가 발생했는지 확인하도록 권장합니다. 동기화되거나 제거 된 항목이 없음을 나타내야합니다.
p4 sync -n @changelist_number
답변
기술 스 니펫을 보관하는 장소로 Stackoverflow를 사용하라는 Jeff의 제안에 따라이 질문에 직접 답하기 위해 ….
명령 줄에서 다음을 사용합니다.
p4 changes -m1 @<clientname>
그리고 클라이언트 사양의 이름으로 바꿉니다. 그러면 다음과 같은 형식의 출력이 생성됩니다.
Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'
변경 목록 번호를 추출하기 위해 쉽게 구문 분석됩니다.
답변
“p4 files”명령의 출력에서 최대 변경 수를 찾아 볼 수 있습니다. 하지만 작업 디렉토리에는 동기화 후 커밋이 포함되어서는 안됩니다. 이것은 단지 조금 낫다
p4 changes -m1 "./...#have"
후자는 서버에서 실행되는 것처럼 보이고 “MaxResults”제한으로 인해 큰 소스 트리에서 실패 할 수 있습니다.
$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.
$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657
여기서 p4lastchange.py는 2005 년 4 월 15 일 Kodak Information Network / Ofoto의 JTGoldstone에서 P4G.py를 명령 줄에서 사용 프레젠테이션 의 코드를 기반으로합니다 .
#! /usr/bin/env python
import sys, os, marshal
if os.name == "nt":
# Disable newline translation in Windows. Other operating systems do not
# translate file contents.
import msvcrt
msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )
lastcl = 0
num = 0
try:
while 1:
dict = marshal.load(sys.stdin)
num = num + 1
for key in dict.keys():
# print "%s: %s" % (key,dict[key])
if key == "change":
cl = int(dict[key])
if cl > lastcl:
lastcl = cl
except EOFError:
pass
print "Files: %s" % num
print lastcl
답변
P4V를 사용하는 경우 그래픽으로이를 수행 할 수 있습니다.
- 대시 보드 탭 (보기-> 대시 보드)에서 폴더를 선택하면 폴더가 아직 업데이트되지 않은 변경 목록 목록이 표시됩니다. 가장 낮은 숫자 (가장 높은 행)를 기록합니다.
- 작업 공간 트리에서 이전에 대시 보드에서와 동일한 폴더를 선택했는지 확인하십시오. 그런 다음 기록 탭 (보기-> 기록)으로 이동하여 이전에 기록한 번호로 스크롤합니다. 그 숫자 바로 아래의 숫자는 현재 변경 목록의 번호입니다.
답변
p4 changes -m1 @clientname
내 고객을 위해 “권장”하는 방법은 약 10 분 정도 걸립니다.
이것이 내가 사용하는 것입니다.
p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'
동일한 클라이언트의 경우 2.1 초 소요
답변
cstat 명령을 사용할 수도 있습니다.
p4 도움말 cstat
cstat -- Dump change/sync status for current client
p4 cstat [files...]
Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.
The fields that cstat displays are:
change changelist number
status 'have', 'need' or 'partial'
답변
심각한 빌드 (테스트 준비중인 빌드)의 경우 원하는 라벨 또는 변경 목록 번호를 명시 적으로 지정하고 라벨에 동기화하고 빌드 아티팩트에 임베드하십시오.
변경 목록 (또는 레이블)이 제공되지 않으면를 사용 p4 counter change
하여 현재 변경 번호를 가져 와서 기록하십시오. 하지만 여전히 변경 번호를 사용하여 모든 것을 동기화 해야합니다 .
일반적으로 전체 작업 공간이 특정 변경 목록 번호와 동기화되지 않기 때문에 원하는 것을 정확히 얻을 수 있다고 생각하지 않습니다. 일부 파일을 이전 개정판에 명시 적으로 동기화 할 수 있으며 단일 변경 목록 번호는 의미가 없습니다. 그렇기 때문에 sync
단일 변경 목록 번호가 코드 버전을 정확하게 나타 내기 위해 새로운 것이 필요합니다.
의견과 관련하여 : 예, 내 대답은 QA에 제공 할 빌드를 준비하는 구성 관리자가 사용하기위한 것입니다. 개발자는 일반적으로 빌드의 일부로 동기화하지 않습니다. 제출하기 전에 빌드를 수행하므로 변경 사항으로 인해 빌드 또는 테스트가 중단되지 않는지 확인할 수 있습니다. 그런 맥락에서 우리는 저장소 레이블을 삽입하지 않아도됩니다.
접근 방식에서는 마지막 변경 목록을 제출할 때 전체 작업 영역이 헤드에 동기화되었고 해당 변경 목록에 열려있는 모든 파일이 포함되어 있다고 가정합니다. 이러한 가정에서 착각하기가 너무 쉽고 감지하기 어렵고 시간 손실 측면에서 끔찍한 비용이 듭니다. 반면에 문제를 해결하는 것은 결점없이 쉽습니다. 그리고 변경 목록 번호를 명시 적으로 지정할 수 있기 때문에 어떤 개정이 필요한지 또는 코드베이스가 얼마나 빨리 변경되는지는 중요하지 않습니다.
