on reputation and lines and putting things places (Re: gcc branches?)

Bruce Stephens bruce@cenderis.demon.co.uk
Sun Dec 8 14:45:00 GMT 2002


Stan Shebs <shebs@apple.com> writes:

[...]

> Now, almost all of *my* merge difficulties have been because Apple
> changes to GCC are logically contradictory to FSF code.  Does arch
> include an intelligent merging component that is smart about C and
> can figure out which pieces of FSF code need to be overridden by
> Apple code, even if the FSF code changed?

No, but (like other modern CM systems) it remembers what's been
merged.  So with CVS, you develop on a branch (presumably updating
with whats on the head), and when you want to update the head, CVS
does textual guessing to decide which apparent conflicts are real ones
(and this usually works pretty well, to be fair).  

Arch remembers the updates you've done on your branch, so when you
want to update the head, you'll get fewer spurious conflicts.  

So with arch, it makes sense to keep branches up to date with respect
to each other---it makes future merges easier.  With CVS, it's
sometimes the opposite.

(Arch knows about file renames and things, too, which would matter for
some projects, but possibly not gcc.)

> If not, then for *me* it doesn't have any advantage over CVS, and
> there's no point in trying to sell it to me.

Maybe not.  It's hard to say without looking in more detail and trying
experiments.

[...]



More information about the Gcc mailing list