Uploaded image for project: 'Plugins'
  1. Plugins
  2. CONTRIB-161

Someone borked the MOODLE_16_STABLE branch tags around March 23

    Description

    Someone issued a command similar to this at Moodle root level, in HEAD:

    cvs tag -B -b MOODLE_16_STABLE

    which means all the MOODLE_16_STABLE branch tags were moved to be the same as HEAD.

    Eloy and I have been working on this over the weekend.

      Gliffy Diagrams

        Issue Links

          Activity

          dougiamas Martin Dougiamas created issue -
          Hide
          dougiamas Martin Dougiamas added a comment -

          Eloy did a whole bunch of other cleaning up, but the last steps I did just now were:

          1) cvs update -dPr MOODLE_16_BETA (to get back to the old branching point)
          2) cvs tag -d MOODLE_16_STABLE (to delete all non-branch tags)
          3) cvs tag -B -b MOODLE_16_STABLE (to create the branch tag)
          4) cvs update -dPr MOODLE_16_STABLE (to return to 16_STABLE in my local copy)
          5) Use a new copy of the latest files before the disaster
          6) Copy all these files over the top of the MOODLE_16_STABLE checkout
          7) cvs commit with message, linking to this bug.

          Show
          dougiamas Martin Dougiamas added a comment - Eloy did a whole bunch of other cleaning up, but the last steps I did just now were: 1) cvs update -dPr MOODLE_16_BETA (to get back to the old branching point) 2) cvs tag -d MOODLE_16_STABLE (to delete all non-branch tags) 3) cvs tag -B -b MOODLE_16_STABLE (to create the branch tag) 4) cvs update -dPr MOODLE_16_STABLE (to return to 16_STABLE in my local copy) 5) Use a new copy of the latest files before the disaster 6) Copy all these files over the top of the MOODLE_16_STABLE checkout 7) cvs commit with message, linking to this bug.
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          Seems to be working ok now. I've compared current STABLE_16 checkout against safe copy of files before disaster and there aren't differences at all.

          IMO, this should help to learn that:

          1) branching is a "dangerous" operation that, currently can be performed by every developer. My +1 to protect CVS from such operations. Doing that now, MD will be the only one allowed.

          2) We must try to keep the list of unmerged files as small as possible always. it's a pain to analyse them when they are old while it's really simple to keep them updated in the commit moment. The list if updated regularly on http://docs.moodle.org/en/Unmerged_files and also, it's the FIRST search result when you introduce "unmerged files" in your favourite Google search box. So, please, let's keep them near 0. (exaclty now we should centre our efforts on the 17_STABLE and 18_STABLE unmerged files).

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - Seems to be working ok now. I've compared current STABLE_16 checkout against safe copy of files before disaster and there aren't differences at all. IMO, this should help to learn that: 1) branching is a "dangerous" operation that, currently can be performed by every developer. My +1 to protect CVS from such operations. Doing that now, MD will be the only one allowed. 2) We must try to keep the list of unmerged files as small as possible always. it's a pain to analyse them when they are old while it's really simple to keep them updated in the commit moment. The list if updated regularly on http://docs.moodle.org/en/Unmerged_files and also, it's the FIRST search result when you introduce "unmerged files" in your favourite Google search box. So, please, let's keep them near 0. (exaclty now we should centre our efforts on the 17_STABLE and 18_STABLE unmerged files). Ciao
          Hide
          dougiamas Martin Dougiamas added a comment -

          Eloy, thanks for all your hours spent on this over the weekend. I think we're in a good place now!

          Show
          dougiamas Martin Dougiamas added a comment - Eloy, thanks for all your hours spent on this over the weekend. I think we're in a good place now!
          dougiamas Martin Dougiamas made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          danmarsden Dan Marsden added a comment -

          This change means we can no longer manage our own branches in contrib...... any possibility of allowing users to branch in contrib, but not moodle core? - kinda makes the new design of contrib a bit bung! - or should we still log requests for contrib branching in the tracker?

          thanks!

          Dan

          Show
          danmarsden Dan Marsden added a comment - This change means we can no longer manage our own branches in contrib...... any possibility of allowing users to branch in contrib, but not moodle core? - kinda makes the new design of contrib a bit bung! - or should we still log requests for contrib branching in the tracker? thanks! Dan
          Hide
          dougiamas Martin Dougiamas added a comment -

          Is there really a need for arbitrary branches in contrib? Beyond the standard MOODLE_17_STABLE, MOODLE_18_STABLE etc ?

          Show
          dougiamas Martin Dougiamas added a comment - Is there really a need for arbitrary branches in contrib? Beyond the standard MOODLE_17_STABLE, MOODLE_18_STABLE etc ?
          Hide
          daniss Daniele Cordella added a comment -

          I am sorry to leave my comment here where my contribution in not relevant.
          I would like to answer to MD:
          > Is there really a need for arbitrary branches in contrib?
          If you are saying that all teaching problem were solved with MOODLE_17_STABLE, MOODLE_18_STABLE, I would say that AFAIK it is impossible, for istance, to hide participants email to participants and, at the same time, leave to participants a channel to send email to teachers.
          Have a look at my post in: http://moodle.org/mod/forum/discuss.php?d=47971
          This is a need not satisfied by MOODLE_17_STABLE, MOODLE_18_STABLE.

          Show
          daniss Daniele Cordella added a comment - I am sorry to leave my comment here where my contribution in not relevant. I would like to answer to MD: > Is there really a need for arbitrary branches in contrib? If you are saying that all teaching problem were solved with MOODLE_17_STABLE, MOODLE_18_STABLE, I would say that AFAIK it is impossible, for istance, to hide participants email to participants and, at the same time, leave to participants a channel to send email to teachers. Have a look at my post in: http://moodle.org/mod/forum/discuss.php?d=47971 This is a need not satisfied by MOODLE_17_STABLE, MOODLE_18_STABLE.
          Hide
          danmarsden Dan Marsden added a comment -

          .....maybe I'm using the wrong command in tortoise...... - I'm trying to turn the HEAD into MOODLE_18_STABLE....

          ...ahhh.... I see Moodle_18_stable was tagged when everything moved into the new structure! - so I "guess" I need to check out Moodle_18_stable, and then commit my changes to it instead of using HEAD.

          thanks,

          Dan

          Show
          danmarsden Dan Marsden added a comment - .....maybe I'm using the wrong command in tortoise...... - I'm trying to turn the HEAD into MOODLE_18_STABLE.... ...ahhh.... I see Moodle_18_stable was tagged when everything moved into the new structure! - so I "guess" I need to check out Moodle_18_stable, and then commit my changes to it instead of using HEAD. thanks, Dan
          Hide
          dougiamas Martin Dougiamas added a comment -

          Absolutely, Dan. I'd recommend having one MOODLE_17_STABLE site, one MOODLE_18_STABLE site and one HEAD site active at all times.

          The CVS docs do cover the merging dance but yell out please if you have any trouble understanding - it is complicated!

          Are you saying it might have been you who did the MOODLE_16_STABLE snafu last week?

          Show
          dougiamas Martin Dougiamas added a comment - Absolutely, Dan. I'd recommend having one MOODLE_17_STABLE site, one MOODLE_18_STABLE site and one HEAD site active at all times. The CVS docs do cover the merging dance but yell out please if you have any trouble understanding - it is complicated! Are you saying it might have been you who did the MOODLE_16_STABLE snafu last week?
          Hide
          dougiamas Martin Dougiamas added a comment -

          Daniele .... errr, no, we are not saying every version of Moodle satisfies the needs of every user on the planet. If it did we could stop working and do something else.

          STABLE just means that no new FEATURES are being added to that branch, we only fix bugs there.

          As for your block, is there a specific bug in the tracker where you have attached that code? If you do that it's easier for us to know about it and schedule it for review and possible integration into the next stable release.

          Show
          dougiamas Martin Dougiamas added a comment - Daniele .... errr, no, we are not saying every version of Moodle satisfies the needs of every user on the planet. If it did we could stop working and do something else. STABLE just means that no new FEATURES are being added to that branch, we only fix bugs there. As for your block, is there a specific bug in the tracker where you have attached that code? If you do that it's easier for us to know about it and schedule it for review and possible integration into the next stable release.
          Hide
          daniss Daniele Cordella added a comment -

          Thank you Martin for your answer.
          I am going to post a new feature requet in the tracker.

          Just to know... when do you start to send killer around the world to kill users posting and posting bug and feature request in the tracker?
          Do I have to wait for a killer when I reach 100 posts in the tracker or when the fixing interventions consequent to/descending from my posts reach 100?

          Ciao and thank you far all.

          Show
          daniss Daniele Cordella added a comment - Thank you Martin for your answer. I am going to post a new feature requet in the tracker. Just to know... when do you start to send killer around the world to kill users posting and posting bug and feature request in the tracker? Do I have to wait for a killer when I reach 100 posts in the tracker or when the fixing interventions consequent to/descending from my posts reach 100? Ciao and thank you far all.
          Hide
          dougiamas Martin Dougiamas added a comment -

          I'm more worried about all the killers that users will start sending when their "unresolved bugs" list reaches 100

          Show
          dougiamas Martin Dougiamas added a comment - I'm more worried about all the killers that users will start sending when their "unresolved bugs" list reaches 100
          Hide
          danmarsden Dan Marsden added a comment -

          Thanks Martin, - it wasn't me who caused the bork! - I wasn't working on anything on the day in question!

          Dan

          Show
          danmarsden Dan Marsden added a comment - Thanks Martin, - it wasn't me who caused the bork! - I wasn't working on anything on the day in question! Dan
          Hide
          dlnsk Dmitry Pupinin added a comment -

          Now contrib developers can't also create/move any tags. It very need for mark released version of modules/blocks/etc

          Martin, could you describe how register request for tag manipulations?

          Show
          dlnsk Dmitry Pupinin added a comment - Now contrib developers can't also create/move any tags. It very need for mark released version of modules/blocks/etc Martin, could you describe how register request for tag manipulations?
          Hide
          dougiamas Martin Dougiamas added a comment -

          Well, it shouldn't be necessary, generally.

          There are already branches for MOODLE_16_STABLE, MOODLE_17_STABLE, MOODLE_18_STABLE and HEAD, and I'll create new ones that match the ones in core Moodle.

          To mark particular versions within the branches you should use the $version variable within the version.php file.

          If you have a particular need beyond this please file a new bug in the CVS repository component:

          http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10020&sorter/order=DESC&sorter/field=priority&resolution=-1&component=10140

          Show
          dougiamas Martin Dougiamas added a comment - Well, it shouldn't be necessary, generally. There are already branches for MOODLE_16_STABLE, MOODLE_17_STABLE, MOODLE_18_STABLE and HEAD, and I'll create new ones that match the ones in core Moodle. To mark particular versions within the branches you should use the $version variable within the version.php file. If you have a particular need beyond this please file a new bug in the CVS repository component: http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10020&sorter/order=DESC&sorter/field=priority&resolution=-1&component=10140
          Hide
          dlnsk Dmitry Pupinin added a comment -

          >There are already branches for MOODLE_16_STABLE, MOODLE_17_STABLE, MOODLE_18_STABLE and HEAD
          I'm not about branch. I'm about TAGs which very important for checkout necessary version (please see attendance block, wiki module for example)!

          >To mark particular versions within the branches you should use the $version variable within the version.php file.
          Yes. But how checkout previous version without using TAG if some files has already changed and commited? Also very difficult to Merge changes from HEAD to any branch and vice versa.

          Maybe could move contrib in separate repository and allow Branch/Tag manipulation?

          Show
          dlnsk Dmitry Pupinin added a comment - >There are already branches for MOODLE_16_STABLE, MOODLE_17_STABLE, MOODLE_18_STABLE and HEAD I'm not about branch. I'm about TAGs which very important for checkout necessary version (please see attendance block, wiki module for example)! >To mark particular versions within the branches you should use the $version variable within the version.php file. Yes. But how checkout previous version without using TAG if some files has already changed and commited? Also very difficult to Merge changes from HEAD to any branch and vice versa. Maybe could move contrib in separate repository and allow Branch/Tag manipulation?
          Hide
          dougiamas Martin Dougiamas added a comment - - edited

          Well, there is one exception I forgot to mention ... you can move any existing MOODLE_XX_MERGED tag (and you should use these tags within the branches to manage merging).

          For other tags I don't yet see why you need them. Any version of your code in the MOODLE_18_STABLE branch should work on any version of Moodle 1.8. And surely the most recent version of the code in a branch is the "best", right?

          Can you explain exactly why you are needing to tag other moments within the branches?

          Perhaps there is a better way of doing it, and if not, I'm happy to find some other solution (one that doesn't involve everyone being able to mess up any existing tag).

          Show
          dougiamas Martin Dougiamas added a comment - - edited Well, there is one exception I forgot to mention ... you can move any existing MOODLE_XX_MERGED tag (and you should use these tags within the branches to manage merging). For other tags I don't yet see why you need them. Any version of your code in the MOODLE_18_STABLE branch should work on any version of Moodle 1.8. And surely the most recent version of the code in a branch is the "best", right? Can you explain exactly why you are needing to tag other moments within the branches? Perhaps there is a better way of doing it, and if not, I'm happy to find some other solution (one that doesn't involve everyone being able to mess up any existing tag).
          Hide
          dlnsk Dmitry Pupinin added a comment -

          >you can move any existing MOODLE_XX_MERGED tag
          Yes I know.

          >And surely the most recent version of the code in a branch is the "best", right?
          Yes of course!

          >Can you explain exactly why you are needing to tag other moments within the branches?
          OK. Imagine next real situation:
          Fumikazu Iseki got version 1.0.8 of Attendance (not from CVS) and improved it for autoassign attendances. How can I view differences if I'll can't get version 1.0.8 from CVS? Now I already have 1.0.9. Only because I have tag ATTENDANCE_108 I can checkout this release and create patches.

          Example 2:
          Consider module NWiki. Ludo and Co creates 3-5 releases in month.
          I want improve some features but I also want have stable release for my site. When new release appear I want simple update to it. I don't want latest HEAD version because it can be untested or unfinished. Some time ago all releases of Wiki was tagged but now isn't.

          Show
          dlnsk Dmitry Pupinin added a comment - >you can move any existing MOODLE_XX_MERGED tag Yes I know. >And surely the most recent version of the code in a branch is the "best", right? Yes of course! >Can you explain exactly why you are needing to tag other moments within the branches? OK. Imagine next real situation: Fumikazu Iseki got version 1.0.8 of Attendance (not from CVS) and improved it for autoassign attendances. How can I view differences if I'll can't get version 1.0.8 from CVS? Now I already have 1.0.9. Only because I have tag ATTENDANCE_108 I can checkout this release and create patches. Example 2: Consider module NWiki. Ludo and Co creates 3-5 releases in month. I want improve some features but I also want have stable release for my site. When new release appear I want simple update to it. I don't want latest HEAD version because it can be untested or unfinished. Some time ago all releases of Wiki was tagged but now isn't.
          dougiamas Martin Dougiamas made changes -
          Project Moodle [ 10011 ] Non-core contributed modules [ 10033 ]
          Key MDL-9032 CONTRIB-161
          Fix Version/s 1.6.5 [ 10210 ]
          Affects Version/s 1.8.2 [ 10221 ]
          Affects Version/s 1.6.5 [ 10210 ]
          dougiamas Martin Dougiamas made changes -
          Component/s Questionnaire [ 10086 ]
          dougiamas Martin Dougiamas made changes -
          Link This issue has a clone MDLSITE-216 [ MDLSITE-216 ]
          tsala Helen Foster made changes -
          Component/s Document Management [ 10081 ]
          salvetore Michael de Raadt made changes -
          Component/s Hotpot [ 10090 ]
          Hide
          salvetore Michael de Raadt added a comment -

          I'm closing this issue, which looks like it was fixed long ago.

          Show
          salvetore Michael de Raadt added a comment - I'm closing this issue, which looks like it was fixed long ago.
          salvetore Michael de Raadt made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          salvetore Michael de Raadt made changes -
          Component/s Journal [ 10056 ]
          salvetore Michael de Raadt made changes -
          Component/s Exercise [ 10074 ]
          salvetore Michael de Raadt made changes -
          Component/s LAMS [ 10085 ]
          salvetore Michael de Raadt made changes -
          Component/s Wiki (1.x) [ 10079 ]

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development