Domanda

Ho sempre utilizzato Subversion o CVS per il controllo della versione, che utilizzano una metodologia di "unione".Uno dei miei amici è entusiasta di Perforce e di quanto sia fantastico con i suoi elenchi di modifiche e la metodologia di check-out.

Anche se sono sicuro che molto dipenda dall'esperienza e dalle preferenze personali, mi chiedevo se fosse stata fatta qualche ricerca su quale metodo di controllo della versione è più efficiente su cui lavorare?

MODIFICARE: Per chiarire, so che sia Perforce che SVN consentono il blocco e l'unione, ma SVN "incoraggia" un metodo di modifica e unione liberale, mentre a quanto ho capito, Perforce incoraggia un metodo di checkout-checkin.

È stato utile?

Soluzione

Onestamente penso che dipenda dalla disciplina degli sviluppatori.

Utilizzo Subversion per il mio lavoro personale e l'ho usato in alcuni lavori.Quello che mi piace di Subversion è che non devo dare la caccia a qualcuno e chiedergli perché sta lavorando su qualcosa e se sarebbe giusto per me fare un po' di lavoro.Il problema arriva quando qualcuno decide di iniziare a lavorare su qualcosa e non lo controlla per un po';ciò può rendere difficile l'unione poiché vengono apportate diverse modifiche tra il check-out e il check-in.

Uso Perforce in questo momento e per qualche motivo mi piace di più SVN.Perforce mi dà sicuramente un'indicazione migliore che ci saranno conflitti di unione e dispone anche di strumenti integrati per aiutarmi a risolvere le unioni.Ha lo stesso problema per cui se qualcuno apporta tonnellate di modifiche per un lungo periodo, l'unione sarà più difficile.

Fondamentalmente entrambi i modelli richiedono che tu controlli spesso le modifiche.Se effettui numerosi check-in, riduci la probabilità di richiedere un'unione.Sono colpevole di tenere le cose sotto controllo per troppo tempo e troppo spesso.Personalmente ritengo che il prezzo di SVN compensi tutto ciò che manca rispetto a Perforce;Non ho ancora trovato una differenza tra loro.

Altri suggerimenti

L'unione è più efficiente.Per il semplice motivo che le modifiche simultanee allo stesso file tendono ad essere comuni e l'unione consente di ripristinarle.Al contrario, la cassa unica evita quel po’ di lavoro extra, ma lo fa a costo di enormi inefficienze nella pianificazione.In genere è necessario un breve periodo di tempo per unire due modifiche allo stesso file (ad es.minuti), mentre è necessario molto tempo per apportare modifiche a un file (ad es.molte ore o giorni) per cui impedire l'accesso alla modifica di un file rappresenta un'enorme inefficienza.

Tieni presente che Perforce non forza la metodologia di checkout, ma consente checkout simultanei (equivalenti all'unione).

Nella nostra ultima valutazione, Perforce ha battuto subversion nel supporto alla ramificazione e all'integrazione dei cambiamenti tra i rami.Era in corso il lavoro su Subversion per rimediare a questa lacuna, ma non siamo tornati per verificarlo.

In Perforce, quando si ramifica un file, Perforce "ricorda" da dove proviene e quali revisioni sono state "integrate" nelle due versioni.Ha anche alcune ottimizzazioni di archiviazione nel repository in modo che una copia del ramo non si materializzi realmente finché qualcuno non apporta una modifica nel ramo e quindi (se ho capito bene), utilizza le differenze rispetto alla copia di base, proprio come le revisioni all'interno di un ramo.

Il monitoraggio delle relazioni tra le filiali da parte di Perforce è una risorsa enorme.Se Subversion lo ha implementato ora, per favore dammi un avviso.

Forse intendevi Source Safe piuttosto che Perforce?Perforce supporta la fusione, e in effetti aveva un supporto di fusione migliore rispetto a SVN fino a SVN 1.5 dove furono aggiunte le fusioni con nome (così come gli elenchi di modifiche, che Perforce ha sempre avuto e mi dispiace molto passare a un negozio che utilizzava SVN, ma non lo faremo) t l'aggiornamento fino alla versione 1.5 è stato testato un po' più a lungo.)

Vale la pena notare che SVN e Perforce ti consentono entrambi di eseguire un checkout bloccato, quindi puoi eseguire il modello "non unito" se lo desideri, ma a parte forse la gestione dei binari con il controllo della versione, non vedo molto uso per questo.

Ad ogni modo, la risposta semplice alla tua domanda è "i modelli di unione sono di gran lunga migliori ogni volta che è coinvolto più di uno sviluppatore".

Se ho capito bene, Perforce rende di sola lettura tutti i file che non sono stati estratti.Questo è simile al comportamento in Microsoft TFS e VSS.Subversion d'altro canto non imposta attributi di sola lettura.IMO, il metodo Subversion è più semplice perché non devi preoccuparti di un client di controllo del codice sorgente per modificare i file: vai avanti e modifichi con sconsiderato abbandono e poi confronti ciò che è cambiato sul disco con il server quando sei pronto per effettuare il check-in.

Quando tutti i file sono di sola lettura, mi ritrovo a modificare costantemente un file, tentando di salvarlo, scoprendo che è di sola lettura, quindi dovendo passare al client di controllo del codice sorgente per verificarlo.Non è poi così male se il client di controllo del codice sorgente è integrato nel tuo editor, ma se stai memorizzando cose che non sono codice sorgente sotto il controllo della versione, spesso questa non è un'opzione.

Se ho capito bene, Perforce rende di sola lettura tutti i file che non sono stati estratti.

Questo è solo il comportamento predefinito.Se necessario, è possibile impostare i file che cambiano frequentemente in lettura-scrittura.Visualizza un elenco completo dei modificatori di file Qui.

Inoltre, per il mio ambiente, sto utilizzando Eclipse con Plug-in Perforce.Con questo plugin, la modifica di un file apre immediatamente il file per la modifica.

Non sono sicuro della ricerca, ma ecco un punto dati per te:
Il mio team ha scelto PVCS (checkout) principalmente per la comodità.I dubbi sulla fusione e la mancanza di consapevolezza di strumenti come Subversion hanno sicuramente contribuito a ciò.

Non sono sicuro di aver compreso la domanda qui: non sono a conoscenza di alcun moderno sistema di controllo del codice sorgente (diverso da Visual SourceSafe) che non supporti completamente l'unione.

Preferisco decisamente la metodologia di fusione.

Ho usato Visual Sourcesafe (speriamo mai più), CVS, subversion e bzr.Visual sourcesafe applica la metodologia "checkout prima della modifica" e può essere doloroso.Storicamente CVS e subversion non sono stati bravi ad accettare le fusioni, anche se ho sentito che subversion 1.5 ha migliorato la situazione.

Consiglierei di utilizzare un VCS progettato pensando alle fusioni frequenti fin dall'inizio.bzr è quello che ho usato che fa questo, ma lo fanno anche gli altri principali sistemi vcs distribuiti (git e mercurial).

Ma alla fine non conosco alcuna ricerca su quest'area specifica.In generale c’è pochissima ricerca sull’efficienza della programmazione, Articoli per la gente essendo una delle eccezioni degne di nota.

Non capisco proprio la domanda, a dire il vero.Ma posso garantire l'efficienza e la capacità di Perforce di gestire più di una persona che modifica un file in modo asincrono e di gestire l'unione delle modifiche.

In Perforce, se qualcuno archivia un file che stai anche modificando, alla successiva sincronizzazione dal server (ad es.ottieni i file più recenti) verrai informato che ci sono alcune modifiche che devono essere risolte.La scelta su quando farlo dipende da te.Quando "risolvi" un file, questo viene unito nella tua versione locale e gli strumenti sono utili per questo.

Avere una scelta su quando farlo è importante: potresti sincronizzarti in modo da poter ottenere alcuni aggiornamenti non direttamente correlati alla tua attività (correzione di bug, diciamo), e in quella fase non vuoi occuparti di capire se qualcun altro la modifica agli stessi file su cui stai lavorando avrà effetto su di te.Quindi vai avanti, esegui la creazione e il test, quindi risolvi i file nel tuo tempo libero.

L'altro caso è che invii le tue modifiche senza aver prima sincronizzato il file aggiornato.In questo caso, Perforce impedisce l'invio e contrassegna i file da risolvere.Qualsiasi sviluppatore sensato in questa fase eseguirà l'unione, quindi ricompilerà e/o testerà prima di inviare nuovamente la modifica a Perforce.

Ciò che mi piace di questo è che fa di tutto per impedirti di inviare modifiche al server centrale che non sono state elaborate esplicitamente, e quindi riduce al minimo le possibilità di interrompere la build.Il processo di risoluzione è semplice e ha costi molto bassi, quindi non c'è alcun problema di efficienza.

Perforce è molto esplicito nel darti scelta e controllo su come vengono propagate le modifiche e lo supporta con strumenti eccellenti per gestire l'unione delle modifiche.Personalmente mi piace la scelta e il potere di esercitare le scelte con facilità.Senza dubbio anche Subversion ha le sue alternative.

Immagino che probabilmente dipenda da ciò a cui sei abituato: non penso che ci sia un problema di efficienza significativo o misurabile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top