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: source mgt....[_HAS_ gcc relevance]



On Sat, 14 Dec 2002, Tom Lord wrote:
>
>        The advantage of the SCM-assisted merges is really that when
>        you trust the other side, it becomes a non-issue.
>
> It helps even when you don't implicitly trust the other side.

Sorry, you're right, and that's really what I mean.

To give write access to the tree you _really_ have to trust the other
guy. You have to trust him not only today, but you have to trust his
judgement in the long term. Which is why open source projects don't tend
to give write access to CVS trees very lightly, and as a result you tend
to have a fairly small "clique" of trusted developers.

In contrast, for a one-time merge you only have to trust "that merge".
Which is a different thing altogether, and doesn't require any kind of
"implicit trust".

> A remote, less-than-implicitly-trusted developer submits a patch.  You
> kick it back with comments.   Meanwhile, your mainline has gone on.
>
> Before resubmitting, that developer has to update his patch to reflect
> the new head-of-mainline.
>
> If that remote developer has his own repository, but a true,
> first-class branch of your mainline, then he can use SCM-assisted
> merges to keep his patch up-to-date.

Absolutely. And he can still use SCM-assisted merges with his cohorts to
fix whatever issues you brought up:  that's also an important part of
a distributed SCM.

Many people want to check stuff into the CVS tree _not_ because they
really want everybody to see the thing, but because they use the CVS tree
as a way to communicate with a few other people working on the same thing.
That's where the "single main repository" _really_ falls down. CVS tends
to use branches for this, but I do not know a single CVS user who isn't a
bit nervous about creating a new branch. That's true even when you don't
have the "write access" issue.

In contrast, with a good distributed system, if you want to just
communicate with some other people working on the same thing, you can
merge only the _affected_ trees, not the "main" tree. Merge into the main
tree only when you're done and the people involved are happy.

				Linus


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