Cartelle ostruite in Subversion

Cosa diavolo significa "ostruito" quando provi a controllare Subversion? Vedo due cartelle in rosso con lo stato del testo "ostruito". Non vedo cosa significhi da nessuna parte nei documenti.

Quando provo il cleanupcomando, ottengo "il nome della cartella non è una directory di lavoro". Questa è una cartella che ho appena creato in VS e quando provo ad aggiungerla a Subversion mi dà quell'errore. Tutte le altre cartelle vanno bene.

si verifica quando sono state eliminate o spostate le sottodirectory .svn (senza passare attraverso i comandi SVN), quindi SVN ha una vista danneggiata della copia di lavoro.

Prova prima una pulizia e, se ciò non lo risolve, ripristina (o aggiorna) la directory per ripristinare le cartelle .svn della sottodirectory.

Senza sapere che cosa causa questo, la soluzione può essere quella di esportare la copia di lavoro (l'intero checkout che hai localmente) da qualche altra parte.

Se stai usando tortoisesvn, hai la possibilità di "esportare file senza versione", ma penso che se lo fai dalla riga di comando esporta solo i file con versione, quindi potresti avere un po 'di laboriosa attività di copia manuale di file senza versione .

Una volta fatto, controlla una copia di lavoro pulita e quindi rilascia il backup esportato che hai sopra di esso. È molto importante che il backup non contenga cartelle .svn.

Ho visto questi errori in precedenza quando le persone hanno verificato copie di lavoro all'interno di altre copie di lavoro o qualsiasi altra cosa che corrompe le voci .svn.

Aveva lo stesso problema e risolto in questo modo:

• ribattezzato il dir ostruito
• ha creato la dir con il suo nome originale in SVN (es. svn mkdir)
• ha aggiornato la cartella principale, quindi la directory appena creata appare nella mia copia di lavoro
• ha copiato i file dalla directory ostruita a quella appena creata e li ha salvati

Se utilizzi un sistema * nix, assicurati di non aver creato un file, aggiungilo a SVN, quindi eliminalo, sostituendolo con una cartella con lo stesso nome. Non aiuta l'OP, ma spero che salverà qualcuno di stress.

Ciò significa che, per qualche motivo, si è verificato un conflitto durante l'operazione. Verifica se esiste un file o una cartella non verificato esistente con lo stesso nome di uno con versione.

(Parafrasato dal file della guida del client SVN di Tortoise)

Niente ha funzionato per me, quindi ho fatto quanto segue:

• esportato con i file non visti in una nuova posizione
• rinominato la cartella esistente
• spostato la cartella dalla posizione di esportazione nel progetto
• rinominata la nuova cartella
• aggiungere, impegnare
• rimosso la vecchia cartella rinominata
• rinominata la nuova cartella
• commettere

Esistono diverse varianti di scenario che possono causare questa situazione. Ecco un esempio:

Ho finito con il! segnare su una directory che è stata rinominata da www a www_a senza usare il comando 'svn rename':

1. Rinominare la directory corrente che porta il nome originale, ad esempio www_b
2. Rinomina www_a torna a www
3. Assicurati di fare 'svn update' o 'svn revert' nella directory www
4. Elimina la directory www aggiornata senza usare 'svn delete'
5. Vai alla directory principale e pubblica 'svn update'
6. Ciò ripristinerà la directory www originale
7. Questa volta usa 'svn rename' per rinominare www in www_a
8. Rinomina www_b torna a www
9. Usa 'svn add' per aggiungerlo nel repository

A questo punto dovresti ottenere una directory di lavoro svn corretta. E impara una o due cose su come risolvere la confusione della directory svn.

Di fronte a questo problema su un computer Windows.

Avevo verificato la directory prima di aver verificato l'intero progetto a cui apparteneva. Mi ha causato il problema "ostruito".

Ho semplicemente cancellato quella cartella ed eseguito un aggiornamento dalla radice (di quella cartella). Ha funzionato bene.

I comandi come cleanup ecc. Non hanno funzionato per me.

Qualche avvertenza:

1. Questo è costoso se la cartella è grande.
2. Ti farà perdere tutte le modifiche se ce ne sono.

Ti auguro il meglio.

L'ho visto anche su Windows quando ho creato un collegamento simbolico a una directory del repository; in questo caso, la radice del repository viene vista come "ostruita". Questo non sembra avere alcun effetto, però.

Passaggi per riprodurre:

1. Dai un'occhiata al tuo repository

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Verifica che la tua directory sia OK

   cd plugin_dir
   svn st -u
   

   L'output dovrebbe essere

   Status against revision: 1234
   

3. Crea il link simbolico (che mostra il problema)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   L'output sarà

   ~           1234  .
   Status against revision: 1234
   

Mi sono imbattuto in questo problema quando ho incollato una cartella con sottodirectory nella mia copia di lavoro utilizzando il mio client FTP - sapevo di aver rovinato non appena ho premuto il pulsante di trasferimento ... i pericoli di lavorare troppo tardi.

Ho provato tutti i suggerimenti sopra e altri trovati online senza alcun risultato. Ogni opzione produceva l'errore che la mia directory era bloccata e l'operazione non poteva essere eseguita.

Sono andato nella mia copia di Time Machine, ho ripristinato la directory e sono andato bene. Ho pulito la copia di lavoro per precauzione, ho aggiornato correttamente i miei file ed ero di nuovo in affari.

Spesso abbiamo più rami in movimento allo stesso tempo, per salvarmi cambiando o scherzando con la configurazione IIS controllo ogni ramo in una cartella separata. Quindi uso il collegamento alla directory per ricollegare quelle cartelle al percorso principale configurato in IIS.

Quindi per me la directory collegata ha sempre un punto esclamativo giallo ed è contrassegnata come ostruita. Credo che ciò sia dovuto al fatto che tecnicamente è stato creato / spostato al di fuori di SVN.

Ottengo questo stato "ostruito" sulle directory quando eseguo gli aggiornamenti a un CMS (WordPress o Drupal) attraverso l'interfaccia Web - l'applicazione non è a conoscenza del fatto che il suo codice sia in realtà una copia funzionante di sovversione, quindi quando aggiorna un plugin rimuove quello directory (inclusa la .svndirectory) e inserisce una nuova directory dalla nuova versione del plugin.

Per recuperare quella .svndirectory, dalla directory che contiene la directory ostruita. Faccio un checkout con --force. Ad esempio, se plugin_dirè contrassegnato "~", dalla sua directory principale eseguo:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Tutti i file già presenti vengono lasciati soli e contrassegnati "E" sull'output del comando di checkout (contrassegnato come "M" quando eseguo svn status).

A volte devo tornare indietro e aggiungere tutti i file che erano nuovi con l'aggiornamento; o eliminare i file che dovrebbero essere eliminati come parte dell'aggiornamento, poiché sono riapparsi quando ho fatto il checkout. Credo che questi siano contrassegnati come "A" alla cassa, ma un successivo svn statusnon li menzionerà.

Mi sono imbattuto in questo in Eclipse dove alcuni file sono stati contrassegnati con un punto esclamativo rosso. Il problema era una cartella .svn smarrita nella directory di origine. Ho eliminato la cartella .svn, aggiornato eclipse e sono stato in grado di controllare i file.

Questo può accadere anche quando aggiorni la tua sovversione a una versione che XCode non supporta.

Ecco il modo più semplice (e più sicuro) che ho trovato per risolvere questo:

1. Rinominare temporaneamente il file o la directory offensivi (o una directory principale) che è ostruita (ad esempio, aggiungere ".backup").
2. Elimina tutte le .svndirectory all'interno della directory rinominata (se applicabile).
3. svn revert l'oggetto rinominato (e ora mancante) dal passaggio 1.
4. svn delete l'oggetto ripristinato.
5. Rinominare il backup dal passaggio 1 al suo nome originale.
6. Aggiungi e archivia nuovamente l'oggetto rinominato in svn come nuovo oggetto.

Questo mi è successo quando ho sostituito un file con una cartella, con lo stesso identico nome. Risolto eliminando il vecchio file, esegui il commit e quindi aggiungi quello nuovo. Un po 'confuso, ma ha funzionato per me :)

Ho eliminato .svn in directory ostruite e lo ho aggiornato dall'esterno. Quindi il comando svn esterno riconoscerà questi file.