Onlangs is onze svn-server gewijzigd en hebben we een svn-switch gedaan.
Omdat de werkkopie een enorme hoeveelheid bronnen zonder versienummer had, werd de werkkopie vergrendeld en begonnen we map voor map te wisselen voor alle mappen onder svn, wat prima werkt.
Maar op het bovenste niveau van de repository, als ik bestanden probeer bij te werken, krijg ik de svn: Working copy ‘.’ vergrendelde-fout en opschonen helpt ook niet. Als ik opruim, krijg ik fouten zoals deze – svn: ‘content’ is not a working copy directory
Vers afrekenen is helemaal GEEN optie. Zijn er andere manieren om de sloten op te ruimen en te ontgrendelen en de schakelaar volledig uit te voeren?
BEWERKEN:
De laatste alinea in het antwoord van JesperE
Als u een “geen werkkopie” krijgt wanneer
een recursieve “svn-opruiming” doen my
denk dat je een directory hebt
die een werkkopie zou moeten zijn (d.w.z.
de .svn-map op het hoogste niveau
zegt het wel), maar het mist zijn eigen
.svn-map. In dat geval ben je
zou kunnen proberen om dat gewoon te verwijderen / verplaatsen
directory en voer vervolgens een lokale update uit
lijkt de oplossing te zijn voor het probleem in de repository. Ik heb die mappen geïdentificeerd en alleen die specifieke mappen opnieuw uitgecheckt en wauw, de sloten worden vrijgegeven bij de daaropvolgende opschoning! Heel erg bedankt JesperE !!
Maar ik kan de svn-schakelfout nog steeds niet achterhalen, die nu zoiets als,
. luidt
svn: De repository op
‘svn://repourl/reponaam/mapnaam’
heeft uuid ‘m/reponame’, maar de WC
heeft ‘b5b39681-0ff6-784b-ad26-2846b9ea8e7d’
Enig idee?
Antwoord 1, autoriteit 100%
Als je een “geen werkkopie” krijgt wanneer je een recursieve svn cleanupuitvoert, vermoed ik dat je een map hebt die een werkkopie zou moeten zijn (dwz de .svndirectory op het hoogste niveau zegt het wel), maar het mist zijn eigen .svndirectory. In dat geval kunt u proberen die map gewoon te verwijderen/verplaatsen en vervolgens een lokale update uit te voeren (d.w.z. rm -rf content; svn checkout content).
Als je een not a working copyfoutmelding krijgt, betekent dit dat Subversion daar geen juiste .svndirectory kan vinden. Controleer of er een .svndirectory in contents
is
De ideale oplossing is, indien mogelijk, een nieuwe kassa.
Antwoord 2, autoriteit 37%
Ik kwam in een vergelijkbare situatie (svn: 'papers' is not a working copy directory) op een andere manier, dus ik dacht ik post mijn strijdverhaal (vereenvoudigd):
$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied
Oeps! rechten herstellen… dan:
$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~ papers
$ svn cleanup
svn: 'papers' is not a working copy directory
En zelfs het verplaatsen van papersuit de weg en het uitvoeren van svn up(wat werkte voor de OP) loste het niet op. Dit is wat ik deed:
$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers
Dat werkte.
Antwoord 3, autoriteit 5%
Ik heb het opgelost door
- Kopieer een back-up van de getroffen mappen
- SVN zet de getroffen mappen terug
- Plak de bestanden terug van de back-up
In mijn geval was het probleem te wijten aan verwijderde .svn-bestanden.
Antwoord 4, autoriteit 4%
Misschien heb je zojuist de mapstructuur gekopieerd en geprobeerd de laagste toe te voegen.
SVN
|_
|
subfolder1
|
subfolder2 (here you get an error)
in dat geval moet je de directory op het bovenste niveau vastleggen.
Antwoord 5, autoriteit 2%
Oplossing:
Hernoem map die geen ‘werkkopie’ is
Afrekenen/bijwerken/herstellen van deze map opnieuw
Verplaats bestanden van hernoemde map naar nieuw
Wijzigingen doorvoeren
Reden:
U heeft enkele wijzigingen aangebracht in enkele bestanden in de .svn-map, dit verbreekt de ‘werkkopie’
Antwoord 6, autoriteit 2%
Als u een bestand in een nieuwe map hebt gemaakt, in plaats van ‘SVN Voeg Newdir / Newfile’ gebruik ‘SVN toe Voeg NEWDIR toe, omdat u de map wilt toevoegen. Alle bestanden in de map worden standaard toegevoegd.
7
Ik heb net “geen werkende kopie”, en voor mij was de reden de auto op Unix.
Gewoon een frisse “CD / PATH / TO / WERK / WERK / DIAD” deed de truc.
8
Ik heb geprobeerd de .svn-map uit de submap naar de hoofdmap te plakken. Het werkt !!!
9
Ik voldoe ook aan dit probleem in SVN-diff-operatie, het werd veroorzaakt door onjuist bestandspad, u moet './'toevoegen om de huidige bestandsdirectory aan te geven.
10
SVN: de repository bij ‘SVN: // Repourl / Reponame / Foldername’ heeft UUID ‘M / Reponame’, maar de WC heeft ‘B5B39681-0FF6-784B-AD26-2846B9EA8E7D’
Elke Subversion Repo heeft een unieke identificatie (UUID). Subversion gebruikt dit om ervoor te zorgen dat de repo eigenlijk hetzelfde is bij het doen van dingen zoals schakelen. U moet waarschijnlijk de UUID op de server wijzigen om hetzelfde te zijn als voorheen.
11
Zou het een werkende kopieerformaat kunnen zijn? Het veranderde tussen SVN 1.4 en 1.5 en nieuwere gereedschappen converteren automatisch het formaat, maar dan werken de ouderen niet langer met de geconverteerde kopie.
12
U moet een SVN-basisbestand van uw project hebben verwijderd (dat alleen-lezen bestanden zijn). Hierdoor krijgt u deze foutmelding.
Bekijk opnieuw een nieuw project, voeg de wijzigingen (indien aanwezig) van uw oudere SVN-project samen met nieuwe gebruik van “WINMERGE” en plegen de wijzigingen in uw nieuwste uitchecken.
13
Had hetzelfde probleem, blijkt dat we Slik 1.6.2 en schildpad op dezelfde machine hadden. Tortoise was bijgewerkt (en had de werkkopie bijgewerkt) maar Slik had niet, dus Tortoise werkte OK, maar opdrachtregels mislukt met:
SVN: ‘.’. ‘ is geen werkkopmap
Het verwijderen van zowel Tortoise als Slik en het opnieuw installeren van Tortoise met ingeschakelde opdrachtregelprogramma’s loste dit voor mij op.
Antwoord 14
voor mac: – neem de kassa vanaf de serverzijde en er wordt een nieuw venster geopend om de map van uw lokale machine te selecteren, plaats dan al uw code in de geselecteerde map en open vervolgens de lokale zijde van svn en voeg het project toe en maak het vast
Antwoord 15
Vandaag heb ik hetzelfde probleem gevonden /FILE_NAME/ is not a working copyin de ochtend en ik heb meer dan twee uur besteed om het op te lossen. Na lang zoeken met RND en Google heb ik een oplossing gevonden en dat is CHECKOUT.
CHECKOUTvanSUBVERSIONnaar lokaal als nieuw project.- Verander een deel van de code in het Java-bestand en COMMIT het project.
- Het werkt voor mij.
Ik hoop dat het je zal helpen.
Antwoord 16
Onlangs gebruikte ik Mac voor andere ontwikkelaars
Ik had dezelfde situatie, probleem was; eerst moest ik get repo-pad naar terminal typen, maar dat deed ik niet, dan staat er wat je gebruikersnaam en wachtwoord is.
Antwoord 17
Ik kwam zojuist een geval tegen waarbij de .svn-directory zich op een nfs-server op een andere machine bevindt, en de nfs-client draaide niet de bestandsvergrendelingsservice (lockd).
svn: E155007: '/mnt/svnworkdir' is not a working copy
Dit ging weg zodra lockdwerd gestart op de nfs-clienthost.
Het lijkt erop dat subversion een betere foutmelding kan geven als het problemen heeft met het vergrendelen van bestanden. Dit was subversie 1.10.0
Antwoord 18
Ik heb een nieuwe checkout gemaakt van hetzelfde project naar een andere locatie, vervolgens de .svn-map ervan gekopieerd en vervangen door mijn oude .svn-map. Daarna de svn-updatefunctie aangeroepen en alles was correct up-to-date gesynchroniseerd.
Antwoord 19
Ik had precies deze fout. Ik zag dat ik in de verkeerde directory zat. Toen ik terugging naar de SVN Trunk-directory, was het probleem opgelost.
Antwoord 20
Ik zag deze fout tijdens het uitvoeren van mvn release:prepare op mijn code. In mijn geval had ik het project van SVN naar Github gemigreerd en de broncode van Github gekloond. Maar in mijn pom.xml-bestand miste ik het bijwerken van de SCM-locatie van SVN-URL naar Github-URL, wat de mismatch tussen de werkmappen veroorzaakte.
Het corrigeren van de URL naar de Github-locatie heeft het voor mij opgelost.
Antwoord 21
Verwijder de .svn-map die aanwezig is op uw lokale computer. Druk op het Windows-pictogram en typ .svn, verwijder de hele map. Het werkte voor mij.