Esperienza con il controllo versione locale della copia di lavoro SVN?

Question

Nel mio posto di lavoro, utilizziamo SVN e TortoiseSVN (Windows XP) come client. Ho un lungo pendolarismo e lavoro offline durante quello.
Ora, vorrei avere una sorta di " annullamento esteso " a livello locale; ad esempio, vorrei avere il controllo della versione locale della mia copia di lavoro SVN, al fine di osare fare il refactoring per esempio.
Passare del tutto ad es. git, mercurial ecc. non è un'opzione poiché la società utilizza SVN.

Quello che mi piacerebbe sapere è se qualcuno ha qualche esperienza nel controllo delle versioni della copia di lavoro SVN locale, magari eseguendo un git locale o simile?
Ci sono potenziali svantaggi? (magari scherzando con le cartelle .svn o simili)

Answer 1

Di solito mi piace così:

1. Ottieni il repository SVN come copia funzionante.
2. Inizializza il repository Git in questa copia di lavoro.
3. Hack hack hack;
4. Impegnati nel mio repository Git.
5. Aggiornamento dalla società SVN.
6. Risolvi i conflitti.
7. Impegnarsi con il repository SVN aziendale una funzionalità completa.

Answer 2

Uso Git come client Subversion locale per lavoro e funziona benissimo. Quando si esegue un git svn clone di un repository Subversion, il checkout che si ottiene non ha le directory .svn nascoste, ma è invece un repository Git completo a sé stante . La capacità di utilizzare filiali locali e leggere per organizzare il mio sviluppo è una caratteristica killer per me.

Altre funzionalità che utilizzo sempre sono git stash , commit in fasi e git add -p .

Answer 3

È possibile creare un'istantanea dell'opera usando svn export e quindi creare il proprio repository di sovversione e utilizzare l'istantanea dal repository di lavoro come check-in iniziale.

Quindi è possibile apportare le modifiche e utilizzare Subversion (copia del repository locale) fino al termine. Naturalmente è possibile eseguire regolarmente l'unione dal repository di lavoro principale per assicurarsi che il contenuto sia aggiornato. Infine, al termine del refettoring è sufficiente eseguire un'istantanea di esportazione svn del repository locale e fonderla nuovamente nel repository di lavoro principale.

Questo è un po 'rozzo ma questo è l'unico modo per gestire questo tipo di flusso di lavoro.

Se hai abbastanza accesso regolare al lavoro. È possibile creare un ramo del contenuto e lavorare sul ramo esclusivamente dal repository di lavoro e utilizzare il metodo di repository locale quando è necessaria la funzionalità di annullamento esteso. A questo punto, ovviamente, l'utilizzo di un sistema di controllo della versione locale non ti limiterà alla sovversione, quindi fai la tua scelta.

Answer 4

Potresti provare SVK che un VCS decentralizzato basato sulla sovversione. Può essere utilizzato per eseguire il mirroring del repository ufficiale sul laptop e sincronizzare i commit con il trunk ufficiale.

Answer 5

L'ultima volta che ho verificato lo stato di SVN, il supporto per il check-in locale era ancora un piano funzionale a lungo termine. Git, d'altra parte, è sicuramente un'opzione, con git-svn. Cioè, se la tua architettura è Unix, AFAIK, git-svn non è ancora supportato sulla piattaforma Windows.

Answer 6

Nulla impedisce l'esecuzione del server SVN locale. Lo sto usando in questo modo.

Answer 7

Git sarebbe una buona soluzione (perché puoi creare e unire molti rami molto facilmente) ma:

• quando reimportate le vostre modifiche in svn, dovreste prima ripulire i molti rami intermedi che avete creato sotto git;
• git-svn non funziona con la distribuzione Windows di Git, quindi potresti voler usare un'immagine virtuale Linux se stai lavorando su Windows
• Se riesci a far funzionare git-svn, usa gli script git2svn et svn2git ruby, come descritto in questa domanda