टीएफएस 2010

Question

में एक ब्रांचिंग रिलेशनशिप निकालें मेरे पास एक टीएफएस 2010 टीम प्रोजेक्ट है जिसे मैंने अभी ले लिया है। ब्रांचिंग पदानुक्रम है कि देव टेस्ट का बच्चा है, टेस्ट मुख्य का बच्चा है।

Main

----Test

--------Dev

अतीत किसी में कुछ बिंदु पर

हालांकि देव और मुख्य बीच एक निराधार मर्ज किया है। इससे भ्रम का एक बड़ा सौदा हो रहा है क्योंकि डेवलपर्स अब गलती से देव से मेन तक कोड विलय कर रहे हैं।

यह कोड सही प्रक्रिया का पालन करते समय अप्रत्याशित मर्ज विवादों के साथ दर्द का कारण बन रहा है और टेस्ट से मेन में विलय कर दिया गया है, साथ ही संभवतः एक परिदृश्य भी बना रहा है जहां मुख्य शाखा में अवांछित कोड को बढ़ावा दिया जाता है।

शाखा और हटाने के बिना देव और मुख्य के बीच शाखा संबंधों को हटाने का कोई तरीका है? मैं देव शाखा और टेस्ट के साथ इसका रिश्ता रखना चाहता हूं। बस मुख्य के साथ संबंध हटा दें।

मैंने संबंधों को हटाने के लिए शाखा को एक फ़ोल्डर में बदलने की कोशिश की है लेकिन यह काम नहीं करता है। मैं शाखा को पुनर्निर्मित कर सकता हूं लेकिन रिश्ते को पूरी तरह से हटाने का कोई स्पष्ट तरीका प्रतीत नहीं होता है। मैं शाखा को एक फ़ोल्डर में परिवर्तित कर सकता हूं, फिर इसे हटा सकता हूं और टेस्ट से रीब्रैंच कर सकता हूं लेकिन इसका मतलब यह होगा कि कोडबेस सिंक्रनाइज़ किया गया है जो हासिल करना मुश्किल हो सकता है।

Answer 1

टीएफएस आवश्यक रूप से पीछे की संगतता के लिए शाखा वस्तुओं के आधार पर मर्ज उम्मीदवारों का निर्माण नहीं करता है (शाखा वस्तुओं को टीएफएस 2010 में नया था) और आधारहीन विलय का समर्थन करने के लिए (एक बार जब आप दो पथों के बीच आधारहीन विलय करते हैं, तो उन्हें एक के साथ संग्रहीत किया जाएगा भविष्य में विलय के लिए रिश्ते विलय करें।)

मैं यहां एक कस्टम चेक-इन नीति का उपयोग करने का सुझाव दूंगा जो यह बताता है कि विलय -> टेस्ट या टेस्ट -> देव से विलय हो जाता है और मध्यवर्ती स्तर को छोड़ नहीं देता है। यह आपको देव को शाखा वस्तु के रूप में रखने की अनुमति देता है, इसलिए आपको अभी भी शाखा दृश्यता जैसी सभी अच्छी सुविधाएं मिलेंगी।

मैं अपने मन में एक बहुत ही मोटा, बहुत छद्म-कोडी उदाहरण प्रदान कर सकता हूं। (यह दोनों नाराज है क्योंकि मैं आलसी हूं और क्योंकि मैं अपना समय जावा एसडीके में खर्च करता हूं, न कि .NET SDK और मुझे एहसास है कि ज्यादातर लोग .NET चेक-इन नीति चाहते हैं। लेकिन अधिकतर क्योंकि मैं आलसी हूं।)

/* 
* Create a dictionary of merge targets to allowable merge sources. 
* For an item in this list, the allowable merge sources are a whitelist. 
*/ 
private readonly Dictionary<String, List<String>> restrictedMergeTargets = 
    new Dictionary<String, List<String>>(); 

public static MergeWhitelistPolicy 
{ 
    /* Only allowed merges to $/Main from $/Test. */ 
    List<String> mainWhitelist = new List<String>(); 
    mainWhitelist.add("$/Test"); 
    allowedMerges.put("$/Main", mainWhitelist); 

    /* Only allow merges to $/Test from $/Dev. */ 
    List<String> testWhitelist = new List<String>(); 
    testWhitelist.add("$/Dev"); 
    allowedMerges.put("$/Test", testWhitelist); 
} 

public PolicyFailure[] evaluate(PolicyContext context) 
{ 
    PendingChange[] pendingChanges = GetPendingCheckin().GetCheckedPendingChanges(); 

    foreach(PendingChange change : pendingChanges) 
    { 
     if(! change.IsMerge()) 
     { 
      continue; 
     } 

     foreach(KeyValuePair<String, List<String>> restrictedTarget : restrictedMergeTargets) 
     { 
      if(VersionControlPath.IsChild(restrictedTarget.GetKey(), change.GetServerItem()) 
      { 
       /* Whitelisted merge path - investigate. */ 
       foreach(String allowedSource : restrictedTarget.GetValue()) 
       { 
        foreach(MergeSource mergeSource : change.GetMergeSources()) 
        { 
         if(! VersionControlPath.IsChild(allowedSource, mergeSource.GetServerItem())) 
         { 
          return new PolicyFailure("Merge from " + 
           mergeSource.GetServerItem() + " to " + 
           change.GetServerItem() + " is disallowed."); 
         } 
        } 
       } 
      } 
     } 
    } 

    return null; 
} 

इसके साथ कई मुद्दे हैं। आप निश्चित रूप से पॉलिसी में स्वीकार्य विलय संबंधों की सूची को हार्डकोड नहीं करना चाहते हैं - आप इसे कॉन्फ़िगरेशन फ़ाइल में बाहरी कर सकते हैं, या आप सर्वर पर विलय संबंधों से पूछ सकते हैं और यदि आपके पास विशेष नियम थे जैसे केवल प्रत्यक्ष वंशज मर्ज करें। (यह कैशिंग महत्वपूर्ण है क्योंकि चेक-इन नीति मूल्यांकन अक्सर चलता है और तेजी से होने की उम्मीद है। यह कभी-कभी यूआई थ्रेड पर भी चला सकता है (हालांकि मुझे शक है), इसलिए आपका माइलेज भिन्न हो सकता है।)

इसके अलावा, मेरे पथ परीक्षण कोड बहुत ही मैला है, ज्यादातर मेरी टिप्पणी में कुछ जगह बचाने के लिए। (और, मेरे हिस्से पर उपरोक्त आलस्य।)

मुझे आशा है कि यह एक अच्छी शुरुआत है।

Answer 2

उत्कृष्ट सवाल!मेरे पास सीधा जवाब नहीं है लेकिन मेरे पास भविष्य की घटनाओं के जोखिम को कम करने के लिए सुझाव है:

गंभीर रूप से मुख्य शाखा के लिए मूल शाखाओं में विलय करने के अधिकार रखने वाले अधिकारों को प्रतिबंधित करें। मैं एक देव लीड या सीनियर देव को एक शाखा मालिक के रूप में नामित करता हूं जो आरआई के लिए जिम्मेदार है उस शाखा में विलीन हो जाता है। (व्यवस्थापक अतिरिक्त विशेषाधिकारों की आवश्यकता के बिना भी कवर कर सकते हैं।)

बेसलेस विलय एक नए रिश्ते को बनाने के बाद यह आपकी मदद नहीं करता है, लेकिन भविष्य में अनपेक्षित पुनरावृत्ति के जोखिम को कम करना चाहिए। एक वैध मामला भी हो सकता है जहां आपकी टेस्ट शाखा जंपिंग आवश्यक होगी, लेकिन मैं ऐसा करने के किसी भी अच्छे कारण के बारे में नहीं सोच सकता।