<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>