Page 81 of 85 FirstFirst ... 31717980818283 ... LastLast
Results 1,201 to 1,215 of 1264

Thread: TivoWebPlus 2.1 Testing and Development

  1. #1201
    Join Date
    Dec 2006
    Posts
    57
    I'm sure you're right - I was going via Code=>Browse on the SF website which gives you 070428
    http://tivowebplus.cvs.sourceforge.n...c/tivowebplus/
    Tivo since 2002. UK S1 + 1TB SATA. ex-TAM (tenner a month). Virgin Media not available here.

  2. #1202
    Join Date
    Oct 2009
    Posts
    40
    I've updated the sourceforge cvs tree to include all the newer oztivo releases, up through oztivo-110622. I didn't try to call out each individual change in that series. I'm not entirely sure that the oztivo-090121 tag acually represents that release, as there are a number of changes that seem to be reverted when I went to oztivo-090223, but then were re-added later (usually modified a bit). Looking at things this morning, it appears that the tag oztivo-090223 tag also didn't get done correctly, and it would be kinda hard to redo at this time (if there's demand, I'll give it a try, but cvs doesn't like to checkout by date and branch and does it extremely poorly). Again, this is on the v2-1 branch.

    For the new ddb-20120803 and ddb-2013013 I'll be trying to do individual commits, with pointers to posts in this thread. That will take a little more care, since in doing this I found a few of the changes in the mercurial were misattributed. It will take a little bit of time to sort out.

    Enjoy.

  3. #1203
    Join Date
    Dec 2006
    Posts
    57
    Excellent job, and worth doing I think. When it's 'stable' I'll add in some of the other bug fixes I've made (but which I didn't post here since I didn't deem them noteworthy enough)
    Tivo since 2002. UK S1 + 1TB SATA. ex-TAM (tenner a month). Virgin Media not available here.

  4. #1204
    Join Date
    Mar 2005
    Posts
    235
    bsdimp,
    I have cvs backup before you made your changes. It would be much easier for me to roll it back then re-apply oztivo updates then trying to go back and fix it. Probably best to do it before you start adding the individual commits. Let me know...

    spitfires,
    That sounds great. The plan is to bring it up to ddb-2013013, then bsdimp is going to add his patches. Once your patches are in, we can bump the version to 2.1b4 and move the 2.1 branch into HEAD, and the current HEAD into a 2.0 branch. This should make it easier to locate the latest version.

  5. #1205
    Join Date
    Dec 2006
    Posts
    57
    Sounds like a plan Please let me know when it's ready for me to mod.

  6. #1206
    Join Date
    Oct 2009
    Posts
    40
    Quote Originally Posted by jkozee View Post
    I have cvs backup before you made your changes. It would be much easier for me to roll it back then re-apply oztivo updates then trying to go back and fix it. Probably best to do it before you start adding the individual commits. Let me know...
    I'm not sure I understand what you are getting at here...

    spitfires,
    That sounds great. The plan is to bring it up to ddb-2013013, then bsdimp is going to add his patches. Once your patches are in, we can bump the version to 2.1b4 and move the 2.1 branch into HEAD, and the current HEAD into a 2.0 branch. This should make it easier to locate the latest version.
    Yes, I should likely create the 2.0 branch in CVS right away. But then CVS's "wonderful" merging process may get in our way. Moving the v2-1 branch to the default branch would be a bit of a shock to the system from a history point of view. Thankfully, the number of people relying on the 2.0 version in the mainline is vanishingly small, so any of the typical disruptive effects of merging a branch created 5 years ago can be ignored.

    Once me merge it to the default branch though, maybe we could just start calling it 2.1 or 2.1.0? After all, most of the fixes that are going in are relatively minor issues that are typical of production quality code as opposed to some of the larger bugs found in earlier releases which were more typical of beta quality code. I'd have no problems with one more round called 2.1.b4 to make sure that the merges we're planning don't cause unintended side effects, but after that, surely this has waited long enough. We could also upload releases to source forge again too.

    This might be enough to have other repackagers start to pick this up...

  7. #1207
    Join Date
    Oct 2009
    Posts
    40
    OK, I've created the 2.0 branch (as v2-0), so when we decide the time is ripe to pull the trigger and merge the v2-1 stuff to the repo head, we can do that any time. I doubt there ever will be a commit on the 2.0 branch, except maybe to fix any typos in the README file I dropped in there...

  8. #1208
    Join Date
    Mar 2005
    Posts
    235
    Quote Originally Posted by bsdimp View Post
    I'm not sure I understand what you are getting at here...
    I created a backup of the SF repository a few days ago. I can restore the backup to SF and it will be as if none of the changes you commited ever occured. Then either you or I can re-commit the updates you made. It would be far easier than trying to create to fix the missing oztivo-090223 tag.

  9. #1209
    Join Date
    Oct 2009
    Posts
    40
    Quote Originally Posted by jkozee View Post
    I created a backup of the SF repository a few days ago. I can restore the backup to SF and it will be as if none of the changes you commited ever occured. Then either you or I can re-commit the updates you made. It would be far easier than trying to create to fix the missing oztivo-090223 tag.
    Turns out I had a script from "back in the day" which let me kinda checkout by date enough that I could reconstruct the oztivo-090223 tag, which I just committed. So I'm ready to start committing the two ddb- versions....

  10. #1210
    Join Date
    Oct 2009
    Posts
    40
    I've committed the code that jkozee posted here in #1127 for the ddb-20120803 into the SourceForge CVS repo on the v2-1 branch and tagged it with ddb-20120803.

    I'll do 20130113 later. Once we have that, we can go forward from there. My current plan is to commit the v2-1 branch onto the default branch and do all further development on the default branch. This is more typically what's done for the 'current version' after a 'development branch' is merged back into the mainline. It will also give users looking for this the most up-to-date version by default. Please let me know if there's a problem with these plans.

    I'd also like to upload the 20130113 to source forge as well.

  11. #1211
    Join Date
    Oct 2009
    Posts
    40
    I've updated the sourceforge cvs repo to the latest ddb-20130113 dist from jkozee. Lemme know if I messed anything up.

  12. #1212
    Join Date
    Mar 2005
    Posts
    235
    Thanks bsdimp!

    It looks good to me. With your latest commit, we should be up to date with the patches from this thread (save the minor patch from #1186). I uploaded tivowebplus-v2.1.b3-20130113.tgz to the 2.1.0 directory on sourceforge, so that should appear as the latest version (for now).

  13. #1213
    Join Date
    Mar 2005
    Posts
    235
    Quote Originally Posted by spitfires View Post
    Sounds like a plan Please let me know when it's ready for me to mod.
    Things should be fairly stable for now, and ready for any updates.

  14. #1214
    Join Date
    Oct 2009
    Posts
    40
    I have a couple of fixes I'd like to get into the next spin. I'll post them here for review, and if people like them, we can roll them in. Sound like a plan?

  15. #1215
    Join Date
    Mar 2005
    Posts
    235
    Sounds good to me. I'll have some things to roll in as well.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •