Errore SVN: non una copia funzionante

Recentemente il nostro server svn è stato modificato e abbiamo fatto uno switch svn.

Poiché la copia di lavoro aveva un'enorme quantità di risorse non controllate, la copia di lavoro è stata bloccata e abbiamo iniziato a cambiare cartella per cartella per tutte le cartelle sotto svn, che funziona perfettamente.

Ma al livello più alto del repository, quando provo ad aggiornare i file, ottengo svn: Working copy '.' neanche l'errore bloccato e la pulizia non aiutano. Quando eseguo la pulizia, ricevo errori come questi: svn: 'content' non è una directory di copia funzionante

Il checkout fresco NON è affatto un'opzione. Esistono altri modi per ripulire e rilasciare i blocchi e eseguire completamente l'interruttore?

EDIT: l'ultimo paragrafo nella risposta di JesperE

Se ottieni una "copia non funzionante" quando esegui una "svn cleanup" ricorsiva, suppongo che tu abbia una directory che dovrebbe essere una copia funzionante (la directory .svn al livello superiore lo dice), ma manca il suo possedere la directory .svn. In tal caso, potresti provare a rimuovere / spostare quella directory e quindi fare un aggiornamento locale

sembra essere la soluzione al problema nel repository. Ho identificato quelle cartelle e ho fatto un nuovo checkout di quelle cartelle specifiche da solo e wow, i blocchi vengono rilasciati nella successiva pulizia! Grazie mille JesperE !!

Ma non riesco ancora a capire l'errore di svn switch che ora legge qualcosa del tipo,

svn: il repository in 'svn: // repourl / reponame / foldername' ha uuid 'm / reponame', ma il WC ha 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Qualche idea ?

Se si ottiene una "copia non funzionante" quando si esegue una ricorsiva, la svn cleanupmia ipotesi è che si dispone di una directory che dovrebbe essere una copia funzionante (la .svndirectory al livello superiore lo dice), ma manca la propria .svndirectory. In tal caso, potresti provare a rimuovere / spostare quella directory e quindi fare un aggiornamento locale (ad esrm -rf content; svn checkout content .).

Se viene visualizzato un not a working copyerrore, significa che Subversion non riesce a trovare una .svndirectory corretta . Controlla se c'è un.svn directory incontents

La soluzione ideale è una nuova cassa, se possibile.

Mi sono trovato in una situazione simile ( svn: 'papers' is not a working copy directory) in un modo diverso, quindi ho pensato di pubblicare la mia storia di battaglia (semplificata):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

Oops! correggi permessi ... quindi:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

E anche spostarsi papersdi mezzo e correre svn up(che ha funzionato per l'OP) non ha risolto il problema. Ecco cosa ho fatto:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

Ha funzionato

L'ho risolto

1. Copia un backup delle cartelle interessate
2. SVN ripristina le cartelle interessate
3. Copia i file dal backup

Nel mio caso il problema era dovuto ai file .svn eliminati.

Forse hai appena copiato l'albero delle cartelle e hai provato ad aggiungere quello più basso.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

in tal caso è necessario eseguire il commit della directory al livello superiore.

Soluzione alternativa: rinominare la directory che non è "copia funzionante" Esegui il checkout / aggiorna / ripristina questa directory Sposta i file dalla directory rinominata in nuove modifiche di commit

Motivo: hai apportato alcune modifiche ad alcuni file nella directory .svn, questo interrompe la 'copia di lavoro'

Se hai creato un file all'interno di una nuova directory, invece di 'svn aggiungi newdir / newfile' usa 'svn aggiungi newdir' perché devi aggiungere la directory. Tutti i file all'interno della directory verranno aggiunti per impostazione predefinita.

Ho appena ottenuto "non una copia funzionante", e per me il motivo è stato l'Automouter su Unix. Solo un nuovo "cd / path / to / work / directory" ha funzionato.

Lo stesso, dovevo aggiornare una cartella 'contrib':

1. Spostato la vecchia cartella,
2. Copiato quello nuovo
3. Ho copiato le cartelle .svn in ciascuna nuova cartella (solo tre nel mio caso).

Anche nel mio caso il problema era dovuto alle cartelle .svn eliminate.

Risolto.

Ho provato a incollare la cartella .svn dalla sottocartella alla cartella principale. Funziona!!!

Questo è quello che ho fatto:

1. rinomina trunk in trunk_
2. creare un nuovo trunk di cartelle
3. Ricontrolla e interrompi il processo dopo che alcuni file sono stati estratti
4. Sposta i file da trunk_ a trunk
5. Svn cleanup
6. Aggiorna svn. Ciò aggiornerà lo stato dei file e quindi tutti i tuoi file saranno sottoposti a versione.

Incontro anche questo problema nell'operazione svn diff, è stato causato da un percorso di file errato, dovresti aggiungere './'per indicare la directory del file corrente.

svn: il repository in 'svn: // repourl / reponame / foldername' ha uuid 'm / reponame', ma il WC ha 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Ogni repo sovversione ha un identificatore univoco (uuid). Subversion usa questo per assicurarsi che il repository sia effettivamente lo stesso quando si fanno cose come il passaggio. Probabilmente dovresti cambiare l'UUID sul server in modo che sia lo stesso di prima.

Potrebbe essere una mancata corrispondenza del formato di copia funzionante? È cambiato tra svn 1.4 e 1.5 e gli strumenti più recenti convertono automaticamente il formato, ma poi quelli più vecchi non funzionano più con la copia convertita.

È necessario aver eliminato un file SVN - base dal progetto (che sono file di sola lettura). A causa di ciò si ottiene questo errore.

Guarda di nuovo un nuovo progetto, unisci le modifiche (se presenti) del tuo vecchio progetto SVN con uno nuovo usando "Winmerge" e apporta le modifiche nell'ultimo check out.

Menzioni @JesperE necessità di cambiare l'UUID. Quanto segue dovrebbe aiutarti a raggiungere questo obiettivo.

Su SVN 1.5+, puoi fare svnadmin setuuid; puoi quindi verificare che sia stato impostato correttamente usando svnlook uuid. Nelle versioni precedenti di SVN, è un processo più difficile. Vedi http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

Inoltre, l'UUID di "m / reponame" sembra sospetto. Credo che dovrebbe essere un numero in formato esadecimale come quello della copia di lavoro, quindi forse questa azione migliorerà le cose a tutto tondo :-)

[Inizialmente ho commentato la risposta di @ JesperE , ma ho creato questa risposta per renderla più ovvia per le persone e più utile per Google. Da allora ho rimosso i miei commenti. ]

Abbiamo avuto lo stesso problema, a quanto pare abbiamo avuto Slik 1.6.2 e Tortoise sulla stessa macchina. Tortoise era stato aggiornato (e aveva aggiornato la copia di lavoro) ma Slik no, quindi Tortoise ha funzionato bene, ma le righe di comando non sono riuscite con:

svn: '.' non è una directory di copia funzionante

Rimuovere Tortoise e Slik, quindi reinstallare Tortoise con gli strumenti da riga di comando abilitati ha risolto questo problema per me.

per mac: - fai il checkout dal lato server e si aprirà una nuova finestra per selezionare la directory dal tuo computer locale, quindi inserisci tutto il codice nella cartella selezionata, quindi apri il lato svn locale e aggiungi e commetti il ​​progetto

Oggi ho riscontrato lo stesso problema /FILE_NAME/ is not a working copyin mattinata e ho impiegato più di due ore per risolverlo. Dopo molto tempo su RND e Google ho trovato una soluzione e questo è vero CHECKOUT.

1. CHECKOUTda SUBVERSIONa locale come nuovo progetto.
2. Cambia parte del codice nel file java e COMMIT il progetto.
3. Funziona per me.

Spero ti sia utile.

Recentemente stavo usando altri sviluppatori Mac e ho avuto la stessa situazione, il problema era; prima dovevo digitare get repo path to terminal ma non l'ho fatto, quindi dice qual è il tuo nome utente e password.

Ho appena incontrato un caso in cui la directory .svn si trova su un server nfs su una macchina diversa e il client nfs non eseguiva il servizio di blocco dei file ( lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

Questo è andato via una volta lockdavviato sull'host client nfs.

Sembra che Subversion potrebbe presentare un messaggio di errore migliore quando ha problemi a bloccare i file. Questa era la sovversione 1.10.0

Ho effettuato un nuovo checkout dallo stesso progetto in una posizione diversa, quindi ho copiato la cartella .svn da esso e sostituito con la mia vecchia cartella .svn. Dopodiché ha chiamato la funzione di aggiornamento svn e tutto è stato sincronizzato correttamente e aggiornato.

Elimina la cartella .svn presente nel tuo computer locale. Premere l'icona di Windows e digitare .svn, eliminare l'intera cartella. Ha funzionato per me.