info-cvs
[Top][All Lists]
Advanced

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

Re: importing vendor branches


From: Greg A. Woods
Subject: Re: importing vendor branches
Date: Fri, 11 May 2001 11:58:10 -0400 (EDT)

[ On , May 4, 2001 at 18:28:36 (-0400), Laine Stump wrote: ]
> Subject: Re: importing vendor branches
>
> Right. And not all merges are simple 10 minute deals, and not all
> repositories are used by less than 10 people. Imagine some significant
> portion of 100 engineers breathing down your neck because they can't
> do any commits, updates, or checkouts during the week that it takes
> you to resolve merge conflicts due to a new import

Hmmm...  well, no, I can't quite imagine that...  I suppose it was
somewhat similar to the scenario in which Berliner was working when
CVS-II was first implemented, though they had broken the top-level
module down into many tiny sub-modules which the developers actually
worked on and I'll bet there were rarely inconsistencies in many of the
tiny modules even after importing a major new SunOS release....

However in general that many engineers working on that large a single
module doesn't sound very smart in the first place!  :-)

(i.e. not all large repositories are made up of one module!  ;-)

> If you're really concerned about the concept of "concurrent
> development", then you should make all changes dealing with a specific
> piece of new functionality, whether these changes are from the vendor
> or done locally, show up on the trunk at the same time.

I would agree.  And I think some tools other than CVS do that better!  :-)

BitKeeper, and maybe Aegis and Perforce, for sure, and maybe even PRCS.

In general though unless your versioning system has some fundamental
support for the concept of change sets, or supports two-phase commits,
(CVS has neither) it's almost impossible to eat your cake and have it
too when you're working with very large modules.  There's simply going
to be a delay, that grows with the size of the module and the number of
conflicts, between an import of a new third-party release and the time
when the module is available again for ongoing development.  Even with
change sets or two-phase commits the time to do the merge is still there
-- it's just that the mechanisms provide ways to temporally adjust the
times when the conflicts or inconsistencies appear so that they seem to
not be there at all.

> Me? I'm lucky - the only CVS repositories that I commit to these days
> have at most 3 people working on them, so I can afford to be impolite
> ;-)

These days I'm even luckier than that, even though I also have whole
operating systems in one large module; though I can't afford to be
impolite to the developer at all, because that's me!  ;-)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]