info-cvs
[Top][All Lists]
Advanced

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

Re: importing vendor branches


From: Laine Stump
Subject: Re: importing vendor branches
Date: 04 May 2001 18:28:36 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

address@hidden (Larry Jones) writes:

> Greg A. Woods writes:
> > 
> > I still don't see the problem here.  If everyone who might do a checkout
> > reads at least the subject lines of the mail from loginfo they'll know
> > when an import was done, and in what module, and be able to avoid doing
> > a fresh checkout that might result in an inconsistent working directory.
> 
> Note that it's not just a fresh checkout; a plain update has the same
> problem.

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 (sure, it should be
designed so that actual conflicts in the imported files takes much
less time than that, but let's suppose that the new import changes
some functionality, and that requires a rewrite of portions of locally
developed code in order to work correctly; anyway, even a *day* is a
long time, especially in a project with a lot of people, where
tomorrow someone else might do yet another import of something
different which again renders the repository "temporarily unusable").

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. Doing
otherwise restricts the productivity of the other developers (it's
really just an unenforced read lock on the entire repository) and is
extremely impolite (with the level of impoliteness increasing as a
square of the number of developers using the same repository and a
cube of the number of hours the repository is in an inconsistent
state).

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
;-) (On the other hand, I'm unlucky that the repository used by lots
of people is still under VSS, which doesn't even have a *bad* vendor
branch concept, much less a good one (and also doesn't allow
scheduling adds and deletes to happen simultaneous with a commit).




reply via email to

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