Non-core contributed modules

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.

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

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

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

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

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.

.....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

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?

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.

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.

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

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

Dan

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?

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

>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?

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).

>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.