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 Bo, I understand the revisioning. But sometimes you have made changes and checked in. Now you want to revert the changes you have made and work with older version. In that case how we need to proceed further? Thanks, Neeraja -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of cvsnt-request at cvsnt.org Sent: Tuesday, May 27, 2008 4:30 PM To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: cvsnt Digest, Vol 65, Issue 34 Send cvsnt mailing list submissions to cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook To subscribe or unsubscribe via the World Wide Web, visit http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs or, via email, send a message with subject or body 'help' to cvsnt-request at cvsnt.org You can reach the person managing the list at cvsnt-owner at cvsnt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cvsnt digest..." Today's Topics: 1. Re: Merging problems, getting strange conflicts.... (Bo Berglund) 2. Re: Checking in Older versions (Bo Berglund) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 May 2008 12:39:48 +0200 From: "Bo Berglund" <Bo.Berglund at system3r.se> Subject: Re: [cvsnt] Merging problems, getting strange conflicts.... To: <cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook> Message-ID: <C66EBC6C8B31CC488641B94D31FD86589A8D1C at 3REXCHANGE02.system3r.com> Content-Type: text/plain; charset="us-ascii" Concerning 2-way merges I am not talking about such. Mu merges are 1-way only, first from Trunk to Branch and then later another 1-way from Branch to Trunk. The sequence is: - Branch off trunk at say rev 1.8 - Make changes on branch to arrive at 1.8.2.9 - Also change trunk to get 1.11 - Now merge HEAD into branch and resolve conflicts (1-way) - Commit to get 1.8.2.10 - Now there is a mergepoint set on 1.8.2.10 pointing back to 1.11 - Next try the merge from branch to head (also 1-way) and get the conflicts I always thought that the mergepoints recorded pairs of revisions that were already merged such that the receiving end had all the changes from the branchpoint included. In my case above after the first merge the branch would contain all of the head changes in addition to the branch changes and this is noted by the mergepoint. Now, in the second (1-way) merge CVSNT should have noted that 1.8.2.10 (tip of branch) already contained all of the head changes from the original branch point to the HEAD revision 1.11 since the mergepoints would tell it so. Consequently there is no need to get any data from HEAD, just copy over the contents of branch in the merge process. But what happens is that it announces conflicts where there are same location changes even though the valid such conflicts were already solved in the first merge/commit. So why are the mergepoints not used? (Sorry about the top-posting, I am doing this from work where newsreaders do not work and Outlook is not able to format my reply properly...) Best regards, Bo Berglund -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Arthur Barrett Sent: den 27 maj 2008 02:02 To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: Re: [cvsnt] Merging problems, getting strange conflicts.... Bo, > Now my TCPIP branch is working fine and I need to move it to TRUNK. In > preparation for this I merged HEAD into the branch and solved the > conflicts (because HEAD had changed a lot less than Branch over the > months). I thought that by doing this the final merge from branch to > trunk would be almost automatic. There was a really long thread on this ages ago. I think Gerhard was involved in a lot of it and may even have written something up afterwards in the wiki. The short summary is that CVSNT cannot do bidirectional merging. I think after that discussion Tony may have made some changes to the merge code to support a single suggestion that was made - if I'm remembering correctly then that'll be in 2.5.04 only and I think your production system is 2.5.03 - but I'm not sure it'd cover this case. The recommended approach is to merge branch to trunk with no merge from trunk to branch (you did this as a 'prep' step which is simply unnecessary since the trunk is not locked or changed until you actually commit the merge. Alternativly there is the 'copy branch to trunk' or 'make trunk equivalent to branch' method. Regards, Arthur _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs ------------------------------ Message: 2 Date: Tue, 27 May 2008 12:46:55 +0200 From: "Bo Berglund" <Bo.Berglund at system3r.se> Subject: Re: [cvsnt] Checking in Older versions To: "Sanjeev, Neeraja (GE Infra, Energy)" <neeraja.sanjeev at ge.com>, <cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook> Message-ID: <C66EBC6C8B31CC488641B94D31FD86589A8D1F at 3REXCHANGE02.system3r.com> Content-Type: text/plain; charset="us-ascii" I think you do not fully understand the way CVS works. A file under version control is managed on the server by adding new revisions for each committed change you make to the file. Such a new revision can only be based on the *latest* revision of that file either on the main line (TRUNK) or on a branch. If you have checked out a file and updated it to a past revision (one that is not the latest one on the server), say that you have revision 1.13, and then you want to edit it and commit the result, you will fail. The reason is that the successor of 1.13 is 1.14, so a commit of your edited file should create 1.14. But it can't because 1.14 already exists! The way to handle this is to create a branch off the code at some time in the past and then put the sandbox on that branch. In that case you would be able to commit the changes to 1.13 to arrive at 1.13.2.1, signifying that the file is located on a branch. Don't ever mess with the CVS subdirectory of your sandbox and its contents! As soon as you remove it the files stop being under version control on your PC (they are still on the server of course) and cannot be committed at all anymore! Best regards, Bo Berglund -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Sanjeev, Neeraja (GE Infra, Energy) Sent: den 27 maj 2008 10:36 To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: [cvsnt] Checking in Older versions Hi, I was trying to checkin the olderversion of the file. It failed. I think it might succeed if I do not get the cvs directory of the old version. Is there any way or CVS command available to checkin the older version of the file? Is there option available to update the directory by ignoring the CVS directory? Thanks, Neeraja _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs ------------------------------ _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs End of cvsnt Digest, Vol 65, Issue 34 *************************************