[GRASS5] Jan's copyright notice ++

Andreas Lange Andreas.Lange at Rhein-Main.de
Sun Nov 12 10:53:02 EST 2000


Hi Justin, Hi Markus, Hi all,

i read in my copy of Karl Fogels on-line book on CVS that every keyword
expansion may cause spurious conflicts on merging back from a
development branch into the main trunk. So even the $Id Keyword will
cause conflicts that must be resolved manually. 

On the other hand i haven't really understood how the future CVS
developement is intended to go. Markus created a new CVS-Repository for
the new GRASS 5.1 tree, where the development of the new version should
be done. IMHO the existing source of GRASS5.0stable must be checked in
manually in the new repository in a new directory structure, so that an
CVS-guided merge back from GRASS 5.1 to GRASS5.0 stable is not possible. 

If we go this way, i believe that the Log messages will be very useful
to review the development in the previous version without the need to
look into the cvs log of the other repository. 

But if we decide to create a branch inside the existing repository for
the new development tree (what was the result of the previous
discussion? Can't remember), the log entries will cause much trouble.

I personally tend to the first system (checking in the exsisting code
into a new, completley reorganized repository), mainly because i am not
familiar with the CVS branching/merging operations (and i fear that the
reorganization of the directories will be too complicated to be done
with a cvs branch). The reorganization should be used to review every
module/part. If we have a stable GRASS version, the new deveopment trunk
needn't be useful/stable while working on it. 

So that's my opinion, i think we should use the $Log keyword.
Please tell me if i am wrong on my assumptions on the further
development!

cu,

Andreas

Justin Hickey wrote:
> 
> Justin Hickey wrote:
> Heh! Now I do have a concern with the log messages being used in the
> header. While looking into the use of the $Log$ keyword in the document
> "Version Management with CVS" by Per Cederqvist et al, I came across the
> following warning in section 12.5 "Problems with the $Log$ keyword"
> 
> =================== Begin Text =======================================
> 
> The $Log$ keyword is somewhat controversial. As long as you are working
> on your development system the information is easily accessible even if
> you do not use the $Log$ keyword -- just do a cvs log. Once you export
> the file the history information might be useless anyhow.
> 
> A more serious concern is that CVS is not good at handling $Log$ entries
> when a branch is merged onto the main trunk. Conflicts often result from
> the merging operation.
> 
> People also tend to "fix" the log entries in the file (correcting
> spelling mistakes and maybe even factual errors). If that is done the
> information from cvs log will not be consistent with the information
> inside the file. This may or may not be a problem in real life.
> 
> It has been suggested that the $Log$ keyword should be inserted last in
> the file, and not in the files header, if it is to be used at all. That
> way the long list of change messages will not interfere with everyday
> source file browsing.
> 
> =================== End Text =======================================
> 
> What concerns me is the second paragraph concerning the conflicts that
> can result from a merge operation. Since we are about to create a new
> branch that will eventually be merged back in, then I think we need to
> take this problem into consideration.
> 
> Without any experience with this problem, I would recommend that we do
> not use the $Log$ keyword to avoid what could be major headaches in the
> future given the size of Grass. Am I being paranoid? What do people
> think?


-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list