Forum for JP1 remotes
https://www.hifi-remote.com/forums/
Thanks Capn - you are right - you would think I would have gotten that right since I use that one! I will check those out and try to do another release this weekend with the issues from the last few posts.Capn Trips wrote:xnappo: You apparently overlooked this [DeviceTypeAliases] change that Greg provided you for the Atlas OCAP RDF. I assume that it is required in ALL Atlas JP1.3 RDFs. (I certainly need it in the 3A333A33 RDF). Your RDF distro has a slightly different entry in the 30333033 RDF, and a completely different one (no "VCR" line at all) in the others (30003000, 30323032, 3A303A30, 3A333A33). Could you check those out?
My best guess is that you did a right-click>save on a link where you were supposed to click on the link in order to download the file.mathdon wrote:What I downloaded turned out to be HTML files that I could not understand, despite them having the .rdf extension and being named appropriately for RDFs.
This is an annoying artifact of the revision control system. When I label the files as a group as being part of the release, it adds a version number to all of the files. So version '812' in this case just indicates that they are all part of a release. I don't know if there is any way to prevent that and agree it is confusing. In the future I will at least make sure that when you look at the detailed information, you will see "812 tagging files for 1.30 release" or something so it is at least clear there was no real change to the file. Greg if you know something I don't here please chime in.mathdon wrote:
1. The files in the RDF Release Area (which it says are those in the current release) have a later revision number than those in the RDF Beta Area (which it says are ones intended for the next release). Am I misunderstanding the revision number?
They are the same.mathdon wrote: 2. I have downloaded the zip file from the link "RDF Files needed for IR and RM - version 1.30". In view of question 1, are the files in this zip actually those in the RDF Release Area or are they an earlier version?
I am not having that exact problem, but I am having problems with my browser thinking that RDF files are XML and trying to parse them. At any rate, the easiest way I have found to get an individual RDF is to 'right-click' the 'As Text' button and do a save-as. If anyone knows how to get it to stop acting like an RDF is XML please let me know!mathdon wrote: 3. I tried to answer these questions myself by downloading the RDFs that most interest me directly from the Release and Beta areas. to compare them with those in the zip file. What I downloaded turned out to be HTML files that I could not understand, despite them having the .rdf extension and being named appropriately for RDFs. What was I doing wrong? I tried everything I could think of but found no way of getting the actual RDFs from these areas.
Sure, three choices here:mathdon wrote: One thing I did discover, from the zip file, is that RDFs for URC-7781 Extender A2, and for both extenders A1 and A2 for URC-7780, are missing. I want to supply those after I have made updates to them corresponding to those that you have made in the URC-778x RDFs that are present in the zip file. Do I post them in the RDFs - Development section? If so, is there any way to indicate that they are mature RDFs that should go (I hope) into the next release, rather than ones genuinely still under development?
Since the 'Beta' link always represents the latest files added, I can't really make a zip that will be the same as the beta area.mathdon wrote:Is there a way of getting all the Beta section files together as a single zip file?
No need, I was just asking what was currently possible. However, what I found for the files that I downloaded from the Beta area was that they were identical to the ones in the release. Was there any way I should have been able to tell that, without downloading and comparing them? More generally, is there a way of seeing which files in the Beta area are actually later versions than in the release? I had naively assumed that the Beta area only contained files changed from the release, but I think now that it must contain all latest versions, whether they have changed from the last release or not.xnappo wrote:If the group feels that I need to have intermediate releases in zip format (like 1.31_beta1) then can do that too...
Yes - if the file in the beta area had a version higher than '812' then it is newer than what was in the release. This is, of course, not obvious. This revision control tool works in a way that takes some getting used to. Basically any time a file is changed it gets the next available number for the whole collection of files. So after I did a release which happened to be at version '812', the next file that gets changed with get '813'.mathdon wrote: No need, I was just asking what was currently possible. However, what I found for the files that I downloaded from the Beta area was that they were identical to the ones in the release. Was there any way I should have been able to tell that, without downloading and comparing them?
Glad you got it set up! Hmm, there definitely should have been a box for a comment when you did the 'commit'....mathdon wrote: As for the missing files that I mentioned, I've gone the whole hog - installed TortoiseSVN and uploaded them myself. I can now see them in the Beta area, but all the others have a log entry against them. I didn't see any opportunity to add a log entry, such as "New RDF", when I did the "commit". Was I missing something?
That would have been my assumption too, and that's certainly how we used to do it. In other words, once an RDF moved from beta to the official release, it was deleted from the beta folder.mathdon wrote:I had naively assumed that the Beta area only contained files changed from the release
I don't see anyway to do that with the definition I am using now for Beta - which in revision control terms is really 'Latest' - the latest version of all the files.The Robman wrote:That would have been my assumption too, and that's certainly how we used to do it. In other words, once an RDF moved from beta to the official release, it was deleted from the beta folder.mathdon wrote:I had naively assumed that the Beta area only contained files changed from the release
I would hope that that would be the case with the sorceforge versions too.
That works for me. Can you add comments to help make that point (wherever you think they're needed).xnappo wrote:Consider the 'Development' area to be the old test area, and beta to be the stuff that will be in the next release.
Then I presume it was there but I didn't realise its significance. I'll look more carefully next time, now that I know it is something that appears on the Sourceforge page.xnappo wrote:Hmm, there definitely should have been a box for a comment when you did the 'commit'....