Perforce에서 동기화 된 마지막 변경 목록 확인

때때로 발생하는 질문은 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에 제공 할 빌드를 준비하는 구성 관리자가 사용하기위한 것입니다. 개발자는 일반적으로 빌드의 일부로 동기화하지 않습니다. 제출하기 전에 빌드를 수행하므로 변경 사항으로 인해 빌드 또는 테스트가 중단되지 않는지 확인할 수 있습니다. 그런 맥락에서 우리는 저장소 레이블을 삽입하지 않아도됩니다.

접근 방식에서는 마지막 변경 목록을 제출할 때 전체 작업 영역이 헤드에 동기화되었고 해당 변경 목록에 열려있는 모든 파일이 포함되어 있다고 가정합니다. 이러한 가정에서 착각하기가 너무 쉽고 감지하기 어렵고 시간 손실 측면에서 끔찍한 비용이 듭니다. 반면에 문제를 해결하는 것은 결점없이 쉽습니다. 그리고 변경 목록 번호를 명시 적으로 지정할 수 있기 때문에 어떤 개정이 필요한지 또는 코드베이스가 얼마나 빨리 변경되는지는 중요하지 않습니다.

전체 디포 (작업 공간 / 클라이언트뿐만 아니라)

p4 counter change

마지막 변경 목록을 말하면서 작업을 수행합니다.

지금까지 내가 찾은 가장 좋은 방법은 빌드하려는 변경 목록에 동기화를 수행 한 다음 변경 사항 -m1 //...#have를 사용하여 현재 로컬 변경 목록 (개정판)을 가져 오는 것입니다.

p4 sync @CHANGELIST_NUM p4 변경 -m1 //...#have | awk '{print $ 2}'

원하는 곳 어디에서나 사용할 수있는 변경 목록 번호를 제공합니다. 나는 현재 p4 변경 -m1 //...#have보다 더 간단한 방법을 찾고 있습니다.

필요한 답을 얻었는지 확실하지 않지만 비슷한 문제가 있습니다. 목표는 프로젝트의 특정 버전을 로거에 작성하는 것이 었습니다. 문제는 자체 메이크 파일을 만드는 동안 전체 빌드 시스템이 구성 관리에 의해 제어된다는 것입니다. 이것은 "sync to something then do something"이라고 말하는 모든 솔루션이 실제로 작동하지 않으며 커밋 할 때마다 수동으로 버전을 변경하고 싶지 않았 음을 의미합니다 (오류에 대한 확실한 소스). 해결책 (실제로 위의 답변 중 일부에 암시되어 있음)은 다음과 같습니다. makefile에서 p4 변경을 수행합니다. -m1 "./...#have"이 결과는 Change change_number on date by user @ client '입니다. msg ' 로거에 의해 인쇄되는 문자열로 메시지를 간단히 생성합니다 (변경 번호는 중요한 요소이지만 다른 하나는 확인하지 않고 직접 변경 한 내용이 특정 버전에 포함되어 있는지 여부를 신속하게 결정하는 데 유용합니다). 도움이 되었기를 바랍니다.