Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Arthur, Ok, let me see if I can explain the process we've been using with 2.0.58d and why we do it: We do releases on a regular cycle every three months. However some of the new features we add often take much longer than this to develop. While this development it going on we need to keep the development code separate from the main trunk, from which the releases are taken. This is easily done by creating a new branch and doing the development on that. Once the feature development is complete we merge it into the main trunk. This can be quite difficult when you have two development paths with maybe 12 months of separate development on each. Trying to merge them together in one big-bang was not acceptable. In order to avoid this problem we used a method called re-basing. (I've never used ClearCase, but I was under the impression it supported this.) At certain points during the development, the branch was re-based with the trunk. To do this, the latest code on the trunk was merged into the development branch. This way the merging could be done in small, manageable chunks. When the final merge from the development branch to the trunk was done, the only merge required was the changes since the last rebase merge. This technique proved very successful and CVS was able to track all of the merges using it's mergepoints. The only issues we ever had were with binary files. Since we have very few of these and they rarely change, they could be treated as a special case. Since this proved to be a very simple and easy process, we took it one step further. Before the development branch was merged into the trunk, a final re-base we performed. This way all the regression testing we needed to do can be done on the development branch before the code went anywhere near the trunk. This then means that the final merge into the trunk is a trivial affair. Once we got this process in place for all the long term development, we started doing it for all development branches. Again, this was very successful and we saw a marked improvement in the stability of our trunk code, as all conflict resolution and regression testing was able to be done on the development branch. I hope that explains exactly what we're trying to achieve. Please let me know if there's anything else I can explain. Please can you explain to be exactly how this (or another scenario) might result in lost data? Our own experiences would indicate that our process would not be affected by this problem and so would be better to use an older version rather than the current one. However if you can explain it a bit more for me then I should be able to verify one way or the other. Many thanks, Andy -- Andy Harrison - Platform Software Engineer Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ, UK "No matter how bad things seem... ...nothing could be worse than being used as a towel rail." - A.A. Milne -----Original Message----- From: Arthur Barrett [mailto:arthur.barrett at march-hare.com] Sent: 10 January 2007 12:52 To: Harrison, Andy; Tony Eva; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: RE: [cvsnt] Mergepoint issues on 2.5.0.3 b2382 Andy, As explained by Tony Hoyle - you do not want the versions where this was enabled because you can lose data. I strongly suggest stepping away from the problem and perhaps you and Tony Eva can explain what BUSINESS FUNCTION you are trying to achieve a CVS solution for. Many people on the newsgroup can then help explain how to automate that business function with CVSNT. I've used ClearCase a fair amount and I've never seen this functionality used - it is quite possible CC has the same "limitation" - but perhaps not - I certainly do not think this is a part of UCM. Regards, Arthur A member of the Anite Group of companies. Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email. Anite Group plc Registered in England No.1798114 Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187 Scanned for viruses by BlackSpider MailControl.