Ho un file delle impostazioni che si trova sotto il controllo della versione utilizzando subversion. Ognuno ha la propria copia di questo file, e ho bisogno che questo non venga mai commesso. Tuttavia, come ho detto, c'è già una copia sotto controllo di versione. La mia domanda è: come faccio a rimuovere questo file dal controllo di versione senza eliminare il file di tutti, quindi aggiungerlo all'elenco di ignora in modo che non venga eseguito il commit? Sto usando la riga di comando linux svn.SVN: Ignorare un file già impegnato
risposta
Effettuare un checkout pulito, svn delete
il file e aggiungere l'ignore. Quindi commetti questo. Tutti gli altri dovranno fare attenzione (una volta) che la loro copia locale non venga cancellata nel prossimo svn update
, ma in seguito il file locale rimarrà indisturbato e ignorato da SVN.
Come (come "tutti gli altri") si impedisce il cancella durante l'aggiornamento? –
Spostarlo prima di eseguire l'aggiornamento. Copia di nuovo in seguito. –
Come mai non c'è un modo più semplice per farlo? Qualcuno può spiegare? – DaveS
Se si rimuove il file dal controllo di versione, in che modo uno sviluppatore nuovo del progetto (o quello che ha eliminato per errore la sua copia locale) lo ottiene dopo il checkout iniziale? Cosa succede se ci sono aggiunte al file delle impostazioni?
vorrei suggerire quanto segue: Mantenere un file di impostazioni di default (senza password, hostname, stringhe di connessione, ecc) in SVN, nome è qualcosa di simile a settings.dist
, e lasciare che il codice di lavoro con una copia di questa, di nome settings
. Ogni sviluppatore deve fare questa copia una volta e può quindi lavorare con le sue impostazioni personalizzate. Se ci sono aggiunte, aggiungili a settings.dist
- tutti gli altri le riceveranno con un aggiornamento e potranno quindi unirle nella sua copia personalizzata.
definire semplicemente un file contenente impostazioni che sostituiranno quelle predefinite. Questo file non è controllato in Subversion e ogni sviluppatore è responsabile della gestione di questo file in base al loro ambiente.
In un mondo Ant-based, si avrebbe i file:
settings.properties
settings-local.properties (ignored for Subversion)
e nel vostro file di build.xml
<property file="settings-local.properties"/>
<property file="settings.properties"/>
Per coloro che non hanno potuto unire i puntini:
- modificare il file build.xml come proposto
- s et le setting-local.properties come ignorati
- in un
init
bersaglio della vostra costruzione, copiare i settings.properties per settings-local.properties - aspettare un paio di giorni fino a quando tutti hanno avuto la possibilità di correre questo obiettivo
- eliminare i setting.properties da Subversion
Voila, ogni sviluppatore ha le sue setting-local.properties e tutto è stato fatto automaticamente (e nessuno sviluppatore ha perso le proprie impostazioni, che succede se si elimina il file brutalmente da Suvversione e non c'è "Tutti gli altri dovranno fare attenzione ...")
Non aiuta a risolvere il problema anche se –
Strano che questa risposta sia stata rifiutata così tante volte, poiché è l'unica che non ha ignorato la parte relativa alla mancata eliminazione del file locale di tutti. –
[[Sono nuovo di sovversione, quindi forse questo non ha senso. contrassegnando questo come wiki - se si conosce la risposta corretta, si prega di APPENDERE nella sezione successiva]]
Non si può avere un set personalizzato di passaggi di checkout in modo che ogni utente abbia una diversa cartella delle impostazioni?
$ svn checkout http://example.com/project project .. $ dir project original_settings\ folder1\ folder2\ $ svn checkout http://example.com/project/aaron_settings project\settings .. $ dir project original_settings\ folder1\ folder2\ settings\
O per i nuovi utenti
$ svn import project\settings http://example.com/project/aaron_settings
Quello che voglio dire è che si desidera ciascun utente di avere una visualizzazione personalizzata del repository. In altri sistemi di controllo delle versioni, è possibile impostare un elenco personalizzato dei progetti che si stavano utilizzando e che non si erano e che si inseriscono in luoghi strani.
Funziona in sovversione? Il codice sopra sembra davvero rischioso, ma forse sto sbagliando.
WIKI:
(ancora nulla)
Dopo aver eliminato il file, gli utenti dovranno recuperare il file dal repository utilizzando svn export
.
$ svn export -r x path ./
Dove x
è una revisione in cui esisteva il file prima che fosse cancellato, path
è il percorso completo del file, e ./
è dove verrà posizionato il file.
Vedere svn help export
per ulteriori informazioni.
Ho un problema simile. Nel mio caso si tratta di un file di impostazioni utente generato automaticamente (studio visivo) che è stato accidentalmente verificato molto presto nel progetto. Mentre è appena possibile eliminarlo potrebbe funzionare, sembra più correct
rimuoverlo dalla cronologia, in quanto non avrebbe mai dovuto esserci in primo luogo.
mi sono imbattuto in questo, che potrebbe essere una nuova funzionalità da quando la questione è stata originariamente pubblicato 7,5 anni fa:
https://stackoverflow.com/a/6025750/779130
sembra un'idea sarebbe quella di:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
Questo potrebbe essere l'unico modo per eliminare completamente il file. Nella maggior parte dei casi l'approccio "elimina e ignora" potrebbe essere abbastanza buono.
possibile duplicazione di [svn ignora senza eliminare file?] (Http://stackoverflow.com/questions/951032/svn-ignore-without-deleting-files) – tchrist