Date: Sat, 3 Oct 2009 18:30:45 -0400
Subject: Re: [SDSS3-infrastructure 1507] Re: 2.5m obslog 20091002 (MJD 55107)
From: Michael Blanton
Dear Dan,
The latest version is always the
one checked into the svn server.
The link you mention below is an
html link to a working copy of
the product --- that is, a checked-out
version --- that we provide for
convenience --- you don't *have*
to use it, and as I've mentioned
before it would be best practice
*not* to.  We, in practice, have
always kept this check-out up
to date when we've released or
retrofit plates, so I don't think it
has caused a problem (yet).
You may have working copies on the
mountain that are not being svn updated
(though I think at least some are
auto-updated).  Anyway, that is what
Kaike's description implied.  I think
somebody needs to track down
where that is going awry.
Thanks,
Mike
On Sat, Oct 3, 2009 at 6:06 PM, Dan Long  wrote:
> Hi Mike (and any other svn savvy types),
>
> =A0 I would really like a better idea of what is being updated and where
> various bits of software look for things. =A0I and the pluggers were goin=
g
> under the assumption that if we looked at the plugMapP and overlay files =
in
>
> http://data.sdss3.org/products/NULL/platelist/trunk/plates/0036XX/003634/=
plateLines-003634-guide.png
>
> that not only was this the latest and most legitimate version, but that t=
his
> was where everyone else looked (including the software).
>
> =A0 From what Mike says, this appears not to be the case. =A0I think it i=
s not
> unreasonable to require that an operational machine checks automatically =
and
> frequently to make sure that it is running the latest approved/current
> version of anything operationally critical. Or like Paul said, anytime a
> mapping operation happens, have the mapping script check that wherever it=
 is
> looking matches the official version and complain (or update) if it isn't=
.
>
> =A0 This mid-day hurried change shouldn't happen often, but the mapping (=
or
> other software) should be able to flag a problem when it does. =A0Can thi=
s be
> done?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cheers,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dan
>
>
>> Hi Kaike,
>>
>> I checked in (yesterday Oct 2) new versions
>> of the files into the SVN product on the svn server
>> at trac.sdss3.org. No check-ins have occurred
>> since then.
>>
>> That does NOT mean that the /home/sdss3/...
>> working copy of the product got "svn up"ed
>> (whatever machine that is on, I don't know
>> and certainly don't have access to).
>>
>> Nothing has been checked into the platelist
>> product since my check-in yesterday. However,
>> you (or a robot more likely) might have *updated*
>> your working copy today.
>>
>> This sort of misunderstanding most likely
>> explains some of the previous anomalies
>> as well. You need to *actually* to have
>> updated your working copy for the working
>> copy to have been updated.
>>
>> Useful commands:
>> - "svn stat -u" compares your working copy to the servers
>> - "svn log [filename]" gives the history of the file
>> - "svn up" will update your working copy
>> Note also that the browser on the trac system
>> also gives useful revision history information.
>>
>> Before observing these plates, you'll want to
>> double-check that the *pluggers* used the right
>> versions of the overlays (though they *must* have
>> else they would have complained about having
>> 16 holes to plug with only 11 fibers), and that
>> the guider knows about the actual latest plugmap
>> files.
>>
>> Thanks,
>> Mike
>>
>> On Oct 3, 2009 2:23pm, kaike pan  wrote:
>>>
>>> =A0Thanks Paul,
>>>
>>> =A0 =A0 =A0Short answer: No. The plPlugMapM files were based
>>> =A0on yesterday version of plPlugMapP files. Apparently, someone
>>> =A0updated these plPlugMapP files today (Oct. 3rd).
>>>
>>>
>>> =A0Detail: =A0 =A0My script gets plPlugMapP files from SVN products
>>> =A0(i.e. /home/sdss3/products/Linux64/plateList/trunk/plates)
>>> =A0and converts to plPlugMapM files. Mike and Dan worked
>>> =A0on plugMapP files for these plates to re-assign guiding =A0fibers.
>>> According to Mike's email, he did update SVN
>>> =A0products. The script was ran after Mike's update. So
>>> =A0the current plPlugMapM files should use plPlugMapP
>>> =A0files from yesterday (Oct 2) afternoon update.
>>>
>>>
>>> =A0 =A0However, When I check now and find the last version
>>> =A0of plPlugMapP files were checked into today (Oct. 3). =A0We had prob=
lem in
>>> loading these plates into DB, so
>>> =A0Demitri and Craig were contacted, and helped us
>>> =A0to solve the loading problem. Thanks to Demitri and Craig.
>>>
>>>
>>> =A0Demitri, did you edit plPlugMapP files when you worked
>>> =A0on the loading problem last night? Did you or do you
>>> =A0know someone updated the plateList?
>>>
>>>
>>> =A0Thanks,
>>>
>>>
>>> =A0-kaike
>>>
>>>
>>>
>>>
>>>
>>> =A0On Oct 3, 2009, at 11:50 AM, paul harding wrote:
>>>
>>> =A0I will look at the guiding problem on Cart 5 plate 3632 Side B.
>>> =A0However I suspect the problem is some form of mismatch
>>> =A0in the PlPlugMapM file.
>>>
>>>
>>> =A0Kaike,
>>> =A0Can you verify that the plplugmap file you edited is the latest vers=
ion
>>> =A0that mike created?
>>>
>>>
>> =A0> Paul
>>>
>>>
>>> =A0On Oct 3, 2009, at 7:50 AM, Kaike Pan wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Message 1507 of sdss3-infrastructure -
>> sdss3-infrastructure@sdss3.org
>> https://sdss3.org/mailman/listinfo/sdss3-infrastructure
>
>
--=20
Michael Blanton
Assistant Professor
Department of Physics
New York University
212-998-7770