This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Notes from the version control BOF at the summit


    > From: fche@redhat.com (Frank Ch. Eigler)

    > With signed patches and an appropriate merging server, there is no
    > need for developers to have login access to a repository server at
    > all.  

Merging servers are a pretty interesting idea for lots of reasons.

For GCC hackers working with branches, one idea is to use a merge
server to do "nightly merges" much as people often do "nightly
builds".  

Suppose you have two long-lived branches: a new instruction scheduler,
inx, and a new register allocator, reg.  These will be a longish time
in development but both are important.  A merge server can tell you,
conveniently, months in advance, exactly how inx and reg are going to
conflict.  You might get a nightly email with a count of conflicting
lines or perhaps there is a web site with links to the conflicts.  If
one day your cron job email says, instead of "about 100 lines of
conflicts", "hey, there's about 10000 lines of conflcits", you can
immediately look at what got checked in yesterday, analyze the source
of the conflicts, and adjust coding plans accordingly.  You retain the
benefits of branches, but you have a planning tool for working around
one of their limitations.

Another use for merge servers is support a higher rate of commits than
is otherwise practical.  In the arch project, we use one as the
transactional database for our bug system.  All open and recently
closed bug reports live, as ordinary files, in an archived tree.  You
can work with the issues database via email or web -- but also just by
checking it out.

We have a role in the project for a "bug czar" whose job is to
sanitize and vet the stream of incoming new bug reports.  He works by
checking out the database, editting it normally (with a text editor,
etc.), committing to a branch, and.... drumroll....

Sending mail to a merge server which then merges from his branch,
burping back at him should the database have changed in conflicting
ways in the meanwhile.  Among other advantages, this spares him from
having to race with incoming bugs in order to have his tree fully
uptodate when he commits his work.

-t


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]