[Xorg] next steps with the xorg tree

[Egbert Eich]

Kendall Bennett writes:
 > "Kaleb S. KEITHLEY" <kaleb at shiman.com> wrote:
 > 
 > > Kendall Bennett noted that {RCS,CVS}ID strings in the sources make
 > > it hard to import/merge changes into other people's trees. I
 > > certainly agree -- after 10+ years working with X Consortium,
 > > XFree86, and now Xorg trees doing imports and merges -- that it
 > > does indeed make for more work. 
 > > 
 > > So you have to tell me whether it's valuable or not to be able to
 > > look at a file, possibly from somewhere else, and be able to tell
 > > at a glance what its provenance is. 
 > 
 > As I mentioned before, that is the realm of good source control systems. 
 > I don't use CVS extensively so I don't know it works for CVS, but with 
 > Perforce I can just do a 'p4 filelog' on any file and it will give me all 
 > the history of that file, the change log comments and changelist numbers. 
 > With the changelist numbers I can find out what other files were checked 
 > in at the same time for that change as well.

I don't think that was what was ment here. What was ment was if it is
worthwhile mirroring every commit by XFree86 including the log entries 
to each file.

What you suggest can easily be done with 

cvs log <filename>

 > 
 > You can also do a 'p4 annotate' to get an annotated version of the file 
 > that contains information about exactly which *line* of code was changed, 
 > how it was changed and what change # the line of code was changed in.

cvs annotate <filename> 

does the same thing. You can also do this for a previous version.

 > 
 > With those kinds of features around RCS ID strings are a total waste of 
 > bandwidth (IMHO).

Sometimes it's useful to have the versions of the files
in the sources from a tarball.
Some people put them into a string constant. Then you
can search the binary for the versions of the sourcefiles 
that went into it.

 > 
 > If CVS doesn't have these abilities, maybe we should consider using a 
 > better tool for the job, like Perforce ;-)
 > 

Well, it does.

Egbert.