DragonFly BSD
DragonFly users List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: src/contrib/ policy


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Sep 2006 21:17:33 -0700 (PDT)

:How likely is it that we would need to take the major step of backing out
:a new version?  Since we're adding third-party software, it's known to
:work (though on other platforms) at that point, and if it's broken,
:there's usually a patch that follows from the vendor.
:
:The reason I ask is that our CVS repository is getting pretty large.
:
:leaf:/home/justin> du -sh /cvs
:765M    /cvs
:
:Is that an accurate measure?

    782MB for the whole repository, 354MB of which is contrib.  But most
    of contrib is made up of one-offs.  We have multiple versions of
    sendmail, a few of gcc, a few cvs, and that's pretty much it insofar
    as the duplicates go.  GCC is a gimme... we have no choice but to
    import major revs separately because we just can't afford to blow up
    the core compiler.  The others only amount to ~40MB or so.  So as yet
    I do not see the duplication as creating a problem.

    If worse comes to worse we can always scrap the oldest copies, at the
    cost of not being able to checkout an exact representation of very old
    releases.  I don't consider it a problem to do that since there are
    plenty of other things, like the compiler updates, that already make
    it impossible to compile the oldest versions of the system.  The only
    CVS history that's *truely* important is for /usr/src.

    What I don't want to do is put a burden on developers for the sake of
    saving a little space in the CVS repository.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



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