2009-08-25 13 views
0

Ich arbeite schon seit einiger Zeit mit Team Foundation und finde ein Verhalten besonders ärgerlich. Sagen, dass ich mehr Team Projekte habe:So verhindern Sie, dass Team Foundation die Sperren rückgängig macht

$/ 
    Project1 
    Project2 

nun aus Gründen wir nicht wirklich in erhalten müssen, ich bin zu wollen $/Project2 gesperrt zu halten, jemand anderes zu verhindern, etwas zu tun es. Normalerweise, wenn Sie auf einer bestimmten Ebene der Struktur einchecken, ist alles auf dieser Ebene und darunter im Check-in enthalten.

In diesem Fall jedoch, wenn ich einen Check-in zu irgendetwas unter $/Project1, in der Liste der Elemente zum Einchecken enthalten ist die Sperre auf $/Project2. Wenn ich nur auf OK klicke, verschwindet mein Schloss. Gibt es eine Möglichkeit, dieses Verhalten zu verhindern?

Antwort

2

Verwenden Sie verschiedene Arbeitsbereiche. Sperren, Checkouts und Checkins sind auf den Arbeitsbereich beschränkt.

Sobald die Arbeitsbereiche eingerichtet sind, ist ihre Verwendung weitgehend transparent (vor allem, wenn Sie sich beim Auschecken auf den neuesten Stand bringen).

2

Mein erster Vorschlag wäre der gleiche wie Richards, verwenden Sie einen anderen Arbeitsbereich.

Eine andere Möglichkeit besteht darin, keine Sperren zu verwenden, sondern die Sicherheitsberechtigungen für das Teamprojekt so zu ändern, dass nur Sie Dateien darin überprüfen können. Um Berechtigungen zu ändern, klicken Sie mit der rechten Maustaste auf den Ordner im Source Control Explorer, wählen Sie Eigenschaften ... und dann die Registerkarte Sicherheit.

Sie können das Kontrollkästchen "Sicherheitseinstellungen übernehmen" deaktivieren und dann zulassen oder ablehnen, wie Sie es für richtig halten. Seien Sie jedoch sehr vorsichtig, wenn Sie die Sicherheit bearbeiten, da Sie den Ordner versehentlich so einstellen können, dass selbst Sie die Einstellungen nicht wiederherstellen können. Sehen Sie im folgenden Top-Tipp, wenn Sie sich in diese Situation kommen:

1

Ich bin damit einverstanden, sollten Sie einen separaten Arbeitsbereich für „langlebige“ Schlösser verwenden. Macht das Leben viel einfacher. Sie müssen nicht einmal einen Ordner auf der Festplatte erstellen. Ordnen Sie einfach $/an einer beliebigen Stelle zu, klicken Sie auf Nein, wenn Sie zur Synchronisierung aufgefordert werden, und sperren Sie sie.

ABER ...

Normalerweise, wenn Sie ein Check-in auf einer bestimmten Ebene des Baumes zu tun, alles, was auf dieser Ebene und unten in der Check-in enthalten. Allerdings, wenn ich etwas unter $/Project1 einchecke, in der Liste der Elemente zum Einchecken enthalten ist die Sperre auf $/Project2.

Ich kann das nicht reproduzieren. Mit VS 2008 SP1 sehe ich das gleiche Verhalten wie immer: Die vollständige Liste der ausstehenden Änderungen in diesem Arbeitsbereich wird im modalen Dialogfeld "Checkin" angezeigt, aber nur die Elemente, die für meinen rechten Mausklick (SCE oder Projektmappen-Explorer) gelten, werden überprüft .

Vielleicht verwenden Sie das Toolfenster für ausstehende Änderungen? Ich benutze es die ganze Zeit, aber eine Sache, die es tut, ist nicht do Scope selbst zu einem bestimmten Ordner. Das heißt, es hat haben eine viel zu versteckte Eigenschaft, die die anderen Checkin Einstiegspunkte nicht: eine Schaltfläche "Filter nach Lösung". Es ist das Symbol ganz rechts vor dem Dropdown-Menü Arbeitsbereich. Vielleicht finden Sie es nützlich - und nicht nur in diesem Fall.

+0

Hmm. Ärgerlich, dass es nicht reproduzierbar ist. Ich sehe es sowohl im Quell- als auch im Projektmappen-Explorer. –

0

Ich denke, ich habe es jetzt herausgefunden.

Als Richard Berg erklärte:

die komplette Liste der anstehenden Änderungen in diesem Arbeitsbereich in der Checkin modalen Dialog angezeigt wird, sondern nur die Elemente scoped meine rechte Maustaste (entweder von SCE oder Mappen-Explorer) ist überprüft.

Was ich jedoch beobachte ist, dass dies für Dateien gilt; Bei Ordnerbezogenen Aktionen sind jedoch alle ausstehenden Ordneränderungen immer enthalten. Und da das Schloss, das ich aufbewahrte, im Ordner lag, wurde es in der Liste der anstehenden Änderungen angekreuzt.

Ich stimme den anderen zu (und habe Upvoted), dass die Verwendung separater Arbeitsbereiche eine bessere Lösung ist, aber zu dem Zeitpunkt, als ich viele Änderungen in diesem gesperrten Ordner hatte, war es nicht sinnvoll den Arbeitsbereich zu wechseln .

+0

Interessant! Dies verdient es, auf Connect abgelegt zu werden. –

Verwandte Themen