On Mar 12, 2003 14:30 -0800, Larry McVoy wrote:
> On Wed, Mar 12, 2003 at 02:21:49PM -0800, David Lang wrote:
> > and if you did real-time updates but once a month or so redid the
> > 'longest-path' thing that would change the CVS version info, correct?
>
> Exactly. So if we redo it then anyone who has active CVS workspaces will
> get the wrong thing when they update if the revs have moved around and
> they will.
>
> I suspect the right answer is that we do the real time updates, see how it
> goes, if it starts to suck we'll periodically toss the CVS tree and start
> over.
What you could do is have a CVS "realtime" branch which is forked from the
trunk, say once a week, or whenever Linux makes a point release. On this
branch you do incremental updates as they are merged into CVS. When it is
time to create a new branch (say for 2.5.99-pre12), you re-do the export from
the branch base tag (at 2.5.99-pre11) to the current BK head in an "optimal"
way, and retag the "realtime" branch off of the new base tag.
We do this in our current CVS development, and CVS is smart enough to keep
local changes over the update and/or generate conflicts. That way, most
people can have a simple-but-good trunk to follow, but people who want
up-to-the-second updates can have it too, and you don't end up renumbering
the CVS revisions for times in the past. It also avoids the need to re-crunch
the entire BK repository to get an optimal path (which is only going to get
slower as time goes on, and I'm not sure whether Linux development is ahead
of or behind Moore's law).
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:33 EST