windows - Gem filtilladelser i Subversion-depot

Indlæg af Hanne Mølgaard Plasc

Problem



Hvordan gemmer du filtilladelser i et depot? Nogle få filer skal være skrivebeskyttede for at stoppe et tredjepartsprogram fra at skille det ud, men efter at have tjekket ud af depotet, er de indstillet til at læse og skrive.


Jeg kiggede på google og fandt et blogindlæg fra 2005, der siger, at Subversion ikke lagrer filtilladelser. Der er patches og hook-scripts opført (kun en url eksisterer stadig). Tre år senere gemmer Subversion stadig ikke filtilladelser og er kroge den eneste vej til at gå om dette? (Jeg har aldrig lavet kroge og brug hellere noget, der er indfødt til Subversion.) [8]

Bedste reference


En mulig løsning ville være at skrive et script, som du tjekker ind med resten af ​​din kode, og som køres som første trin i din byggeproces.


Dette script løber gennem din kopi af codebase og indstiller læs tilladelser på bestemte filer.


Ideelt set ville scriptet læse listen over filer fra en simpel inputfil.
Dette ville gøre det nemt at vedligeholde og let for andre udviklere at forstå, hvilke filer der bliver markeret som skrivebeskyttet.

Andre referencer 1


SVN har evnen til at lagre metadata (egenskaber) sammen med en fil. Egenskaberne er stort set kun nøgle/værdipar, men der er nogle specielle nøgler som 'svn: executable', hvis denne egenskab eksisterer for en fil, vil Subversion indstille filsystemets eksekverbare bit for den fil, når du kontrollerer filen. Mens jeg ved det, er det ikke lige hvad du leder efter, det kan bare være nok (var for mig). [9]


Der er andre egenskaber til line ending (svn: eol-stil) og mime type (svn: mime-type).

Andre referencer 2


Der er ingen indfødt måde at gemme filtilladelser i SVN på.


Både asvn og plaster fra bloggen ser ud til at være op (og hostet på det officielle SVN-depot), og det er så godt, men jeg tror ikke, de vil have sådan metadatahåndtering i kerneversionen helst snart. [10] [11]


SVN har haft evnen til at håndtere symbolske links og eksekverbare filer specielt i lang tid, men fungerer heller ikke korrekt på Win32. Jeg ville ikke holde vejret for en anden sådan ikke-bærbar funktion (selvom det ikke ville være for svært at implementere oven på det allerede eksisterende metadatasystem.) [12] [13]


Jeg ville overveje at skrive et shell script til manuelt at justere filtilladelser, så sætte det i depotet.

Andre referencer 3


Da dette ikke var sagt helt i tidligere svar endnu. Jeg hader at genoplive zombierede tråde selv.


Siden tilføjelse af tilladelse skal understøttelse af SVN rumme flere OS'er og tilladelsestyper, NFS, POSIX, ARWED og RACF


Dette ville gøre SVN oppustet, muligvis sammenbrud med modstridende tilladelse typer som NFS og POSIX, eller åbne op for mulige udnyttelser/sikkerhedsproblemer.


Der er et par løsninger.
pre-commit, post-commit, start-commit er mere almindeligt anvendt, og er en del af Subversion-systemet.
Men vil give dig mulighed for at kontrollere tilladelserne med hvilket som helst programmeringssprog du kan lide.


Det system, jeg implementerede, er, hvad jeg kalder en pakker, der validerer de overførte filer i arbejdskopien, og analyserer derefter en metadatafil, som viser de standard tilladelser, der er ønsket for filer/mapper, og eventuelle ændringer til dem, du ønsker også.


Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700


Du kan også udvide dette og tillade ting som automatisk flytning, omdøbe dem, tagging revision efter typer, som alfa, beta, frigivelse kandidat, frigivelse


For så vidt angår at støtte kunder til at checke dine depotfiler med tilladelser knyttet til dem. Du er bedre at se på at oprette et installationsprogram til din pakke og tilbyde det som en ressource.


Forestil dig folk, der indstiller deres arkiver med en eksekverbar i den, der er angivet med root-tilladelser: www-user 4777

Andre referencer 4


Dette er den opdaterede link til SVN-patch, der håndterer unix stilfiltilladelser korrekt. Jeg har testet ud på fedora12 og synes at virke som forventet: [14]


Jeg har lige gemt det/usr/bin/asvn og brug asvn i stedet for svn kommando, hvis jeg har brug for tilladelser håndteret korrekt.

Andre referencer 5


Mange svar har angivet, at svn ikke opbevarer filtilladelser. Dette kan være sandt, men jeg kunne løse en dll-fil uden eksekveringsrettigheder problem blot ved disse trin:



  1. chmod 755 badpermission.dll

  2. mv badpermission.dll ../

  3. svn opdatering

  4. svn rm badpermission.dll

  5. svn commit badpermission.dll -m 'Fjern dll for at rette tilladelser'

  6. mv ../badpermission.dll.

  7. svn tilføj badpermission.dll

  8. svn commit badpermission.dll -m 'Tilføj dll igen for at rette tilladelser'

  9. rm badpermission.dll

  10. svn opdatering

  11. badpermission.dll kommer tilbage med udførelsesrettigheder


Andre referencer 6


@morechilli:


Asvnindpakningen fra mit tidligere indlæg og bloggen i OP 's post synes at gøre hvad du foreslår. Selvom det lagrer tilladelserne i de tilsvarende filer 'repository egenskaber i modsætning til en enkelt ekstern fil.

Andre referencer 7


Jeg vil anbefale at generere tilladelseskort ved hjælp af mtree-værktøjet (FreeBSD har det som standard), gem kortet i opbevaringsstedet, og som nævnt ovenfor køre et script, der ville gendanne de korrekte filtilladelser fra kortet som det første trin i byggeproces.

Andre referencer 8


Låsning ville ikke løse dette problem. Låsning stopper andre fra at redigere filen. Dette er en tredjepartsprogram, der bliver kørt som en del af byggeprocessen, der forsøger at skrive til en fil - ændre den - hvilket bryder byggeprocessen. Derfor er vi nødt til at stoppe programmet fra at ændre filen, som blot markerer filen skrivebeskyttet. Vi vil gerne have, at oplysningerne holdes i depotet og transporteres på tværs af checkins, filialer mv.

Andre referencer 9


Graham, svn lagrer ikke tilladelser. Din eneste mulighed er at indpakke dit opkald til svn i et script. Skriptet skal kalde svn med sine argumenter og derefter indstille tilladelserne efterfølgende. Afhængigt af dit miljø kan du muligvis kalde dit script svn og justere din PATH for at sikre, at det bliver kaldt.


Jeg kan godt lide morechillis idé om at få listen over filer og tilladelser kontrolleret ind i depotet selv.

Andre referencer 10


Vi har oprettet en batchfil til at gøre dette for os. Ville foretrække faktisk støtte i subversion selvom ...

Andre referencer 11


Overvej at bruge svn lock for at forhindre andre i at skrive til filen. [15]