Re: [forum] A strawman proposal for X.org & XFree86.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stuart Anderson <anderson@netsweng.com> wrote:

> > Upon the release of X11R6.7, XFree86 shall integrate the X11R6.7 code
> > into their code management system as the base of the "X.org Standards
> > Sample Implementation" (SSI) branch.
> 
> Sheesh. We went over this what, 3 years ago?
> 
> We are currently trying to _reduce_ the number of branches of the
> X tree, and prevent the creation of a new one. Having a seperate
> branch doesn't contribute to this at all. 

I am not familiar enough with CVS to know whether this would make merges 
easier or not, but I am very familiar with Perforce (what we use). With 
Perforce I regularly maintain an entire //depot/cvs/ tree in our server, 
that contains verbatim source code from external projects such as 
XFree86, wxWindows, Mesa and other projects that we track. Some of it 
comes from CVS, and some comes from tarballs. We reguarly import external 
code updates into that tree, tag them and submit them into the branch.

The key thing with doing things this way, is that it then allows us to 
'branch' our real development code from the verbatim //depot/cvs/ tree 
development code. This means we do all our core development in a separate 
tree, yet we are able to apply patches and updates to the //depot/cvs/ 
tree from external sources without affecting our development code. Then 
when we are ready to accept the latest code from //depot/cvs/ into our 
development tree, we can do a Perforce 'integrate' operation which will 
do a merge into our tree. For the most part Perforce can automatically 
merge nearly all updates into the tree, except cases where two people 
have modified the same set of code. Even when changes to the same source 
module have occurred, Perforce generally does the automatic merge 
properly and gets it right. If it needs manual fixing, it is very easy to 
find the code that needs manual fixing and fix it before submitting the 
code into the development tree as final.

Due to the fact that we have set this system up, we have been able to 
utilise existing projects maintained with a different version control 
system without our own development trees. We can also merge code back 
into the //depot/cvs/ tree for cases where we are contributing to a CVS 
project and the submit that code back into the CVS tree (we did that 
regularly for the wxWindows code we were working on last year). For 
projects where we do not have CVS access, we can generate patches to send 
to the appropriate parties.

Anyway the point I am trying to make is that keeping a complete, local 
copy of the SSI source code in the XFree86 CVS tree may make a lot of 
sense from the perspective of simplifying the process of merging code 
between the SSI tree and the XFree86 tree. Especially if the X.org 
members are willing to actively maintain and test the SSI tree in the 
XFree86 CVS system.

Of course all this assumes that it makes real sense to have a separate 
SSI and XFree86 tree (I don't understand the issues enough to comment 
here).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



[Index of Archives]     [X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite Questions]     [MIPS Linux]     [ARM Linux]     [ARM Linux Kernel]     [Samba]     [Linux RAID]

  Powered by Linux