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.
Thanks Glen & Tony. We had planned to have users check-out in VSS when they start playing with a file, and when committing using WinCVS I was hoping I could get CVSNT to perform a VSS check-in, so as to try to main the integrity of both VSS & CVS. We were intending to run with one "main" CVS branch and everyone just work off that. If a conflict was to arise then it was going to be to the two developers concerned to sort it out. Kind regards Richard Moore -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Glen Starrett Sent: Sunday, 1 February 2004 04:21 To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: Re: [cvsnt] Trialing CVSNT and have some questions Tony Hoyle wrote: > Richard Moore wrote: > >> 1. When committing a change they would like to see what "merging" is >> about >> to take place. > > > Merging doesn't take place during a commit, but during update, so > there's nothing to see. > Just to expand a little on Tony's comments: One model (largely regarded as the best model) for handling multiple developers editing the same code base is to use branches. Read about that in the wiki and the sources online, but in a nutshell: --The developer branches from the main trunk --Developer works on function X --When complete, developer merges changes for function X into the main branch again. At each step the code can be committed and therefore is preserved independently of the other work going on in the project. The branch serves to isolate one developer's changes from the others. While you can merge at any time, you aren't forced to. When you do decide to merge the changes (in any direction), the typical procedure is: --Commit your sandbox --Merge changes from the other branch | main in --Verify the changes (that's your "how do we see what has changed" question). Use "cvs diff" or TortoiseCVS has a nice diffing function when used with WinMerge, for example. I am in the habit of inspecting ALL merged changes, but it's proving unnecessary and I'm getting much faster at scanning a large amount of changes. --Commit the merged code. Note that none of the files were affected at the moment of the merge. It was only after you had the chance to review those changes and then purposefully committed them did it update the repository. Used this way, CVS is _very_ safe. There's another, less safe way without branches. Just try to commit. If someone else changed the same file in the same line of development, then you'll get a warning from CVS. You can see the differences if you do a CVS DIFF -r HEAD. You will need to Update at that time which will merge in the changes from MAIN into your code. The downside to this is that if you want to roll back, you haven't previously committed your original changes and that file has been altered by the work of the other developer. Our group used to use (some still do) VSS. CVSNT is worlds better for team development. Regards, -------------------- Glen Starrett _______________________________________________ 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