 |
 |
Hi, I would not be too hesitant to commit code to the repository, because older file revisions are easily retrieved. If you break something, then the trunk copy can be replaced with an older revision. That doesn't mean you should commit code that does not compile though so always build locally the file revisions you are going to checkin to the repository. Also, checking with the author of the original class about your modifications is not a bad idea before you change it. They might have some opinions about it. By the way, I have tried to make a new package that would contain monitoring drivers. It is found at trunk/monitoring-drivers so if you're going to make new ones then put them there. There are currently two classes in that module, one for SVT and another for ECal, that have some basic plots. Feel free to add to those and checkin to the SVN. My preference is moving development of monitoring drivers to that package instead of hps-java. --Jeremy -----Original Message----- From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Andrea Celentano Sent: Wednesday, February 26, 2014 4:31 AM To: Gabriel CHARLES Cc: hps-software Subject: Re: Ecal monitoring Hi Gabriel, thanks. Why you suggest to not commit the EcalHitPlots in the case I modify it (I have not done it!)? I mean, the idea I have is that when you work on a piece of the software, at a certain point it will be part of the "hps-software". How is this managed? Who is responsible to decide when a certain "part" will be inserted in the main trunk? I ask this because I prefer to know this in advance, before starting the real work, in order to not have to re-do later one. Thanks! Andrea Il 02/26/2014 01:16 PM, Gabriel CHARLES ha scritto: > Hi Andrea, > > I think you can do both but respecting different conditions. > > If you modify EcalHitPlots and do not commit it, no one will see it, > so you can do whatever you want, but you must be sure you won't commit > it by mistake and organize your own backup. It is not what I would > recommend. > > If you create a new class and want to commit it, you can create it > here: "src.main.java.org.lcsim.hps.users.acelentano", for me it is > located in the java trunk, and there is a folder "users". I think this > is the prefered solution because you can share it with other if needed. > > If it can help, when you create your own PlotsDriver without any > option you can call it from the steering file this way: > > <driver name="YourDriverName"/> > > <driver name="YourDriverName" > type="org.lcsim.hps.users.acelentano.PlotsDriver"> > </driver> > > Hope it helps, > --- > Gabriel CHARLES > Institut de Physique Nucléaire d'Orsay > > On Wed, 26 Feb 2014 12:22:39 +0100, Andrea Celentano wrote: >> Dear all, >> a stupid question about the "proper/standard/hps-defined/.." way to >> proceed for the Ecal monitoring: >> >> - I see there is a class org.lcsim.hps.ecal.monitoring.EcalHitPlots >> that implements (some) of the plots I'd like to add. >> - Should I modify it, adding what I need OR -Should I create a new >> class, modify the steering file accordingly (and eventually copying >> the pieces of code I need from EcalHitPlots)? >> >> Thanks >> >> Andrea >> >> >> ##################################################################### >> ### >> 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