Subversion에 디렉토리 구조가 있습니다.모든 태그 Subversion에서 액세스 폴더를 제한하는 방법은 무엇입니까?
문제는 내가 수많은 태그를 생성했으며, 이제는 태그 내에서 액세스를 제한해야한다는 것입니다.
일반적인 것을해야합니다.
[Repo:/tags/**/folder]
developers =
Administrator = rw
문제는 작동하지 않으며 개발자가 허가를 계속합니다.
생성되는 각 태그에 대해 구성을 해제해야합니까?
Subversion은 경로 기반 인증을 위해 와일드 카드를 지원하지 않습니다. 상위 레벨로 제한하거나 경로를 개별적으로 지정해야합니다.
문제는 내가 수많은 태그를 생성했으며, 이제는 태그 내에서 액세스를 제한해야한다는 것입니다.
두 가지 :
너무 많은 태그을 만들지 마십시오. 리비전 번호는 항상 태그으로 사용할 수 있으며 많은 사이트에서 리비전 번호를 사용합니다. 누군가가 라고 말합니다. "개정판 54220에 대한 코드 리뷰가 있습니까?" 수정 번호를 태그으로 사용하면 많은 수의 태그를 생성하지 않아도됩니다. Jenkins과 같은 CI 시스템을 사용하는 경우 빌드 번호를 태그으로 사용할 수 있습니다. 이는 특정 Subversion 개정판을 다시 가리 키기 때문입니다.
왜 태그에 대한 액세스를 제한하려고합니까? 갑자기 그 태그가 있던 곳에서 이전에 없었던 비밀 정보가 갑자기 나타 났습니까? svnaccess 파일에는 와일드 카드를 사용할 수 없습니다.
은 내가 실제 문제가 너무 많은 태그가 있다는 것을 받아, 사용자는 그들을 밖으로 긴 시간이 오래 걸릴 목록. 또한 /tags에 20,000 개가있는 경우 원하는 태그를 찾기가 어렵습니다. 이 경우 더 이상 필요없는 태그를 삭제하면됩니다.
그러나 우리가 정보를 잃지는 않을까요? 그 태그가 필요한 걸 알게되면 어떡하지?
Subversion은 아무 것도 영구적으로 삭제하지 않습니다. 필요할 경우 언제든지 이전 버전을 되돌릴 수 있습니다. 이전 태그를 삭제했다고 가정 해 보겠습니다.
$ svn delete http://repo/svn/tags/2.4
이제 특별한 이유없이 특정 수정 버전이 필요하다는 것을 알게되었습니다. 어쩌면 오래된 개정판에 여전히 고객이 있었을 것입니다. 그것이 삭제 된 후에 어떻게 되 찾았나요?
첫째, 당신은이 삭제 된 것을 개정에서 찾을 수 있습니다 :이
$ svn log -v http://repo/svn/tags
...
----------------------------------------------------------------------
r32394 | alroc | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 line
Changed Paths:
D /tags/2.4
Deleted obsolete tag that's no longer needed
----------------------------------------------------------------------
! 버전 -r32394에서 삭제되었습니다. 이는 이전 Subversion 개정판 (32393)에서 여전히 존재 함을 의미합니다. 리비젼 32393의 태그를 확인해 봅시다 :
$ svn checkout -r32393 http://repo/svn/tags/[email protected]
모두 완료되었습니다. 우리는 그 오래된 코드를 가지고 있습니다. 당신이 다시 저장소에 해당 태그가 필요 /tags에 다시 복사하면 어떻게 :
$ svn copy -r32393 http://repo/svn/tags/[email protected] http://repo/svn/tags
지금, /tags/2.4가 돌아왔다.
정말로 태그를 삭제하는 것이 싫은 경우 어딘가에 태그 보관 디렉토리를 만들고 사용하지 않는 태그를 이동하십시오. 이렇게하면 은 태그를 삭제하는 것이 아니며, svn ls http://repo/svn/tags을 수행하면 태그가 표시되지 않습니다.
덤프를 수행하고로드하려는 경우 (예 : 프로젝트를 다른 저장소로 분리하는 경우), 보관 된 태그를 포함하지 않으면 svndumpfilter이 엉망이됩니다.
가장 좋은 방법은 처음부터 문제를 만드는 것이 아닙니다. 릴리스 용 태그 만 작성한 다음 태그가 너무 많다고 생각되면 태그를 삭제하십시오.