[cvsnt] NOT [SPAM]

Fri Nov 7 16:02:54 GMT 2003

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
> *************************************