FW: [cvsnt] Trialing CVSNT and have some questions

[Richard Moore]

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
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
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt