Configuration Management con Subversion e SharePoint aiuto

Question

Ok, quando assunto alla mia società attuale di un anno fa, mi è stato affidato il compito di migrazione nostri team di sviluppo da VSS. Hanno già avuto nelle loro menti che volevano Subversion, e dato che ho avuto esperienza come usare e configurare la sovversione, ero un buon candidato. Ho provato a vendere TFS perché woul Dhave risolto il problema mi trovo in questo momento, ma dal momento che il denaro è stretto, e Subversion è libero ... beh si ottiene. Ad ogni modo, ho finalizzato Ricatto d'amore e l'unica cosa in piedi nel modo è il seguente.

ho proposto che conserviamo solo il nostro codice sorgente in SVN, e tutta la documentazione, build di rilascio, e di altri artifracts progetto essere memorizzati nel nostro portale SharePoint, in modo che non c'è bisogno di dare alle parti interessate non sviluppatori l'accesso a SVN. Quando ho presentato la proposta, tutto era eccettuato, ma la questione è stata sollevata su come gestire la sincronizzazione tra i manufatti (Es: come è documento X versione 3.1.2 associata a 4.5.2 release). La mia reazione iniziale è quello di creare una sezione nella pagina SharePoint porject per ogni nuova versione che conterrà i artificats (e tenere traccia dei cambiamenti troppo). C'è un modo migliore di fare questo? Qualcuno sa di chiunque faccia questo? O tutti i pacchetti di integrazione per la sincronizzazione SVN con SharePoint?

Ecco alcune informazioni su l'ambiente di sviluppo le aziende. Tutto il nostro software è per uso interno, vendiamo nessuno di esso, così i nostri clienti sono tutti in-house. Abbiamo 2 tipi di sviluppatori: 1. coloro che si prendono cura di manutenzione e personalizzazione di software di terze parti, e 2. Coloro che scrivono software proprieatry (che è dove cado). Il nostro software che scriviamo è in gran parte NET, ma il software 3rd party è tutto il bordo (COBAL, C, FORTRAN, altre stronzate che non quelli si preoccupa più).

Si prega di comunicare, come ho bisogno di arrivare a questo presentata al più presto. I HATE VSS !!!!!!!!!! e ho bisogno di sollievo!

Answer 1

Cosa facciamo internamente sta mettendo tutti i documenti sotto il nostro sistema di controllo di versione, penso che sia molto più facile. Poi, naturalmente, si deve dare accesso ai non-sviluppatori.

Nel tuo caso, utilizzando SVN, perché non si mette tutto dentro e quindi utilizzare l'interfaccia web per dare accesso alle parti interessate? E 'abbastanza facile per loro :-P

Answer 2

Vorrei usare SVN per entrambi i documenti e il codice sorgente.

I vantaggi:

• È possibile sincronizzare versioni documenti con versioni di fonte codice.
• Hai tutto in un unico luogo, in modo da non ci sono due repository di amministrare.

Svantaggi:

• si sarebbe probabilmente necessario per gestire il diritti di accesso per alcune parti interessate ad alcune parti della documentazione strutture.
• SVN non è lo strumento più appropriato per la gestione dei documenti

Al fine di risolvere le eventuali modifiche simultanee al stesso documento, è possibile utilizzare SVN svn proprietà:. Esigenze-lock per questi articoli, per renderli modificabili da una sola persona, che blocca l'elemento

Come ha detto Pablo, è possibile accedere ai documenti (almeno per leggerli) attraverso l'interfaccia web.

Answer 3

Si potrebbe esporre il repo svn tramite l'interfaccia web e link a quella in SharePoint. In questo modo le persone che hanno bisogno di modificare i documenti devono poter accedere a Subversion ma chiunque potrebbe facilmente accedere ai documenti "sola lettura".

Answer 4

Nella nostra organizzazione, abbiamo docs / artefatti, il codice tutto in SVN e abbiamo dato l'accesso alle parti interessate non tecnici e che fanno uso di client di tartaruga.

tuttavia è possibile guardare la seguente opzione

• Opzione 1: creare un'interfaccia ASP.Net per utenti non tecnici

Si può costruire una semplice interfaccia web in ASP.net, configurare che con un singolo utente in modo da non dover creare utenti distinti per tutti i soggetti interessati non tecnici e avrebbero ottenere l'accesso ai documenti con adeguato controllo di versione, ecc si poteva guardare sharpsvn per l'aspetto attuazione. Lo svantaggio di questo approccio sarebbe quello che si potrebbe avere a investire un po 'di tempo nello sviluppo di questa applicazione

• Opzione 2: naturalmente, creare utenti separate per ciascuna delle parti interessate non-sviluppatore

Answer 5

Questa risposta è probabilmente troppo tardi per voi implementazione, ma il percorso di integrazione più semplice potrebbe essere quella di memorizzare i documenti in SVN e quindi pubblicare per SharePoint con uno svn-hook.

Costruire manufatti potrebbero essere programmaticamente pubblicati nello stesso modo da costruire script.

È possibile caricare i documenti a SharePoint utilizzando un semplice POST

vale a dire.

http://blogs.msdn.com/rohitpuri/archive/2007/04/10/upload-download-file-to-from-wss-document-library-using-dav.aspx

Answer 6

Probabilmente un po 'in ritardo, troppo, ma vorrei evitare di mettere i documenti in SVN se si dispone di una configurazione del sistema SharePoint. Anche se SVN fa un ottimo lavoro per il codice sorgente, per la gestione dei documenti che non fornisce la facilità d'uso di SharePoint. Se si dispone già di installazione e siete una rete principalmente basato su MS, SharePoint fa un sacco di senso e in grado di gestire il controllo di revisione per la documentazione basato su MS molto meglio di SVN.

Sì, è possibile gestire l'accesso ai documenti SVN con le esigenze-lock, ma è probabile che ad un certo punto avrete un non-sviluppatori che necessitano di accedere ai documenti. Spiegando SVN a un non-sviluppatore, non-techie non è una cosa facile.