Print

---

Hi, Matt.

I have a different take on this….

Files that are removed from the trunk with ‘svn rm’ are not really deleted.  Every global revision of the project is saved, so if you want to reminisce about old steering files, you can simply checkout a prior revision of the code that has those files, if all you want to do is look at them.  

If a file is deleted but you want it back, you can perform a reverse merge to get it back into your working copy based on the revision where it was removed.  Suppose in r1234 (listed as “new revision” in the emails you get from checkins) I deleted a file that you want back, then all you need to do is…

You’d remove the “dry-run” on this command to actually do it.  That command will show you what would happen, so it is best to check first.  Then you would check the file back into the trunk.  This will get your deleted file back.

As far as broken steering files, if a steering file won’t even initialize properly via the JobManager, it references a non-existant Driver or has parameter calls which don’t map correctly onto “set” methods in the Driver’s API.  So in that state it is unusable.  I definitely made an effort to fix all steering files where I could, but some of them referenced old Drivers that were deleted and do not have replacements.  So, to my mind, it is better to simply remove those outdated steering files from the trunk, so that there aren’t a bunch of broken configuration files in our SVN, even if they are in a “users” area.  If you actually need/want something I deleted and want to leave it broken, then my preference would be that you “undelete” it using the merge command from above and move it into the sandbox to indicate that it doesn’t work.  I think all steering files in the steering-files module should at least initialize properly.  (Whether they actually work in a job is more difficult to check thoroughly!)

As far as having a separate users project, there is some merit to the idea, but ultimately I don’t agree with this.  The problem is that this module would tend to be in a continually broken state as it would be less clear when changes to HPS Java break it (you pretty much know this immediately now).   And if it is depending on an HPS Java release rather than a snapshot, it will get out of date.  And then you have to fix a bunch of compilation errors when you actually want to release it.  (I have had some previous experience with a similar situation when there was a separate user “contrib” project for lcsim, which was a continual source of headaches.)  So I think it is best to at least make sure that the users area compiles against the current snapshot at all times.

That said, if you have important code that must be kept up to date and working, it should really have one or more tests associated with it that run with the build to make sure that changes don’t break it.  And I think probably it should not really be in the users area.  It should go in some other module like analysis or recon, etc.  At any rate, I think keeping the users area included with the entire build so that it is kept continually up to date with HPS Java trunk is a good idea.

—Jeremy

Some files, like very old analysis steering files and certain monitoring configurations from the Test Run, were too out of date to salvage easily, so I deleted them.  If you want something back that was deleted, let me know, and we can work on fixing them.  Most of these didn't really look like they'd be worth the effort to bring up to date, and I did not delete any steering files that are important for recon passes or upcoming operations.

Generally, I don’t think it’s a great idea to delete files even if they can’t be salvaged to work with changes made somewhere else…especially something like steering files (particularly in the user directory) that can’t break the build.  I’ve definitely gone back to old steering files in order to remind me what I was thinking months ago.  I can see keeping the “official” steering files clean (e.g. production, recon, calibration, etc…) but I don’t really want anyone deleting my old steering files.

On a slightly different note…I wouldn’t mind having the org.hps.users be separated from the hps-java build.  It should be a separate package in my opinion...