[cvsnt] RE: NOT [SPAM] - ignore this!

Fri Nov 7 20:37:43 GMT 2003

My apologies to everyone on the list 

- this message was not supposed to go to the mailing list.

Sorry,
Hugh

> -----Original Message-----
> From:	Hugh Bawtree 
> Sent:	Friday, November 07, 2003 8:03 AM
> To:	'cvsnt at cvsnt.org'
> Subject:	NOT [SPAM]
> 
> Ian,
> 
> The following email is NOT spam.
> 
> Thanks,
> Hugh
> 
> 	-----Original Message-----
> 	From:	cvsnt-request at cvsnt.org [SMTP:cvsnt-request at cvsnt.org]
> 	Sent:	Friday, November 07, 2003 4:00 AM
> 	To:	cvsnt at cvsnt.org
> 	Subject:	[SPAM] - cvsnt Digest, Vol 11, Issue 12 - Email found in subject
> 
> 	Send cvsnt mailing list submissions to
> 		cvsnt at cvsnt.org
> 
> 	To subscribe or unsubscribe via the World Wide Web, visit
> 		http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> 	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 branch with identical versions still changes
> 	       (John Peacock)
> 	   2. Enforcing read-only checkouts from the server? (Oliver Giesen)
> 
> 
> 	----------------------------------------------------------------------
> 
> 	Date: Fri, 07 Nov 2003 05:32:02 -0500
> 	From: John Peacock <jpeacock at rowman.com>
> 	To: Glen Starrett <grstarrett at cox.net>
> 	Cc: cvsnt at cvsnt.org
> 	Subject: Re: [cvsnt] Merging branch with identical versions still changes
> 	Message-ID: <3FAB74A2.2030405 at rowman.com>
> 	In-Reply-To: <001401c3a4c0$5e6e2a20$1401a8c0 at GLEN>
> 	References: <001401c3a4c0$5e6e2a20$1401a8c0 at GLEN>
> 	Content-Type: text/plain; charset=us-ascii; format=flowed
> 	MIME-Version: 1.0
> 	Content-Transfer-Encoding: 7bit
> 	Precedence: list
> 	Message: 1
> 
> 	Glen Starrett wrote:
> 	> But the easiest way to get a non-trivial merge to merge in cleanly is to do
> 	> as I've outlined, I think.  Do you now of a better way?  I would think that
> 	> with the method you're proposing the dev would be manually merging code
> 	> changes into the dev branch instead of CVS automatically merging most of the
> 	> updates + a little manual conflict resolution, which seems like a lot more
> 	> trouble.
> 
> 	I'm still not making myself clear then.  CVS's conflict merging is used in my 
> 	proposal, just as it is in yours.  The only manual processing is the [possibly 
> 	inevitable] manual conflict resolution, which you'd have to do anyway.  In fact, 
> 	with your merge trunk -> branch and branch -> trunk, there is the possibility of 
> 	two manual conflicts (unless the trunk is frozen during this process).
> 
> 	Rather than abstract someone else's work, I urge you to study this section:
> 
> 	http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_With_Branches_And_Survive_
> 
> 	of the very well written "Open Source Development with CVS" by Karl Vogel (now a 
> 	core Subversion developer) and Moshe Bar.  I personally prefer the "Flying Fish" 
> 	model which they discuss in some detail, whereas you are using a modified 
> 	"Dovetail" approach.  It depends completely on how independent your development 
> 	is and how many people are working on each branch (I have a small shop).
> 
> 	NOTE: with CVSNT's mergepoint handling, all of the discussion about merging 
> 	repeatedly with the trunk is moot.  You pretty much can merge in either 
> 	direction without worrying about trying to merge already applied changes.
> 
> 	As long as your developers are frequently doing a 'cvs update -j HEAD' on their 
> 	branch, and cleaning up any conflicts, then it is very unlikely that any 
> 	conflicts (either textual or semantic) will occur when their branch is merged 
> 	back to the trunk.  It just seems to me like you are waiting to do that until 
> 	the last moment (when you are ready to merge the branch).
> 
> 	There is more than one to do this process.  I guess I am saying your process is > 
> 	OK, but you are not doing it often enough.  You shouldn't wait until you are 
> 	ready to merge the branch into the trunk to find out whether the trunk changes 
> 	are going to break your code.
> 
> 	HTH
> 
> 	John
> 
> 	-- 
> 	John Peacock
> 	Director of Information Research and Technology
> 	Rowman & Littlefield Publishing Group
> 	4720 Boston Way
> 	Lanham, MD 20706
> 	301-459-3366 x.5010
> 	fax 301-429-5747
> 
> 	------------------------------
> 
> 	Date: Fri, 7 Nov 2003 11:25:04 +0000 (UTC)
> 	From: "Oliver Giesen" <ogware at gmx.net>
> 	To: cvsnt at cvsnt.org
> 	Subject: [cvsnt] Enforcing read-only checkouts from the server?
> 	Message-ID: <bofveg$f2m$1 at sisko.local.nodomain.org>
> 	Content-Type: text/plain; charset=iso-8859-1
> 	MIME-Version: 1.0
> 	Precedence: list
> 	Message: 2
> 
> 	In a discussion with a (potential) CVSNT user, we stumbled over a
> 	problem which I found quite surprising as it was contrary to what I
> 	thought I remembered from some posts on this list.
> 
> 	The user wants to enforce the use of edit/unedit by enforcing read-only
> 	checkouts. Without thinking I recommended to put cvs -r into the
> 	server's cvsrc file. It turns out that global options in CVSROOT/cvsrc
> 	are ineffective (which is already nicely documented in the CVSNT
> 	Cederqvist - I just didn't notice until now).
> 
> 	Now, ACAICT cvs watch on will only work on existing modules and will
> 	not affect future additions - and is therefore rather useless to
> 	enforce a kind of global policy from the start. So, what's left?
> 
> 	Am I missing anything? Could it be true that something like this is
> 	currently not possibe at all?
> 
> 	P.S.: Before this discussion starts anew: I am perfectly aware that all
> 	this is not really in the spirit of CVS. I'm not using it myself
> 	either. This is not the point of the question. I just think everyone
> 	should be able to make his/her own experiences...
> 
> 	Cheers,
> 
> 	-- 
> 	Oliver
> 	----  ------------------
> 	JID:  ogiesen at jabber.org
> 	ICQ:  18777742     (http://wwp.icq.com/18777742)
> 	------------------------------
> 
> 	_______________________________________________
> 	cvsnt mailing list
> 	cvsnt at cvsnt.org
> 	http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> 
> 
> 	End of cvsnt Digest, Vol 11, Issue 12
> 	*************************************