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.

      Issue Links

        Activity

        Hide
        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
        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
        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
        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
        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
        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!
        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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.
        Hide
        Michael de Raadt added a comment -

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

        Show
        Michael de Raadt added a comment - I'm closing this issue, which looks like it was fixed long ago.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development