여러 사용자가 공유하는 소프트웨어 프로젝트를 보관하기 위한 표준 디렉토리가 있습니까?

FHS에는 이 목적으로 할당된 표준 디렉토리가 없지만 /opt모드 770을 할당하고 사용자를 적절한 그룹에 넣을 수 있습니다.

하지만 나는높은이러한 활동을 위해 버전 제어 시스템(예: )을 설치하는 것이 좋습니다 git. 이렇게 하면 git이 소스 저장소를 처리하고 각 개발자는 자신의 homedir에 있는 개인 저장소에서 작업하게 됩니다.

말씀하신 답변은 사용자 간 데이터 공유가 아닌 프로그램 설치에 대해 논의하고 있습니다. 이 데이터가 Excel 파일이건, 영화 모음이건, 로컬에서 개발된 소스 코드이건 간에 /usr동일한 위치 에 남겨져서는 안 됩니다 /opt.

Directories 및 실제로 /usr모든 디렉토리는 File System Hierarchy Standard(또는 줄여서 FHS)라는 문서에 정의된 매우 잘 정의된 사용법 의미를 갖습니다. 최신 버전은 다음 위치에서 호스팅됩니다./opt/varhttp://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html. 운영 체제(또는 더 구체적으로 Linux 배포판에 포함된 여러 프로그램과 사용자가 직접 설치한 다른 프로그램)에는 이러한 디렉터리 사용과 관련된 특정 동작이 있으므로 이 의미를 존중하는 것이 중요합니다. 예를 들어, 아래에 하위 디렉터리를 생성 /usr/share 하고 해당 디렉터리의 이름이 나중에 설치하려는 프로그램의 이름과 충돌하는 것을 발견한 경우 설치 프로그램은 해당 하위 디렉터리를 덮어쓰거나, 변경하거나, 이름을 바꾸거나 삭제할 수 있습니다. 이 디렉토리의 내용입니다. 이것이 이해하기 쉽다면 팀의 데이터 파일을 Windows 기반 컴퓨터 아래에 /usr두거나 /opt그에 상응하는 방식으로 저장하는 것을 고려해 보십시오.C:\Windows\C:\Program Files

한 가지 주목할 점은 FHS입니다.여러 당사자(예: 로컬 사이트, 배포판, 애플리케이션, 문서 등) 간의 파일 배치를 조정해야 하는 문제를 해결합니다.. FHS는 귀하가 직면할 수 있는 모든 상황에 대해 규칙을 만들려고 시도하지 않습니다.로컬 파일의 로컬 배치는 로컬 문제입니다.(FHS, 섹션 1.1).

원래 질문으로 돌아가서 몇 가지 허용 가능한 옵션을 고려해 보겠습니다.

• /home/<projectname>또는 /home/<someprefix>/<projectname>- FHS는 다음을 의미합니다./home상당히 표준적인 개념이지만 분명히 사이트별 파일 시스템입니다.. 아래의 모든 디렉터리가 실제 사용자의 이름이어야 한다는 요구 사항은 전혀 없습니다 /home. 따라서 그룹이나 프로젝트에 대한 하위 디렉터리를 만드는 것은 허용됩니다. 그러나 그렇게 하려면 최종 충돌을 피하기 위해 몇 가지 수동 예방 조치가 필요합니다(새 사용자가 생성된 경우 이름이 일치함). 기존 프로젝트의 이름).

• /srv/<projectname>또는 /srv/<someprefix>/<projectname>- FHS 하에서,/srv이 시스템에서 제공하는 사이트별 데이터가 포함되어 있습니다.. FHS는 계속해서 설명했습니다./srv 하위 디렉터리의 이름을 지정하는 데 사용되는 방법이 지정되지 않았습니다., 그리고 다음을 포함하는 예를 제공합니다 /srv/compsci/cvs(이것은 아마도 CVS 저장소 자체일 가능성이 높습니다).컴퓨터 과학작업 팀). 내 개인적인 경험에 따르면 /srv이 디렉터리를 활용하는 대부분의 관리자는 클라이언트별, 사이트별 또는 프로젝트별 하위 디렉터리(때로는 클라이언트별, 프로젝트별 하위 디렉터리)를 사용한 다음 데이터 디렉터리를 다음 위치에 추가합니다. 이 하위 디렉토리.

• /<someprefix>/<projectname>또는 /media/<volumename>/<someprefix><projectname>— 솔직히 왜 이 옵션이 Linux 세계에서 거의 언급되지 않는지 모르겠지만 명확히 하겠습니다.당신의FHS는 확립된 의미 체계와 충돌하지 않는 한 루트 수준에서 새 디렉토리를 자유롭게 생성할 수 있음을 의미합니다. 예를 들어, 원하는 대로 디렉토리를 생성 /projects하거나 그 안의 파일을 구성할 수 있습니다. /team일부 관리자는 이를 파일 시스템의 나머지 부분과 분리하여 다른 볼륨( 아래 /media/volumename)을 마운트하는 것을 선호한다는 것을 알고 있습니다. Windows 비유로 돌아가면 이는 바로 아래에 새 디렉터리를 만들 C:\거나 다른 볼륨을 설정하는 것과 비슷합니다 D:\. 예를 들어 두 전략 모두 좋아 보입니다.받아들일 수 있는대부분의 관리자에게 해당됩니다(둘 중 하나의 옵션에 대한 선호도는 다양함).

개인적으로 저는 /srv/<client>/<project>/모든 비즈니스 서버에 하나의 구조를 갖는 것을 선호합니다. 그러면 주어진 프로젝트에 대한 모든 서비스를 쉽게 구성할 수 있기 때문입니다. 이러한 디렉터리 중 하나에는 일반적으로 서비스 지향 및 기능 지향 하위 디렉터리가 모두 있습니다. 예를 들어 , , , ...가 있을 수 있습니다. etc디렉터리 자체 는 htdocsgit 저장소의 이름에 따라 세분화됩니다. 프로젝트에 대해 여러 개의 git 저장소가 있습니다).logsgitgit