Realer Einsatz von Mercurial mit einem Team Foundation Server?

Mein Shop verwendet TFS und ist im Allgemeinen damit zufrieden, mit Ausnahme des Fehlens lokaler Commit-Commits / -Reverts. Ich beginne, Mercurial selbst lokal zu verwenden, um kleinere Änderungsblöcke zu verwalten und sie dann in TFS zu veröffentlichen. Ich sehe, dass Subversion eine 'Bridge'-Komponente hat, um dies automatisch zu aktivieren, wenn das zentrale VCS Subversion ist. Ich habe keine für Team System gefunden. Dies ermutigt mich, dass andere Leute diesen Weg mit der Integration von DVCS in CVCS-Systeme eingeschlagen haben.

(1) Kennt jemand einen? Ich bezweifle es irgendwie (die schnelle Suche hat nichts gefunden).

(2) Verwendet jemand Mercurial / TFS auf diese Weise? Wenn ja, können Sie Ihre Erfahrungen teilen. Ich bin besonders auf der Suche nach Erkenntnissen darüber, welche Probleme auftreten könnten, die in Bezug auf Commits an TFS nach erheblichen Aktivitäten über Mercurial nicht offensichtlich sind.

Bisher scheint es eine totale Win-Win-Situation zu sein, wenn ich nur ein paar Tage benutze - aber ich weiß genug, um zu denken, dass es einfach so einfach ist.

Ich bin mir nicht sicher, ob dies etwas ist, das Sie noch nicht wissen, aber ich verwende Mercurial bereits seit einiger Zeit lokal, und ich denke, dass die Vorteile den zusätzlichen Aufwand für die Verwaltung der beiden Versionsverwaltungssysteme überwiegen. So habe ich es gemacht:

1. Ich habe meine TFS-Kasse zu einem HG-Repository gemacht, das ich als meinen "Master" betrachte. Ich erhalte Updates von TFS und verpflichte sie zu diesem Repo, sodass dieser den aktuellsten Status des Projekts von TFS enthält. Wichtig hierbei ist, dass keine Änderungen daran vorgenommen werden, die unabhängig von einem TFS-Update oder einer Hg-Zusammenführung (Teil 2) vorgenommen wurden.

2. Immer wenn ich etwas ändern muss, klone ich mein "Master" -Repo und mache dort meine Arbeit. Ich habe festgestellt, dass ein Klon pro Feature oder Story eigentlich ziemlich einfach zu verwalten ist und sich ziemlich sauber anfühlt. Sobald ich eine Funktion abgeschlossen habe, führe ich eine Hg-Zusammenführung zum "Master" -Repo durch, auf das alle TFS-Updates angewendet wurden. Auf diese Weise kann ich Mercurials-Zusammenführungsfunktionen verwenden, die TFS so weit überlegen sind, dass in Frage gestellt wird, wie TFS behaupten kann, Code überhaupt zusammenzuführen. Sobald die Zusammenführung abgeschlossen ist, übertrage ich sie in Hg und überprüfe diese Änderungen in TFS. Das Beste daran ist, dass ich beim Einchecken in TFS nichts zusammenführen muss. Sehr sehr nett.

Hier sind die Probleme, die ich bei diesem Ansatz festgestellt habe:

1. Das größte Problem ist die Tatsache, dass TFS schlecht darin ist, Änderungen zu finden. Es gibt ein Make-Writable- Plugin, mit dem Sie die geänderten Dateien beschreibbar machen können, wenn sie von Mercurial aktualisiert / zusammengeführt werden. Dafür habe ich zwei Möglichkeiten gefunden. Sie können entweder TFS zwingen, offline zu gehen. Zu diesem Zeitpunkt wird davon ausgegangen, dass alles Beschreibbare eingecheckt werden muss, oder Sie können das Vergleichstool im Versionsverwaltungs-Tool verwenden, die geänderten Dateien auswählen und einzeln auschecken. Beide sind beschissen IMO

2. Die Quellcodeverwaltungsbindungen sind auf Projektebene weiterhin vorhanden, auch wenn Sie die TFS-Quellcodeverwaltungsdateien aus Ihrem hg-Repository ausschließen (was Sie tun sollten). Dies ist erst dann ganz offensichtlich, wenn Sie der Lösung eine Datei hinzufügen. Zu diesem Zeitpunkt wird versucht, sie der Quellcodeverwaltung hinzuzufügen. Sie können "Ausstehende Änderungen rückgängig machen" und das Hinzufügen der Quellcodeverwaltung entfernen, aber es ist wirklich ärgerlich.

Die gute Nachricht ist, dass ich diesen Ansatz verwendet habe, um eine ziemlich massive Fusion durchzuführen, von der ich glaube, dass ich mich einer Form von harten Drogen zugewandt hätte, wenn ich gezwungen gewesen wäre, die TFS-Tools zu verwenden, um dies zu tun.

Ich habe dies noch nicht auf die Aktualisierung von Zweigen in TFS angewendet, aber ich vermute, dass dies viel besser wäre als die Optionen, die Sie für das Zusammenführen in TFS erhalten. In einem ähnlichen Zusammenhang ist die Verwendung der TFS-Zusammenführung weniger problematisch, da Sie alle für eine Funktion erforderlichen Änderungen an einem Ort zusammenfassen können, da Sie Teile der Arbeitsfunktionalität gleichzeitig einchecken können.

Eine Sache, die ich nicht in Angriff genommen habe, ist, dies im gesamten Team zu teilen. Ein Grund dafür ist, dass es wirklich nicht teamweit sein muss. Ich arbeite remote, daher ist ein lokales Repository eine große Sache und spart viel Zeit. Die anderen Mitglieder meines Entwicklerteams können von diesem Ansatz profitieren oder auch nicht, aber ich finde es ziemlich cool, dass ich es kann, ohne ihre Arbeitsweise zu beeinträchtigen.

Update Ich wollte diese Antwort schon seit einiger Zeit mit zusätzlichen Informationen aktualisieren, die auf Kommentaren und einigen meiner Erfahrungen mit großen TFS-Repositorys basieren.

Wie @ Eric Hexter in den Kommentaren ausführt , können Sie zunächst die Rebase-Erweiterung verwenden , um Commits aus Ihren Arbeitsrepositorys besser in Ihr Haupt-TFS-Repository zu integrieren. Obwohl, je nachdem , wie Sie Ihre Commits TFS erscheinen sollten Sie das verwenden Zusammenbruch Erweiterung um die Änderungen zu quetschen in einem einzigen Commit (dies einfacher Rollbacks in TFS machen können). Es gibt auch den Befehl "online" von TFS PowerTools , mit dem TFS leichter wissen kann, was sich geändert hat (nochmals vielen Dank an Eric, der dies in seinem Blog-Beitrag erwähnt hat ).

Als ich das ursprünglich schrieb, arbeitete ich an einem Projekt, das nur einen TFS-Zweig hatte, den Entwickler verwendeten, und der ziemlich klein war, sodass das Klonen von Repositorys keine große Sache war. Später arbeitete ich an einem Projekt mit einem Repo, das nach dem Auschecken etwa 1,5 GB groß und nach dem Build viel größer war, und wechselte häufig zwischen Zweigen in TFS. Offensichtlich ist dieser Ansatz für diese Umgebung nicht gut geeignet (zumal es zu einem bestimmten Zeitpunkt unmöglich war, die Lösungen in einem beliebigen Verzeichnis zu erstellen.

Das Größenproblem lässt sich am besten lösen, indem eine Technik verwendet wird, die den Themenzweigen von gits ähnelt, anstatt die Repositorys in neue Verzeichnisse zu klonen. Hierfür gibt es einige Optionen. Ich denke, das Beste ist, die Lesezeichenerweiterung zu verwendenund erstellen Sie Themen- "Lesezeichen" anstelle von Themenzweigen. Sie können auch benannte Zweige verwenden, diese haben jedoch den leichten Nachteil, dass sie permanent sind und mit allen Klonen reisen, die Sie möglicherweise verwenden (wenn Sie Ihren raffinierten TFS-Hg-Hybrid mit einem Kollegen teilen möchten). Lesezeichen sind lokal für Ihr Repo und weisen effektiv auf ein Commit hin und reisen mit dem Kopf. Sie sind so implementiert, dass sie an jedem Ort verwendet werden können, an dem Hg eine Überarbeitung erwartet (also Zusammenführungen, Aktualisierungen usw.). Sie können diese verwenden, um ein TFS-Lesezeichen als primären "Zweig" zu erstellen, der nur Aktualisierungen von TFS erhält und aus der Themenarbeit zusammengeführt wird, für die jeweils eigene Lesezeichen vorhanden sind. Sie können diese löschen, sobald Sie sich wieder für TFS entschieden haben. Wenn Sie lieber benannte Zweige verwenden möchten, können Sie genau die gleichen Techniken anwenden, was praktisch ist.

Das Problem mit mehreren Zweigen ist jetzt schwieriger, insbesondere da TFS- "Zweige" tatsächlich Kopien jeder Datei aus dem ursprünglichen Zweig sind. Dies bedeutet, dass Ihr Repo jedes Mal, wenn Sie Zweige aus TFS ziehen, viel größer wird. Eine Möglichkeit, damit umzugehen, besteht darin, eine Kombination aus benannten Hg-Zweigen und Lesezeichen zu verwenden, sodass Sie für jeden TFS-Zweig einen Zweig haben, und dann Lesezeichen für Ihre Arbeit aus diesen Zweigen zu erstellen. Die wirklichen Kopfschmerzen in diesen Szenarien sind tatsächlich die Behandlung von TFS-Arbeitsbereichen durch all dies. Sie können die Zuordnungen in Ihren Arbeitsbereichen entfernen und ziemlich weit kommen. Wenn Sie jedoch wieder Ihrem Arbeitsverzeichnis zugeordnet sind, müssen Sie darauf achten, dass TFS nicht auf Dateien stampft (hier bieten sich die TF PowerTools an). Der Versuch, den Arbeitsbereich angeschlossen zu lassen, während Sie die Zweige wechseln, wird schnell hässlich. Ein paar Werkzeuge, die schön in Ihrem Werkzeuggürtel zu haben sind, sind die HgPurge-Erweiterung und der TF PowerTools-Befehl "scorch". Beide entfernen effektiv Dateien, die sich nicht in der Versionskontrolle befinden (technisch "scorch" stellt sicher, dass TFS und Ihr lokales Arbeitsverzeichnis übereinstimmen, sodass auch Dateien aktualisiert werden können).

Für mich wurde dieser Prozess jedoch ziemlich lästig und fehleranfällig. Ich habe kürzlich auf die Verwendung von git mit git-tfs umgestellt , da es TFS-Arbeitsbereiche für mich verwaltet und einen Großteil der mit dieser Seite verbundenen Belastung beseitigt. Leider scheint es nirgendwo da draußen ein "hg-tfs" zu geben, oder ich hätte das wahrscheinlich gewählt.

Wenn Sie nicht auf mercurial fixiert sind, gibt es ein süßes git / tfs-Integrationsprojekt namens git-tfs, das ich verwendet habe. Es ist git-svn sehr ähnlich, drückt aber stattdessen von TFS. Überprüfen Sie es unter http://github.com/spalts/git-tfs

@ Eric, dein Beitrag bei lostechies war sehr hilfreich. Mit VS2010 musste ich dem Befehl tftp online im Push-Skript die Optionen / diff und / deletes hinzufügen , um geänderte und gelöschte Dateien in TFS einzuchecken. Am Anfang war ich einen Fehler von Push bekommen , wenn eine Datei (von -Arbeiten) gelöscht wurde hg update ist „nicht in der Lage zu entfernen FileXyz : Zugriff verweigert“. Ich habe die Erweiterung MakeWritable.py installiert, aber das funktioniert nur, wenn Dateien geöffnet und nicht gelöscht werden. Also habe ich einen Aufruf von attrib hinzugefügt , um das READ-ONLY aus allen Dateien im Projekt zu entfernen und es anschließend wiederherzustellen (mit Ausnahme des .hg-Ordners). Außerdem habe ich das / diff hinzugefügt

Option, damit Unterschiede von der MD5-Prüfsumme erkannt werden, anstatt vom READ-ONLY-Attribut abhängig zu sein. Scheint jetzt gut zu funktionieren.

=====FILE: push.ps1=====
$projName = "TicTacToeCMMI"
$tftp = "C:\Program Files\Microsoft Team Foundation Server 2010 Power Tools\TFPT.exe"
$tf = "C:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\tf.exe"

hg push
cd ..\$projName-tfs  
"Syncing -tfs workspace with TFS server"  
&$tftp scorch /noprompt /exclude:.hg',_Resharper*',*.user  
"Making all files in -tfs writable"
attrib -R /S /D *
"Updating -tfs with latest push from Mercurial"
hg update -C -y
attrib +R /S /D *
attrib -R /S /D .hg\*
"Resyncing Mercurial changes with TFS Server"  
&$tftp online /adds /deletes /diff /exclude:'.hgignore,.hg,bin,obj,*.ps1,_Resharper*,*.lnk,*.user,*.suo,*.vspscc'  
"Checkin"  
&$tf checkin  
cd ..\$projName-working  
cmd /c pause  

====FILE: pull.ps1=====
$projName = "TicTacToeCMMI"
$tf = "C:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\tf.exe"
$username = cmd /c set USERNAME
$username = $username.SubString($username.IndexOf("=")+1)

function pull {
    cd ..\$projName-tfs
    &$tf get
    hg commit -A -m "from tfs" --user $username
    cd ..\$projName-working
    hg pull --rebase
}
pull  
cmd /c pause  

Ich hatte eine gewisse Lernkurve mit PowerShell-Skripten, die ich zuvor noch nicht verwendet hatte. Für andere wie mich werden die Skripte mit einer Verknüpfung wie dieser ausgeführt:

TARGET: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe C:\dev\TicTacToeCMMI-working\push.ps1
START IN: C:\dev\TicTacToeCMMI-working

Ich habe Push- und Pull-Verknüpfungen in meine Taskleiste eingefügt, sodass das Drücken / Ziehen zu / von TFS mit einem einzigen Klick erfolgt

Ich weiß, dass einige Leute hgsubversion mit der Subversion-Brücke verwendet haben. Ich weiß nicht, wie gut es funktioniert hat, und ich musste TFS nie verwenden.

Soweit mir bekannt ist, gibt es keine "nativere" Bridge als TFS -> Subversion Bridge -> hgsubversion, aber ich habe auch gehört, dass es ziemlich gut funktioniert. Mein äußerst begrenztes Verständnis von TFS legt nahe, dass sein internes Modell Subversion ähnlich genug sein sollte, damit Dinge wie hgsubversion wirklich gut funktionieren.

Wenn Sie mit DVCS und TFS arbeiten möchten, ist es meiner Meinung nach am besten, die SVNBridge für TFS zu installieren und Bazaar zu verwenden. Dies ist AFAIK , das einzige DVCS, das sich problemlos in SVN integrieren lässt, und seit Ihrem TFS sieht aus wie ein SVN, Sie erhalten auf magische Weise Bazaar / TFS-Integration

Hier ist ein Powershell-Skript, mit dem ich mit TFS & hg gearbeitet habe. Um es zu verwenden, müssen Sie ein hg-Repository in Ihrem TFS-Ordner erstellen (die Dateien von TFS darin festschreiben), dieses Repository klonen und am neuen Repository arbeiten. Sobald Sie zufrieden sind, können Sie "hgtfs.ps1 push" ausführen, um die Änderungen aus Ihrem Quecksilber-Repository zurück in TFS zu übertragen.

hgtfs.ps1:

param([parameter(Position=0, Mandatory=$true)][string] $action)

$HGDirectory = Get-Location
$TfsDirectory = @(hg paths | where-object { $_.StartsWith("default = ") })[0].SubString(10)

# Pull from TFS
function pull
{
    # Todo pull changes one by one brining who did it and the comment into HG
    # tf history . /recursive /format:brief /noprompt /version:300~1000 /sort:ascending
    # tf properties . /recursive

    # Add the changes from TFS into the TFS HG repository
    Set-Location $TfsDirectory
    tf get . /recursive
    hg commit -A -m "Update from TFS"  

    # Pull / merge the changes from TFS's HG repository
    Set-Location $HGDirectory
    hg pull
    hg merge --tool internal:fail
    hg commit -m "Merged from TFS"

    ""
    "The you have the following conflicts which need resolving"
    hg resolve -l | write-host -foregroundcolor "red"
    #thg commit
}

# Push to TFS
function push 
{
    Set-Location $HGDirectory
    hg push
    Set-Location $TfsDirectory

    $FilesModified = @()
    $FilesRenamed = @{} # Key: old file name .... Val: new file name
    $FilesRemoved = @()
    $FilesAdded = @()

    # Work out what changes have taken place
    "Calculating the changes which have been made in HG..."
    tfpt scorch /exclude:.hg,*.user | out-null
    $AllChanges = hg status --rev .:tip -A 
    for($i = 0; $i -lt $AllChanges.length ; $i++)
    {
        $type = $AllChanges[$i].SubString(0, 2)
        $fileName = $AllChanges[$i].SubString(2)

        switch($type)
        {
            "M " # Modified files  
                { 
                    $FilesModified += $fileName
                } 

            "A " # New Files
                {  
                    $nextType = $null
                    $nextFileName = $null
                    if($AllChanges.length -gt ($i+1))
                    {
                        $nextType = $AllChanges[$i+1].SubString(0, 2)
                        $nextFileName = $AllChanges[$i+1].SubString(2)                
                    }

                    if($nextType -eq "  ")
                    {
                        # we have a rename
                        $FilesRenamed[$nextFileName]=$fileName
                        $i++
                    }
                    else
                    {
                        # we're adding the file
                        $FilesAdded += $fileName
                    }
                 }

            "R " # Removed
                {
                    if($FilesRenamed.ContainsKey($fileName))
                    {
                        continue
                    }

                    $FilesRemoved += $fileName
                }

            "C " # Same 
                { 
                    continue 
                }

            default 
                { 
                    "Unknown HG status line: "+$AllChanges[$i] 
                    return -1
                }
        }
    }

    # perform the TFS operations 
    "Renaming files in TFS..."
    foreach($file in $FilesRenamed.Keys) {   
        tf checkout $file | out-null
        tf rename $file $FilesRenamed[$file] | out-null
    }

    "Checking out for edit in TFS..."
    foreach($file in $FilesModified) { tf checkout $file | out-null }

    "Removing files from TFS..."
    foreach($file in $FilesRemoved) { tf delete $file | out-null }

    # perform the Mercural update
    "Pulling changes out of HG...."
    hg update --rev .:tip --clean

    # perform any POST TFS operations
    "Adding new files to TFS..."
    foreach($file in $FilesAdded) { tf add $file }

    "Cleaning up..."
    tfpt uu /noget
    tf checkin
}


if ($action -eq "push") { push }
elseif ($action -eq "pull") { pull }
else { "Unknown action ... please supply 'push' or 'pull'" }

# return to our starting point
Set-Location $HGDirectory

Ich habe gerade ein kleines Tool zusammengestellt, HgTfs, das versucht, das Ziel der Synchronisierung von Mercurial- und TFS-Repositorys zu erreichen. Es ist wirklich einfach und hat nur drei Befehle: Klonen, Ziehen und Drücken. Hier ist mein Bitbucket-Repo:

https://bitbucket.org/thepretender/hgtfs

Es gibt auch einen Blog-Beitrag, der die Workflow- und Nutzungsszenarien beschreibt (eigentlich sind Wiki-Seiten nur Teile dieses Blogeintrags):

http://www.olegtarasov.me/Post/2013/07/Mercurial-to-TFS-bridge-(hgtfs)

Der Code ist hackig, aber er scheint die Arbeit zu erledigen. Ich würde mich über Feedback oder Gabeln sehr freuen :)

Ich hatte einen guten Versuch, es zum Laufen zu bringen. Ich konnte Git und TFS über svnbridge zusammen spielen lassen ( Link ), aber ich konnte Mercurial nicht dazu bringen, über svnbridge zu arbeiten, was mich ohne Ende frustrierte. Wenn Sie es schaffen, es zum Laufen zu bringen, lassen Sie es mich wissen, denn ich persönlich bevorzuge Quecksilber gegenüber Git (obwohl beide großartig sind).