<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I'm not just shooting in the dark here. We actually faced a nearly identical problem with a configuration file that had to be locally modified for every installation. The svn/live idea worked like a charm.<div><br></div><div>rg</div><div><br><div><div>On Jul 24, 2008, at 10:57 AM, Chris Van Dusen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">svn:ignore might be something that could be used to accommodate this. <div><br></div><div>Putting just enough thought into it to be dangerous, the live-image could be ignored and the svn-image would be used as Ron stated. But, that's just me shooting in the dark. Maybe it'll give someone an idea.</div> <div><br></div><div>Chris.<br><br><div class="gmail_quote">On Thu, Jul 24, 2008 at 11:52 AM, Ron Garret <span dir="ltr"><<a href="mailto:ron@awun.net">ron@awun.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I suggest modifying the build procedure so that the binaries in SVN<br> are not used directly, but are copied (or symlinked) before they are<br> used. In other words, you'd have two files "svn-image" and "live-<br> image". When you bootstrap, you copy svn-image into live-image. When<br> you build, you create a new live-image. When you want to make a new<br> distribution (and only then) you copy live image back onto svn-image.<br> Only svn-image is actually checked in. I believe that would eliminate<br> this problem.<br> <font color="#888888"><br> rg<br> </font><div><div></div><div class="Wj3C7c"><br> On Jul 24, 2008, at 4:13 AM, Chris Van Dusen wrote:<br> <br> > And that was indeed the case. Thanks!<br> ><br> > Regarding reverting only those files that are in conflict, short of<br> > scripting it, I don't know of a way.<br> ><br> > Chris.<br> ><br> > On Jul 24, 2008, at 4:56 AM, Gary Byers wrote:<br> ><br> >> The "couple of days" that Matt mentioned in:<br> >><br> >> <<a href="http://clozure.com/pipermail/openmcl-devel/2008-July/008389.html" target="_blank">http://clozure.com/pipermail/openmcl-devel/2008-July/008389.html</a>><br> >><br> >> might have been a little optimistic (e.g., the trunk is still<br> >> pretty volatile as he merges several months' worth of IA-32 changes<br> >> into it.)<br> >><br> >> As of Wednesday afternoon, the trunk does build on Darwin/x8664<br> >> (with recent images; the most recent Darwin/x8664 image was checked<br> >> in as r10191 and identifies itself as "1.2-r10180M-trunk".)<br> >><br> >> The fact that SVN handles binary files reasonably well is a good<br> >> thing,<br> >> but one common case that comes up often involves binary files to<br> >> which<br> >> you've made local modifications (the lisp kernel and heap image<br> >> usually<br> >> fall into this category.) "svn update" downloads newer files and<br> >> stores<br> >> them in a parallel directory hierarchy (.svn directories), then<br> >> compares<br> >> them to the corresponding files in your working copy. If your local<br> >> copy wasn't modified since it was last checked out, it's overwritten<br> >> with the new copy. If a text file was modified, svn will try to<br> >> automatically reconcile the changes in your version with the new<br> >> version;<br> >> if it can, you get a working merged version and if it can't, it flags<br> >> the file as "conflicting" and adds some annotations that indicate<br> >> which<br> >> parts of the attempted merge came from which version.<br> >><br> >> If a binary file's in conflict ... well, a binary merge would be an<br> >> interesting research project. Since it can't really do any sort<br> >> of binary merge, svn leaves the locally modified copy alone and<br> >> notes that a conflict exists. (Even if you've never changed the<br> >> source, a lisp heap image that you make yourself may not be bit-for-<br> >> bit<br> >> identical to the same version from the server: some internal<br> >> pathnames<br> >> may be different, there may be timestamps somewhere, ...)<br> >><br> >> You can see those conflicts by doing:<br> >><br> >> shell> cd ccl # your working copy<br> >> shell> svn status<br> >><br> >> I'd guess that "svn status" sould show something like<br> >><br> >> C dx86cl64.image<br> >><br> >> and maybe<br> >><br> >> C dx86cl64<br> >><br> >> indicating that "svn update" didn't really know how to merge the<br> >> locally-modifed copy.<br> >><br> >> 'svn update' has already downloaded a copy of everything in the<br> >> repository (and stored it in a .svn directory), so you can do:<br> >><br> >> shell> svn revert dx86cl64.image<br> >><br> >> which basically says "discard my local modifications to the specified<br> >> file and replace the working copy with the last version obtained from<br> >> the server."<br> >><br> >> If there's a convenient way to say "do 'svn revert' on all files<br> >> that 'svn status' reports as being in conflict", I don't know what<br> >> it is.<br> >><br> >> Anyway, the symptom is "trying to use an old image to compile new<br> >> sources", and if you just did an "svn update" and still have<br> >> an old image, this is a plausible explanation. Binary files<br> >> don't change that often, but when they do it's necessary to be<br> >> aware of the fact that svn can't do much but (conservatively)<br> >> not update the working copy.<br> >><br> >> On Wed, 23 Jul 2008, Chris Van Dusen wrote:<br> >><br> >>> Hi,<br> >>><br> >>> I'm trying to rebuild bleeding edge CCL from the command line<br> >>> (Leopard, X86_64), and am getting the following:<br> >>><br> >>> ? (ccl:rebuild-ccl :full t)<br> >>> ;Building lisp-kernel ...<br> >>> ;Kernel built successfully.<br> >>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nxenv.lisp"...<br> >>> ;Loading #P"/Users/chrisvandusen/bin/ccl/bin/nxenv.dx64fsl"...<br> >>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nx.lisp"...<br> >>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx-basic.lisp"...<br> >>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/lambda-<br> >>> list.lisp"...<br> >>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx0.lisp"...<br> >>> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx1.lisp"...<br> >>> ;Compiler warnings for "/Users/chrisvandusen/bin/ccl/compiler/<br> >>> nx0.lisp" :<br> >>> ; In MAKE-AFUNC: Undefined function %MAKE-AFUNC<br> >>> ;Loading #P"/Users/chrisvandusen/bin/ccl/l1-fasls/nx.dx64fsl"...<br> >>> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/<br> >>> optimizers.lisp"...<br> >>>> Error: Undefined function %MAKE-AFUNC called with arguments () .<br> >>>> While executing: MAKE-AFUNC, in process listener(1).<br> >>>> Type :GO to continue, :POP to abort, :R for a list of available<br> >>> restarts.<br> >>>> If continued: Retry applying %MAKE-AFUNC to NIL.<br> >>>> Type :? for other options.<br> >>> 1 ><br> >>><br> >>><br> >>> The warning seems a foreshadowing of the error to come, but that's<br> >>> just me guessing. If there's any more info that might be helpful,<br> >>> let<br> >>> me know.<br> >>><br> >>> Thanks,<br> >>> Chris.<br> >>> _______________________________________________<br> >>> Openmcl-devel mailing list<br> >>> <a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br> >>> <a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br> >>><br> >>><br> ><br> > _______________________________________________<br> > Openmcl-devel mailing list<br> > <a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br> > <a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br> <br> _______________________________________________<br> Openmcl-devel mailing list<br> <a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br> <a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br> </div></div></blockquote></div><br></div></div></blockquote></div><br></div></body></html>