[New: openFATE 308844] rcs: not an RCS ...
Feature added by: Michael Meeks (michael_meeks) Feature #308844, revision 1 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Jan Engelhardt (jengelh) Feature #308844, revision 2 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. + Discussion: + #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) + Recently, I deleted a project in a local OBS (which had Botan-1.8.8), + and the tarballs were retained in /srv/obs/sources.. clearly: + + 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- + Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. + bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 + 263ea51001ab49f3e5f26fb18d415996-Botan.changes + 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 + 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec + 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch + 590fb4da477eb6fe3044de507c252ee6-MD5SUMS + 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch + 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS + 902aca690474166103e77278edb99f37-Botan.spec + a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch + a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch + cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 + cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch + d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS + d3fdeb79e33037185c2906e033e06a16-Botan.spec + d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- + Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch + dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch + eddec67063305833d211fbe6056c4932-MD5SUMS + fab181550abb855b694059ec602e6724-MD5SUMS -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Jan Engelhardt (jengelh) Feature #308844, revision 3 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS + #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) + I hate this openfate html thing. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Michael Meeks (michael_meeks) Feature #308844, revision 4 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. + #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) + I particularly dislike the way it doesn't push a comment when you enter + it [ why !? ] - but waits for you to hit "Save" - which it cunningly + hides at the top of the screen. Then there is the "Add comment" legend + on the button - which should perhaps read: "Don't really add the + comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on + button click) would be rather better - I'm still confused by the wiki + "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose + content: lets not copy that mis-feature :-) + #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) + You deleted a project, or the packages, or both ? :-) of course my + comments wrt. RCS for packages apply to projects too: good point. + Either way - it is comforting to know that some of the data is still + lurking somewhere inside the magic backend ;-) but I am not really + looking for disaster recovery, but the ability to view and understand + history: revisions, timestamps, who changed what when, and what they + changed (with simple diffing). -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Jan Engelhardt (jengelh) Feature #308844, revision 5 Title: rcs: not an RCS ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). + #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) + I hit "Delete Project" in the webinterface, under the assumption that + doing so is basically an rm -Rf and includes deletion of the packages + within that project. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308844, revision 6 - Title: rcs: not an RCS ... + Title: Offer Undelete of packages and projects - Buildservice: New + Buildservice: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: - 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) I hit "Delete Project" in the webinterface, under the assumption that doing so is basically an rm -Rf and includes deletion of the packages within that project. + #6: Adrian Schröter (adriansuse) (2010-01-21 11:55:20) + the new branch feature should solve some of the described issues. + What is open here, is the offer an "undelete" of a package or project + what would restore also the history. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Michael Meeks (michael_meeks) Feature #308844, revision 7 Title: Offer Undelete of packages and projects Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) I hit "Delete Project" in the webinterface, under the assumption that doing so is basically an rm -Rf and includes deletion of the packages within that project. #6: Adrian Schröter (adriansuse) (2010-01-21 11:55:20) the new branch feature should solve some of the described issues. What is open here, is the offer an "undelete" of a package or project what would restore also the history. + #7: Michael Meeks (michael_meeks) (2010-01-22 14:22:43) (reply to #6) + Ah - good point about branches; one really common use-case, that is + just -shockingly- unpleasant right now; is of branching [ ie. copypac' + ing ] the whole project [ linking can't be used because of the risk of + deletion of the underlying package ], and then hacking a lot: editing + lots of packages to update them; then of course work continues on the + main 'branch' - and then - when it comes time to doing the merge, or + trying to read the 'diff' between the two projects - everything is a + nightmare: in large part because this is not an RCS - and it has no + idea of the branch-point, and it can't do an intelligent / informed + merge. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308844, revision 8 Title: Offer Undelete of packages and projects Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) I hit "Delete Project" in the webinterface, under the assumption that doing so is basically an rm -Rf and includes deletion of the packages within that project. #6: Adrian Schröter (adriansuse) (2010-01-21 11:55:20) the new branch feature should solve some of the described issues. What is open here, is the offer an "undelete" of a package or project what would restore also the history. #7: Michael Meeks (michael_meeks) (2010-01-22 14:22:43) (reply to #6) Ah - good point about branches; one really common use-case, that is just -shockingly- unpleasant right now; is of branching [ ie. copypac' ing ] the whole project [ linking can't be used because of the risk of deletion of the underlying package ], and then hacking a lot: editing lots of packages to update them; then of course work continues on the main 'branch' - and then - when it comes time to doing the merge, or trying to read the 'diff' between the two projects - everything is a nightmare: in large part because this is not an RCS - and it has no idea of the branch-point, and it can't do an intelligent / informed merge. + #8: Adrian Schröter (adriansuse) (2010-02-20 17:09:52) (reply to #7) + There will be project source links. This will be more efficient than a + full copy or link (simply because only needed, but not all packages + need to rebuild). And just the changes are stored in the linking + project. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308844, revision 9 Title: Offer Undelete of packages and projects Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. + Relations: + - Depends on 308802 (reorg of meta files on server side) (feature/id: + 308802) Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) I hit "Delete Project" in the webinterface, under the assumption that doing so is basically an rm -Rf and includes deletion of the packages within that project. #6: Adrian Schröter (adriansuse) (2010-01-21 11:55:20) the new branch feature should solve some of the described issues. What is open here, is the offer an "undelete" of a package or project what would restore also the history. #7: Michael Meeks (michael_meeks) (2010-01-22 14:22:43) (reply to #6) Ah - good point about branches; one really common use-case, that is just -shockingly- unpleasant right now; is of branching [ ie. copypac' ing ] the whole project [ linking can't be used because of the risk of deletion of the underlying package ], and then hacking a lot: editing lots of packages to update them; then of course work continues on the main 'branch' - and then - when it comes time to doing the merge, or trying to read the 'diff' between the two projects - everything is a nightmare: in large part because this is not an RCS - and it has no idea of the branch-point, and it can't do an intelligent / informed merge. #8: Adrian Schröter (adriansuse) (2010-02-20 17:09:52) (reply to #7) There will be project source links. This will be more efficient than a full copy or link (simply because only needed, but not all packages need to rebuild). And just the changes are stored in the linking project. -- openSUSE Feature: https://features.opensuse.org/308844
Feature changed by: Adrian Schröter (adrianSuSE) Feature #308844, revision 10 Title: Offer Undelete of packages and projects - Buildservice: Evaluation + Buildservice: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: We need a decent revision control system to back OBS, and one that we can trust, not to loose data. My preferred option is git [ though clearly not for the big binary files, and huge patches, which need a bespoke 'storage' ]. Currently, the obs RCS looses history very routinely. There are -lots- of ways to loose a packages' entire history: + when it is removed - it looses all history - rather than being hidden from that date. + IIRC - osc copypac also trashes history, not even copying the source history. Of course - tagging is not possible: so, in order to have branches, or known-good-states of a project it is necessary to 'osc copy' a load of packages (using a slew of unreliable manual shell-scripting). Resolving conflicts is horrible, particularly with the 'repairlink' tool, which is highly non-intuitive, and routinely auto-breaks packages. I -always- resort to attempting the conflict resolution by some more pedestrian and reliable manual means locally. While it is claimed that the 'obs' is "subversion-like" - we seem to have captured all the negatives of subversion: such as not knowing where your tags are - and none of the benefits: such as retaining full history, and history informed merges etc. when you branch & tag. Relations: - Depends on 308802 (reorg of meta files on server side) (feature/id: 308802) Business case (Partner benefit): openSUSE.org: Using git would allow us to learn a tool that is widely useful and familiar in the software world, rather than something that is at best equally twisty, but worse - different. Discussion: #1: Jan Engelhardt (jengelh) (2010-01-19 01:41:02) Recently, I deleted a project in a local OBS (which had Botan-1.8.8), and the tarballs were retained in /srv/obs/sources.. clearly: 01:40 ares:../sources/Botan > ls 03026a8788c7ac2be5c2f810b89234a0- Botan.spec 0eb176c70b8b66d27247e6c22246fafa-Botan-ull_constants.patch. bz2 21f8ca8ea39f6a91ece2cb92127a0113-Botan-1.6.4.tar.bz2 263ea51001ab49f3e5f26fb18d415996-Botan.changes 2bf2f9df9a52cd326ecfdb2836cead29-Botan-ull_constants.patch.bz2 41b1abc34c3e696da89f2c78707c7b5e-Botan.spec 4e0a5b122fc80897b5b8a7ae7d5eff96-Botan-no_executable_stack.patch 590fb4da477eb6fe3044de507c252ee6-MD5SUMS 5e807da5314436eef9aa89875a88a1f7-Botan-missing_sentinel.patch 6cc56ccabd396eada9738ffebf90b7ef-MD5SUMS 902aca690474166103e77278edb99f37-Botan.spec a6a0976ab585006d0b6ea07315c8855a-Botan-fix_install_paths.patch a7983322375e92eedee5a6f5af784ffc-Botan-inttypes.patch cb7cf79c34414cdf1f7a25569d7b82ac-Botan-1.8.8.tar.bz2 cbf0d2dd8d09e68f70fa820fbd786be4-Botan-inttypes.patch d25f16c40b055a1ed8e85b11bc19fcdb-MD5SUMS d3fdeb79e33037185c2906e033e06a16-Botan.spec d41d8cd98f00b204e9800998ecf8427e-ready d4fdce6b89a596c60fd9144b54b0fcfe- Botan.spec d8b871e28d1a722d56d703a22860b40a-Botan-no_cpu_tuning.patch dc5b36c7c23071731fed8916b736efcf-Botan-no_fpermissive.patch eddec67063305833d211fbe6056c4932-MD5SUMS fab181550abb855b694059ec602e6724-MD5SUMS #2: Jan Engelhardt (jengelh) (2010-01-19 01:54:32) (reply to #1) I hate this openfate html thing. #4: Michael Meeks (michael_meeks) (2010-01-19 11:24:13) (reply to #2) I particularly dislike the way it doesn't push a comment when you enter it [ why !? ] - but waits for you to hit "Save" - which it cunningly hides at the top of the screen. Then there is the "Add comment" legend on the button - which should perhaps read: "Don't really add the comment yet" (or "Preview" perhaps ;-) IMHO - instant addition (on button click) would be rather better - I'm still confused by the wiki "YOU ARE ONLY VIEWING A PREVIEW" type logic, and occasionally loose content: lets not copy that mis-feature :-) #3: Michael Meeks (michael_meeks) (2010-01-19 11:22:02) (reply to #1) You deleted a project, or the packages, or both ? :-) of course my comments wrt. RCS for packages apply to projects too: good point. Either way - it is comforting to know that some of the data is still lurking somewhere inside the magic backend ;-) but I am not really looking for disaster recovery, but the ability to view and understand history: revisions, timestamps, who changed what when, and what they changed (with simple diffing). #5: Jan Engelhardt (jengelh) (2010-01-20 18:41:38) (reply to #3) I hit "Delete Project" in the webinterface, under the assumption that doing so is basically an rm -Rf and includes deletion of the packages within that project. #6: Adrian Schröter (adriansuse) (2010-01-21 11:55:20) the new branch feature should solve some of the described issues. What is open here, is the offer an "undelete" of a package or project what would restore also the history. #7: Michael Meeks (michael_meeks) (2010-01-22 14:22:43) (reply to #6) Ah - good point about branches; one really common use-case, that is just -shockingly- unpleasant right now; is of branching [ ie. copypac' ing ] the whole project [ linking can't be used because of the risk of deletion of the underlying package ], and then hacking a lot: editing lots of packages to update them; then of course work continues on the main 'branch' - and then - when it comes time to doing the merge, or trying to read the 'diff' between the two projects - everything is a nightmare: in large part because this is not an RCS - and it has no idea of the branch-point, and it can't do an intelligent / informed merge. #8: Adrian Schröter (adriansuse) (2010-02-20 17:09:52) (reply to #7) There will be project source links. This will be more efficient than a full copy or link (simply because only needed, but not all packages need to rebuild). And just the changes are stored in the linking project. + #9: Adrian Schröter (adriansuse) (2010-05-21 21:52:03) + almost complete implemented in backend, api and osc. We will still need + to do some bug hunting next week though. -- openSUSE Feature: https://features.opensuse.org/308844
participants (1)
-
fate_noreply@suse.de