One thing worth doing before investigating is to remove the possibility of 
problems due to case-insensitivity.  No two classes/files/whatever with same
name with different cases.  It's worth a shot ...
-Nathan


On Feb 12, 2015, at 5:51 PM, Omar Moreno <[log in to unmask]> wrote:

> 
> 
> On Thu, Feb 12, 2015 at 2:32 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
> Hi, Omar.
> 
> > Did you rename the old version SVTEvioReader to SvtEvioReader and forgot?  Does the file that you have locally match what is in the trunk? 
> 
> I did not do anything to these files.  I was working from what was in SVN trunk.  I think something you did with these files made it look like there was an untracked local copy on multiple people's working copy of the trunk.  I did a diff of the local copies of SvtEvioReader.java and SVTEvioReader.java and there was no difference.  So I deleted SVTEvioReader.java, and along with a few svn commands to fix up my local copy so that it didn't see conflicts, that seemed to resolve the problem.
> 
> I​ simply committed the files so I'm not sure how that could have affected anything and SVN did know about the two different files yesterday.  I'm not sure what could have caused this on my end ...​
> 
> If I understand correctly the restructuring you did of these classes, the TestRunSvtEvioReader class is intended to replace the old SVTEvioReader, and SvtEvioReader is the new class for future runs.  So there is really no need to keep around SVTEvioReader.java if it is not being used, and it is not used in the code right now from what I can tell.  There's also no need to "sandbox" it because it is still present in prior revisions before it was deleted, should we ever need to recover it.
> 
> ​Yes, that was the eventual plan.  However, there was code in there that I was still going to port over (specifically, temperatures).   I guess I can always revert and rename the file myself but I'll just untrack my local copy.  I know you want to maintain the repo as clean as possible, but send me an email next time before you decide to delete something SVT related.  That will give me a chance to back it up if I need too. 
> ​​
> It seemed to me that everything is fine now because both your tests of Test Run and Engineering Run event building using the readers passed successfully when I ran the build.
> ​
> Both of the test were running before.  Where you having problems running the test? The build didn't fail when I committed the files a couple of days ago so I assumed that it was fine. ​ 
> 
> Or is something messed up in your working copy now?
> 
> ​My working copy is fine and has been fine since my last update (yesterday).  Unless you did something other than deleting SVTEvioReader, I should be fine when I update again.
> 
> 
> —Jeremy
> 
> On Feb 12, 2015, at 1:31 PM, Omar Moreno <[log in to unmask]> wrote:
> 
>> This is the version of SVTEvioReader as of yesterday: 
>> 
>> http://java.freehep.org/svn/repos/hps/show/java/trunk/evio/src/main/java/org/hps/evio/SVTEvioReader.java?revision=%7b2015-02-11%7d
>> 
>> As you can see, it's completely different.  The SVN message you got seems to imply that you already had an untracked local copy of SvtEvioReader.  Did you rename the old version SVTEvioReader to SvtEvioReader and forgot?  Does the file that you have locally match what is in the trunk? 
>> 
>> 
>> 
>> On Thu, Feb 12, 2015 at 1:08 PM, Omar Moreno <[log in to unmask]> wrote:
>> ​i just did a diff on the two files I have locally and they are completely different. I haven't updated in a couple of days though. Let me check the commit logs and try to decipher what happened.
>> 
>> I did a diff on the two files and they were exactly the same, so the old one must have gotten clobbered somehow.
>> 
>> But wasn’t the intention here that you preserved the Test Run code here
>> 
>> evio/src/main/java/org/hps/evio/TestRunSvtEvioReader.java
>> 
>> So I don’t think we need the old SVTEvioReader.java file at all now, unless I’m not understanding what you did.
>> 
>> On Feb 12, 2015, at 12:32 PM, Omar Moreno <[log in to unmask]> wrote:
>> 
>>> SVTEvioReader was not added inadvertently, that was the original SVT Evio reader used for the test run.   That said, can you un-delete the file and rename it or put it in the sandbox?   I never made sure if everything in the file was ported over to the new reader so it shouldn't have been deleted. 
>>> 
>>> On Thu, Feb 12, 2015 at 12:22 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
>>> Hi,
>>> 
>>> I found there was a strange problem in my copy of the HPS Java trunk today. 
>>> 
>>> There was a conflict reported about this file.
>>> 
>>> src/main/java/org/hps/evio/SvtEvioReader.java
>>> 
>>> I think the problem was that there was also inadvertently added a file called “SVTEvioReader.java” which on some platforms/configurations is considered the same file.  Or there was a rename that didn’t work properly.  (Not sure.)
>>> 
>>> So even after fully updating I was getting some messages like
>>> 
>>> [564 $] svn status
>>> D     C src/main/java/org/hps/evio/SvtEvioReader.java
>>>       >   local unversioned, incoming add upon update
>>> Summary of conflicts:
>>>   Tree conflicts: 1
>>> 
>>> To resolve this I did
>>> 
>>> svn resolve accept --working src/main/java/org/hps/evio/SvtEvioReader.java
>>> 
>>> after which the conflict was resolved but it still seemed to want to mark it as deleted anyways
>>> 
>>> [567 $] svn status
>>> D       src/main/java/org/hps/evio/SvtEvioReader.java
>>> 
>>> so then I did 
>>> 
>>> [568 $] svn revert src/main/java/org/hps/evio/SvtEvioReader.java
>>> Reverted 'src/main/java/org/hps/evio/SvtEvioReader.java'
>>> 
>>> And all seems to be well now.
>>> 
>>> If you have any trouble with this let me know.
>>> 
>>> —Jeremy
>>> 
>>> Use REPLY-ALL to reply to list
>>> 
>>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>>> 
>>> 
>> 
>> 
> 
> 
> 
> Use REPLY-ALL to reply to list
> 
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
> 

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1