On Sep 25, 2008, at 11:03 AM, Kevin Thorley wrote: > > On Thu, 2008-09-25 at 10:54 -0400, Marden Marshall wrote: >> On Sep 25, 2008, at 10:34 AM, Kevin Thorley wrote: >> >>> >>> On Thu, 2008-09-25 at 10:13 -0400, Ken Mahoney wrote: >>>> Good morning, >>>> >>>> There are a few binary objects that must be present under ~/libsrc >>>> before SipX can be fully built. Among these are the java-sun- >>>> windows >>>> JVM and Sun's JDK package. I believe these types of files should be >>>> checked into the sipXecs repository. I was considering whether >>>> these >>>> should be saved into the ~/src/lib/ directories and then have the >>>> lib >>>> make infrastructure copy them over to ~/libsrc when a build >>>> begins. I >>>> realize that traditionally ~/src/lib was preserved for packages >>>> that >>>> affect SipX run-time only, but maybe it should be expanded to >>>> include >>>> special packages like these? Or perhaps, a ~/src/buildpkgs >>>> directory >>>> (or something similarly named) should be created for these types of >>>> objects? >>>> >>> >>> I personally don't like stuff like this checked into source control. >> >> Maybe we should stop keeping anything in source control and go back >> to >> the good old days when we carried stuff around on floppies. I've got >> a box of 8 inch floppies that I've been dying to put to use. > > I've got a box of floppies I can donate to the cause. >> >> Seriously, one of the reason that we keep things under source control >> is so that we can always go back and reconstruct a software >> deliverable at any given time. We have already seen on several >> occasions where the "source" for a particular libsrc component was no >> longer available. Fortunately we got lucky and were able to recover, >> either by upgrading or by searching for a copy from some other >> external location. But relying on luck to maintain integrity of our >> build process is a fools game. If the contents of the libsrc >> directory are critical to building and deploying our product, they >> should be treated like any other critical piece of our software and >> kept under source control. >> > > Seriously now, I am hardly suggesting that we abandon source control. > Nor am I suggesting that we give up repeatable builds. Tools such as > Maven and Ivy have come about due to the fact that people realize that > source control is for sources and lib repositories are for libs. The > sources contain information about what version of a given lib to use. > The lib repositories are backed up along with source control. They > also > keep copies of each version of a particular lib so that you can go > back > to a previous source and build against the correct libs. They are > just > as important to repeatable builds as source control, but they keep > dependencies out of source control. All I'm suggesting is using the > right (IMO) tool for the job.
I have said before that I think that something like Ivy would be a great way to manage our third party dependencies. The problem is that this is not a tool that we have at our disposal today. What we do have available today is subversion. As for addressing the problem today, I fail to see any down side to maintaining these critical packages under subversion. -Mardy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
