[cvsnt] Trialing CVSNT and have some questions

[Glen Starrett]

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