[Xorg] RELEASE-1 merged into CURRENT

[Egbert Eich]

Keith Packard writes:
 > > 1. I had the usual spurious conflicts from cvs IDs. Keeping XdotOrg:
 > >    and XFree86: IDs in close vicinity is like calling for trouble.
 > 
 > We might want to change the XFree86 lines from actual CVS tags to 
 > something that CVS won't parse but which still retains the XFree86 version 
 > information:
 > 
 > /* $XFree86: xc/programs/Xserver/dix/main.c,v 3.43 2003/10/30 21:21:02 herrb Exp $ */
 > 
 > would become:
 > 
 > /* Derived from XFree86: xc/programs/Xserver/dix/main.c,v 3.43 2003/10/30 21:21:02 herrb Exp $ */

If we decide not to merge in any XFree86 stuff - and I've turned off
the update of the vendor branch - this issue will be moot in the future.

 > 
 > Getting back to the original CVS tag would be trivial if necessary and we 
 > would avoid CVS accidentally rewriting the tag and losing this information.

CVS won't rewrite those tags as it doesn't know about it.
The vendor tag needs to be specified in a config file.
It only works with the newer (beta) version of CVS when
using CVS out of the box.
The stable version of CVS doesn't support this feature, yet.
You'd have to use a patched version - like the one FreeBSD
is shipping.

 > 
 > > 3. I've used the new ChangeLog file format Keith has been proposing.
 > >    (I've removed the long list of files, instead I've added the 
 > >    ChangeLog from the RELEASE-1 branch (indented by 1).
 > >    If you agree on this format we need to document how to create
 > >    changelog files and I will convert the previous changelog entries
 > >    to the new format (once I've figured out how to do this without
 > >    too much hassle).
 > 
 > There is a perl script (prepare-ChangeLog.pl) available in /home/local/bin
 > which will walk the tree and generate a template in ChangeLog that 
 > includes the files and functions modified, along with the appropriate 
 > header line.
 > 
 > However, this tool traverses the entire repository, making it unsuitable 
 > for use in the monolithic tree as it just takes too long.  We might modify 
 > this script to take an optional list of sub-hierarchies to examine for 
 > changes.

That's not so bad. It actually is pretty fast.
I have noticed some things though:
1. It complains about unbalanced parentheses in some C files because they
   are written uncleanly and have #if statements across group boundaries
   :-((
2. It modifies every ChangeLog file it finds in the tree. That's probably
   not what we want. Especially not for those in extras/
   As it will only thouch these if anything in the tree below the directory
   they are in happens this won't occur very often.
3. I cases like this merge the list of files that were changed is rather
   long and not suitable. 
4. I would propose that every branch starts a new ChangeLog which then
   gets merged when the branch gets merged. This may require some manual
   intervention but it may be possible to script it, too.
   I don't know if we should keep the dates in chronological order or
   if it is better to mark by indentation the entries that refer to a 
   merged branch. That's what I currently did.

 > 
 > The main benefit of this alternate format is that changes are tagged by 
 > date instead of a number.  This makes it possible to prepare changes on 
 > branches and merge them into the release without needing to hand-merge the 
 > change log entries and resequence them.

I wonder if we really want that. Using these dates on branches that we
have merged things into is rather meaningless.

 > 
 > > 4. I will investigate how to merge the CURRENT branch into HEAD
 > >    without causing too much headache for others.
 > 
 > I don't think this will cause much trouble; no-one is using HEAD at the 
 > moment.  Merge at will!
 > 

Right. But a lot of people have branched from XORG-CURRENT.
It shouldn't really matter if people have created a base tag
so a merge like

cvs update -j FOO-BASE -j FOO 
to head should go right thru. However people who have forgotten
the base tag and rely on
cvs update -j FOO
will be screwed. Well, I've just checked: there doesn't seem to be
a project on XORG-CURRENT doing this (I don't quite understand the 
tags CYGWIN is using.)

However some people may still have uncommitted stuff for XORG-CURRENT.
Therefore we should set a date until when the commit has to be done.

	  Friday, April, 23rd

should be a good date. I'll probably do another one of those nasty
cross posts to announce that. As people may not read until here.

Egbert.