Reply to thread

Message

Hi Chris,
Thanks for the reply....
Yes I have seen (and read!) your guides however..
1. They don't seem to be up to date with the new installation mechanism (which allows you to make a backup as part of the svn install process).
2. Although they give you a very clean install. The mechanism of starting from a base with no configuration then installing the svn and then configuring it, is not really so good if you actually want to update reasonably often and actually use the installed svn. The re-configuration can take some time. Also unless you do a backup/restore of your channels and recordings you will not have access to the recorded programs in the newly installed svn (which is a problem if it is this area that you may want to test/report a bug against). Seems to me that step 3 of my process follows your guide for testing reasonably closely, and it is this that I use when reporting a bug.

What I was trying to do was come up with a way of being able to track he nightly builds reasonably often on a working system, but also have a way of ensuring that the quality of problem reports is still good. My experience so far has been that more often than not you can simply install one svn over the top of another without causing too many problems. However if you do this then you must be prepared to every now and again go back to the base and clean things up (which is what I do whenever I have a bug to report). It takes a little more care but it means that I can use/test svns on a day to day basis....

Andy

<blockquote data-quote="gloomyandy" data-source="post: 99151" data-attributes="member: 24855">Hi Chris,Thanks for the reply....Yes I have seen (and read!) your guides however..1. They don't seem to be up to date with the new installation mechanism (which allows you to make a backup as part of the svn install process).2. Although they give you a very clean install. The mechanism of starting from a base with no configuration then installing the svn and then configuring it, is not really so good if you actually want to update reasonably often and actually use the installed svn. The re-configuration can take some time. Also unless you do a backup/restore of your channels and recordings you will not have access to the recorded programs in the newly installed svn (which is a problem if it is this area that you may want to test/report a bug against). Seems to me that step 3 of my process follows your guide for testing reasonably closely, and it is this that I use when reporting a bug.What I was trying to do was come up with a way of being able to track he nightly builds reasonably often on a working system, but also have a way of ensuring that the quality of problem reports is still good. My experience so far has been that more often than not you can simply install one svn over the top of another without causing too many problems. However if you do this then you must be prepared to every now and again go back to the base and clean things up (which is what I do whenever I have a bug to report). It takes a little more care but it means that I can use/test svns on a day to day basis....Andy</blockquote>

[QUOTE="gloomyandy, post: 99151, member: 24855"] Hi Chris, Thanks for the reply.... Yes I have seen (and read!) your guides however.. 1. They don't seem to be up to date with the new installation mechanism (which allows you to make a backup as part of the svn install process). 2. Although they give you a very clean install. The mechanism of starting from a base with no configuration then installing the svn and then configuring it, is not really so good if you actually want to update reasonably often and actually use the installed svn. The re-configuration can take some time. Also unless you do a backup/restore of your channels and recordings you will not have access to the recorded programs in the newly installed svn (which is a problem if it is this area that you may want to test/report a bug against). Seems to me that step 3 of my process follows your guide for testing reasonably closely, and it is this that I use when reporting a bug. What I was trying to do was come up with a way of being able to track he nightly builds reasonably often on a working system, but also have a way of ensuring that the quality of problem reports is still good. My experience so far has been that more often than not you can simply install one svn over the top of another without causing too many problems. However if you do this then you must be prepared to every now and again go back to the base and clean things up (which is what I do whenever I have a bug to report). It takes a little more care but it means that I can use/test svns on a day to day basis.... Andy [/QUOTE]