2012-03-27 18 views
6

मैंने एक परिवर्तन सेट की समीक्षा के लिए सबमिट किया है। दुर्भाग्य से मैं पहले अपने सैंडबॉक्स को रीफ्रेश करना भूल गया, इसका मतलब है कि मैंने उस सेट में कुछ बदलाव शामिल नहीं किए हैं।मैं आरटीसी (ग्रहण) पुनः संपादन योग्य में एक परिवर्तन सेट कैसे कर सकता हूं?

इसलिए मैंने अपने परिवर्तन सेट में परिवर्तन जोड़ने का विकल्प खो दिया।

मैं उस परिवर्तन सेट को त्यागना नहीं चाहता क्योंकि इसमें महत्वपूर्ण परिवर्तन हैं। मैं भी 2 परिवर्तन सेट वितरित नहीं करना चाहता, क्योंकि उनमें परमाणु तर्क होता है (तर्क जिसे विभाजित नहीं किया जा सकता है)।

मुझे यह महसूस हो रहा है कि "रिवर्स" विकल्प मेरे परिवर्तन को एक संपादन योग्य स्थिति में वापस ले जाएगा, लेकिन मुझे वास्तव में पता नहीं है कि यहां क्या करना है।

समेकित करने के लिए: मुझे अपना परिवर्तन फिर से संपादन योग्य बनाने की आवश्यकता है, ताकि मैं इसे किसी अन्य के साथ विलय कर सकूं।

कोई भी जानता है कि मैं यह कैसे करूं?

Thx, आप लोग शासन करते हैं!

+0

मैं एक समान समस्या में भाग गया। मैंने पूरा करने के लिए एक परिवर्तन सेट सेट किया है (सुनिश्चित नहीं है कि मैंने ऐसा क्यों किया) और फिर मैंने इसे वितरित करने का प्रयास किया। लेकिन फिर टीम सलाहकार ने डिलीवरी को अवरुद्ध कर दिया क्योंकि एक फ़ाइल में एक आवश्यक टिप्पणी शीर्षलेख गुम था। इस बिंदु पर मैं अटक गया था, मैं फ़ाइल नहीं बदल सका क्योंकि परिवर्तन सेट पूरा हो गया था और मैं परिवर्तन सेट नहीं दे सका। मैंने टिप्पणी नियम को ओवरराइड करके इसे ठीक किया और फिर मैंने एक और परिवर्तन सेट में टिप्पणी को जोड़ा। यह एक बदतर जाल की तरह लगता है, जैसे एक वीडियो गेम में एक मृत अंत में पकड़ा और खेल को रीसेट करना। –

उत्तर

7

मुझे नहीं लगता कि आप अपने परिवर्तन सेट के लिए एक उत्परिवर्तनीय स्थिति में वापस लौट सकते हैं, अगर उस परिवर्तन सेट को समीक्षा के लिए सबमिट करने से पहले "पूरा" किया गया था।

उस मामले में, एक "रिवर्स", एक नया changeset जिसमें आप अपने काम फिर से करना और के बाद (यानी पिछले changeset रद्द एक नया changeset कर रही है) की समीक्षा के लिए इसे पुनः सबमिट एकमात्र समाधान हो सकता है।

हालांकि, code review in RTC के इस उदाहरण के बाद, समीक्षा के दौरान सेट सेट को निष्क्रिय करने योग्य होना चाहिए (मूल प्रोग्रामर के लिए समीक्षाकर्ताओं की प्रतिक्रिया के आधार पर अपनी फाइलों के नए संशोधन की जांच करने के लिए)।

+1

मैं आपको प्यार करना शुरू कर रहा हूं: डी –

4

आपको नया परिवर्तन सेट बनाना चाहिए।

मैं दो कारणों से यह कहना:

1) केवल एक परिवर्तन काम आइटम के आधार पर तय होने के लिए सौंदर्य तर्क जल्दी से व्यवहार में टूट जाती है - यह एक परिवर्तन भूल करने के लिए आसान है, और आप करना पड़ सकता है बग या समीक्षा टिप्पणियों के कारण संशोधन।

2) कई परिवर्तन सेट होने से आपके परिवर्तनों को समझना आसान हो जाता है। प्रत्येक परिवर्तन सेट में परिवर्तनों का तार्किक सेट हो सकता है, इसलिए एक एकल कार्य आइटम में तीन परिवर्तन सेट हो सकते हैं: "रिएक्टर कोड", "अद्यतन कॉपीराइट", और "समीक्षा से परिवर्तन"। इस तरह, जब कोई भविष्य में फ़ाइलों को एनोटेट करता है, तो उन्हें प्रारंभिक कार्य आइटम की तुलना में एक बेहतर ग्रैन्युलरिटी पर कुछ मिल जाएगा।

"परमाणु तर्क" तर्क के संबंध में: यह संभवतः कोई मुद्दा नहीं है जब तक कि आपकी टीम अलग-अलग परिवर्तन सेटों को वितरित/त्यागने की आदत में न हो। आरटीसी परियोजना पर, हम नियमित रूप से कई परिवर्तन सेटों और एकाधिक घटकों में तर्कसंगत रूप से अलग परिवर्तनों को विभाजित करते हैं।

यदि आप चिंतित हैं कि आप परिवर्तन सेट वितरित कर सकते हैं जो तर्कसंगत रूप से अन्य घटकों में परिवर्तनों पर निर्भर करता है (जैसा कि मैं कभी-कभी करता हूं), तो मेरा सुझाव है कि आप bug 150421 पर चिल्लाएं। Bug 153907 एक समान समस्या का वर्णन करता है, लेकिन इसके लिए एक अधिक जटिल समाधान की आवश्यकता होती है (इसे ग्राहक दबाव के बिना लागू करने की संभावना कम होती है)।

+2

कई बदलावों पर पूरी तरह से सहमत हैं। +1 – VonC

+0

उस स्थिति में, मैं आपकी टिप्पणी करूंगा! :) – Erigami

+0

लेखक से भी +1। ऐसा नहीं है कि आपके +1 या किसी भी +1 की आवश्यकता है: पी –

1

मैंने एक ही मुद्दे में भाग लिया, और एक पैच बनाने का फैसला किया, मेरे परिवर्तनों को त्याग दिया और फिर एक नया परिवर्तन बनाया।