Re: [binarycloud-dev] CVS missing ./core/ directory

[alex b. <en...@tu...>]

> 1.  No file, no directory that is named "core" checks out.
> I co'ed from home in a bare directory and then
> [jef@localhost tmp]$ find . -name Debug.php
> [jef@localhost tmp]$ find . -name init
> ./r2/binarycloud/base/init
> [jef@localhost tmp]$ find . -name core
> [jef@localhost tmp]$

yeah, I'll fix that tomorrow - I _would_ like to know why cvs doesn't like
that dir, your points below about core dumps may actually be true..

> But I think you knew this.  This must be
> some "feature" of CVS, to avoid core dumps
>
> 2.  I can't remember exactly what the second question was,
> but I first co'ed in a place in my home directory
> for my "pristine" cvs place.  Then I make in
> the MYPLACE/r2/binarycloud directory to see
> if there are any errors/problems.  Then I copy
> MYPLACE/r2/binarycloud to /usr/local/binarycloud
> and make in /usr/local/binarycloud.  I have to
> make again, because of the self-generated stuff
> such as in prepend.php which ends up defining
>
> define('BC_PATH', '/home/jef/bc/r2/binarycloud/build/en');
>
> instead of
>
> define('BC_PATH', '/usr/local/binarycloud/build/en');

if you consider /usr/local/binarycloud "production" - then you would only
ever need to copy r2/binarycloud/build/

> where the "development" thingy is.
> So, I have to do a second make, and cannot just
> copy and run...  Yea, I could copy and probably
> edit and then run, if I knew for sure what to
> edit (anything besides prepend.php???).

Oh, yeah, that's marked for doing - i.e. we will incorporate a "location"
facility into the path definitions, which allows you to switch paths based
on environment, or manually, etc.

I.e. that make is complete, but is intended only for use in a single
location. That will obviously change in future.

> Maybe I am being redundant, and I am not quite sure
> what the second question was.  I hope this helps.
>
> As far as I know, there is only the problem of no
> core directory.  And as said, I am still humping along
> because I grabbed the ./core/* directory out of the tarball.

And that's essentially current.

> PS:  I don't know cvs very well at all.  Is it possible that
> the "filtering" of "core" out can occur on the client
> side, and not your side?

no, because it isn't in cvsroot.

erg

_a