Perché il percorso del mio spazio di lavoro TFS continua a rimappare da solo?

Question

Stiamo usando Visual Studio 2008/TFS 2008.

Abbiamo un piccolo gruppo di sviluppatori e per qualche ragione, periodicamente, quando qualcuno di noi "Ricevi l'ultimo", uno dei nostri percorsi rimappa a un percorso diverso in propria. Questo fa sì che "Ottieni l'ultimo" inizi ad eliminare i file, perché il percorso è cambiato. È lo stesso percorso ogni volta che viene rimappato sul percorso sbagliato.

1. Dove vengono memorizzate le definizioni dello spazio di lavoro?
2. C'è qualcosa che potrebbe essere controllato in TFS che sta causando questo?

Answer 1

Le definizioni dell'area di lavoro sono memorizzate sul server.

Se si passa alla riga di comando e si digita "tf workspace", verrà visualizzata la definizione del proprio spazio di lavoro.

Answer 2

Questo non è un comportamento normale: sembra che qualcosa stia diventando divertente. Volevo solo controllare - tutto quello che stai facendo è semplice ottenere da Source Control explorer corretto? Inoltre, siete tutti su macchine diverse? (Ad esempio, non si condivide un'immagine PC virtuale o qualcosa in cui più macchine hanno lo stesso nome)

Una cosa che dovrei controllare è andare su File, Controllo del codice sorgente, Gestisci aree di lavoro e controllare i mapping delle cartelle di lavoro sia prima sia dopo il get e vedere se qualcosa sta cambiando. Non dovrebbe - se lo fa, potrebbe darci un indizio su cosa sta succedendo.

Answer 3

Si può anche provare a cancellare la cache spazio di lavoro e rimapparla:

 
SET AppDataTF=%USERPROFILE%\Local Settings\Application Data\Microsoft\Team Foundation 
SET AppDataVS=%APPDATA%\Microsoft\VisualStudio 
IF EXIST "%AppDataTF%\1.0\Cache" rd /s /q "%AppDataTF%\1.0\Cache" > NUL 
IF EXIST "%AppDataTF%\2.0\Cache" rd /s /q "%AppDataTF%\2.0\Cache" > NUL 
IF EXIST "%AppDataVS%\8.0\Team Explorer" rd /s /q "%AppDataVS%\8.0\Team Explorer" > NUL 
IF EXIST "%AppDataVS%\9.0\Team Explorer" rd /s /q "%AppDataVS%\9.0\Team Explorer" > NUL 

Answer 4

Ho avuto questo accada quando ricevo durante l'apertura di una soluzione. Se la soluzione contiene percorsi relativi ad altri progetti non presenti nella sua cartella, che sono mappati in modo diverso nel tuo spazio di lavoro, GET mi dirà che sta eseguendo il remapping per renderlo conto. Il problema è che le decisioni che prende sono completamente sbagliate.

L'unico modo per garantire che tutti gli sviluppatori utilizzino la stessa struttura utilizzata da controllo sourcec e havev rappresentata in ogni area di lavoro.

Arrivare lì è stato un dolore però. basicamente tutti hanno dovuto cancellare tutte le copie locali di tutti i file, ripristinare l'area di lavoro, SELEZIONARE NO PER OTTENERE QUANDO IL CAMPO DI LAVORO CAMBIATO, chiudere VS, aprire, OTTIENI ULTIMO.

Il motivo era che se copie di progetti erano esistenti in locale, anche se quei progetti NON erano aperti, il GET sarebbe ancora sbagliato. Questo è stato frustrante, perché quando si verificavano le differenze tra i progetti più recenti non c'era alcun cambiamento, ma quando si apriva la soluzione che conteneva quel progetto, i riferimenti alle dll in quel progetto sarebbero cambiati automaticamente. In quel momento, nessuna modifica è in sospeso su QUALSIASI file. Ma dopo la costruzione le modifiche continuerebbero e far sì che il prossimo dovesse essere nuovamente spento ...

Sono sicuro che questo è tutto sbagliato, ma questo è quello che ci è successo questa settimana.

Answer 5

Ok ho capito. Ecco la soluzione.

Prima di tutto installare Visual Studio 2008 SP1. (Suppongo che VS 2008 e Team Explorer siano già installati).

Ora avviare Visual Studio 2008, Goto Source Control ed elimina area di lavoro. Creare un nuovo spazio di lavoro e creare una cartella di controllo del codice sorgente per il mapping delle cartelle locali. Fare clic su OK. Quando viene richiesto "Spazio di lavoro è stato modificato, si desidera ottenere l'ultimo", Selezionare NO.

Ora Chiudi Visual Studio 2008.

Riapri Visual Studio 2008 e vai al controllo del codice sorgente e Ottieni specifico (con entrambe le caselle di controllo selezionate per sovrascrivere i file).

Se si dispone di una soluzione basata su web asp.net, ora è il momento di creare pool di applicazioni, configurare il sito in IIS, impostare l'autenticazione e l'autorizzazione adeguata. Altrimenti è opzionale!

Ora passare alla cartella appropriata nel controllo sorgente e fare doppio clic sul file della soluzione. È anche possibile aprire la soluzione facendo doppio clic sul file della soluzione nella cartella locale, ma trovo più semplice aprire la soluzione dal controllo del codice sorgente.

Facendo il passo precedente, se il vostro sito è configurato, Visual Studio 2008 rileverà automaticamente il vostro sito web che hai avuto l'installazione e richiede di confermare. Clicca ok.

Contatterà il server di controllo del codice sorgente per verificare se la sincronizzazione è necessaria o meno. Se hai una serie di progetti nella tua soluzione, noterai che la barra di avanzamento del file-get lampeggia rapidamente sullo schermo e la tua soluzione verrà configurata in pochi minuti.

Il vero problema è di Visual Studio 2008 Service Pack 1. Senza il quale il mapping TFS viene corrotto. Se SP1 è installato e la guida sopra è stata seguita, non ci saranno problemi.