There's something that always drives me crazy when I upgrade that I thought I would mention. I've got certain files I have hacked in my Moodle. For example, I have a heavily hacked version of index_form.html. I want to incorporate these changes into the latest version of the file. However, there is nothing in the latest file to tell me what version it is so that I can use CVS to run a diff on it with the version I hacked during my previous upgrade. The date of the actual index_form.html doesn't correspond to anything I find in CVS, so I am stumped which file it is exactly. My request would be that developers include the file version number within every Moodle file. For example, in logout.php, I find the following information:
logout.php,v 1.17 2006/01/24 06:01:30
But this is not in every Moodle file, and it would be helpful if it were. Thanks!
If you use a CVS checkout (and it looks like you do already), cvs will know about your changes. There's a lot you can get CVS to do to help you.
So good news: all you need to know is how to use cvs more effectively.
Before a major upgrade, do cvs diff > mychanges.patch -- this will collect all your modifications in a patch file, just in case something goes wrong.
Then you do cvs update -dP -r MOODLE_16_STABLE and cvs will try really hard to upgrade and reapply your changes. there may be conflicts if the same areas of the file have changed on both sides, and you'll have to rework those changes to work again in 1.6. But changes that don't conflict will be ported over.
The $Id$ lines you mention are not very useful, actually, and they force you to do a lot of work that CVS can do itself (saving you a lot of time). They also break a lot of other stuff too so they are not my friends
All files should have this yes, it's added by typing $Id$ in the file ... this gets converted to the date/version/developer of that last change to that file.
Martin L is right that they are not that useful if you use CVS properly (I never look at them either) but it's useful for people who don't use CVS to have some sort of handle on things.
Martin L is right that they are not that useful if you use CVS properly (I never look at them either) but it's useful for people who don't use CVS to have some sort of handle on things.
I don't use CVS. I download Moodle packages or individual modules or whatever and then manually edit files according to a list of changes I keep. I use a lot of non-standard modules that aren't even in CVS so I prefer it that way.
Nicole, I don't really understand what you are asking. You are manually editing files according to a list of changes, and then doing a upgrade and adding those list of changes again manually? Each time you upgrade to the newest version?
It would be much easier (for you) if you did it from a CVS checkout, (even taking into consideration that you use nonstandard modules that may be in contrib or not in CVS at all).
Why does that date field help you?
It would be much easier (for you) if you did it from a CVS checkout, (even taking into consideration that you use nonstandard modules that may be in contrib or not in CVS at all).
Why does that date field help you?
In reply to N Hansen
How to keep customisations wihout CVS (Re: A Request to All Developers)
by Martín Langhoff -
Ok -- note that using CVS is much easier... and it copes alright with using nonstandard modules that aren't in CVS. It will just print a questionmark next to them, because it doesn't know what to do with them.
Without CVS the best strategy is to keep the zipfile of the downloaded moodle around. Here's how you do it:
Moodle 1.Z is released, you unpack it to /somewhere/moodle and edit some files with customisations
A week later, you download a daily build of the MOODLE_1Z_STABLE branch, date 2006XXXX. So you...
Unpack the previous one to a temporary directory (we will call that one "pristine" because you haven't modified it), next to where the 'production' moodle is. So make it /somewhere/moodle-1Z-pristine
Create a patchfile that describes the difference between the pristine and the customised one:
diff -ur /somewhere/moodle-1Z-pristine /somewhere/moodle > /tmp/mylocalchanges.patchNow unpack the new version, and use the
patchutility to apply the changes. You will have to fiddle with the -p parameter, but with a bit of trying it should be all go.
Now, this is all very unixy... there must be a Windows way of doing it with WinDiff and/or WinMerge. Actually, I think WinMerge can do visual 3-way merges, which will probably save you a lot of time...
Anyone knows WinMerge well?
In reply to Martín Langhoff
Re: How to keep customisations wihout CVS (Re: A Request to All Developers)
by Samuli Karevaara -
I don't know WinMerge very well, but it doesn't have 3-way merges 
I'm using TortoiseMerge for that. It's a TortoiseSVN companion, and I think there is no separate download for it. But I think (guessing again) that it does support diffing and merging of any two text files, not just in SVN working copies.
WinMerge is much better in diffing large trees. Also, it has regexp-filters which I'm using to exclude id field matching.
WinMerge is much better in diffing large trees. Also, it has regexp-filters which I'm using to exclude id field matching.
When you download the latest zip package (for a certain branch), it should contain the latest version of that file also? Are you worried that there might be some older version of the file inside the latest package?
I'd like to get rid of the $Id$ fields and auto-generated time stamps completely
I'd like to get rid of the $Id$ fields and auto-generated time stamps completely
I agree. All the $Id$ fields were a total pain when working on the 1.6 branch. They just cause merge conflicts and don't give you any information that cannot be better got elsewhere.
I am intending to take them all out of the quiz module.
If you are maintaining local changes to Moodle code, I think you would find in a worthwhile investment of time to learn how to use CVS. I strongly recommend Pragmatic Version Control with CVS by Dave Thomas and Andrew Hunt (no relation). It is short, easy to read, and tells you exactly what you need to know to use CVS effectively for everyday development.
I am intending to take them all out of the quiz module.
If you are maintaining local changes to Moodle code, I think you would find in a worthwhile investment of time to learn how to use CVS. I strongly recommend Pragmatic Version Control with CVS by Dave Thomas and Andrew Hunt (no relation). It is short, easy to read, and tells you exactly what you need to know to use CVS effectively for everyday development.
Speaking of using CVS properly are you aware of the -kk option?
This will merge keywords like $Id$ perfectly without any conflicts.
I would advise keeping them. Pretty often we get people reporting bugs in daily packages and when they mention that file version it makes understanding the problem a lot easier.
This will merge keywords like $Id$ perfectly without any conflicts.
I would advise keeping them. Pretty often we get people reporting bugs in daily packages and when they mention that file version it makes understanding the problem a lot easier.
Martin, I do know about the -kk and did try it. But it breaks most/all of the binary files, try it! Major pain... Maybe this has been fixed, but that was the case when I last tried it. I griped about it here http://moodle.org/mod/forum/discuss.php?d=41824.
I understand the reasons for keeping the $Id$, my evil smiley meant that I'd like to see them gone for selfish reasons mostly
(To make MY work easier
)
I understand the reasons for keeping the $Id$, my evil smiley meant that I'd like to see them gone for selfish reasons mostly
)
I'm forgotten about that.
And I don't understand it. My Eclipse was set to use -kk for text files by default. However, most of my checked out files were -kkv, with a few -kk and -kv. Then, when I tried to change it to -kk for all files, it asked for a commit comment, so I decided to wait until I understood what I was doing.
Is -kk a server side option or client side, or some combination of the two. It looks like I need to go and read the manual.
In the mix there is also the issue of "text files". CVS doesn't understand binary very well (well, at all, it seems). I think that the server decides which files are binary and which are text (for the -kk purposes), and this can be configured with CVS admin/write rights. But with my tests I couldn't get the binary files to work correctly, no matter what, so my solution was to forget about CVS, I'm just using it to download stuff and then importing them to SVN. I disabled all keyword substitutions in SVN so the $Id$s are not messing up the merges. I know that forgetting about CVS is a luxury that not everybody can afford
But if you do get a -kk checkout that doesn't break the binary files, I'd like to know. Watch for the byte sizes on the files etc. Also, gifs only break enough to mess with the color index
But if you do get a -kk checkout that doesn't break the binary files, I'd like to know. Watch for the byte sizes on the files etc. Also, gifs only break enough to mess with the color index
The manual is here: http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Keyword_substitution#SEC103.
and
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#SEC66
The difficulty is that the same -k set of options are used to control what are really quite different things:
1. they determine whether whether a particuar file is binary or text;
2. they determine what should happen to keywords on checkout.
CVS thinks these are the same option becuase for text/binary files it is deciding whether to substitute newlines, and for the other things it deciding whether to substitute other sequences of bytes.
Now, CVS stores the default setting of this flag for each file on the server, and if you just check a file out or do a merge or something whithout specifying an option, that is what is used.
On individual CVS commands, you can override this option, but then, as lots of people have spotted, it breaks binary files. Actually, in CVS 1.12.2 they made it more intelligent for merging, so specifying -kk on a merge does not break binary files any more. (But I can't discover which version of CVS sourceforge is running.)
Moodle HEAD currently has:
10 files checked in with -kk
2595 files checked in with -kkv
819 files checked in with -kb
The situation when using CVS in Eclipse is that there is no way to specify the -k options on any of the CVS commans it runs on your behalf. There is a bug about making its merge more intelligent: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36436 but it looks like it is not going to get fixed any time soon.
and
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging#SEC66
The difficulty is that the same -k set of options are used to control what are really quite different things:
1. they determine whether whether a particuar file is binary or text;
2. they determine what should happen to keywords on checkout.
CVS thinks these are the same option becuase for text/binary files it is deciding whether to substitute newlines, and for the other things it deciding whether to substitute other sequences of bytes.
Now, CVS stores the default setting of this flag for each file on the server, and if you just check a file out or do a merge or something whithout specifying an option, that is what is used.
On individual CVS commands, you can override this option, but then, as lots of people have spotted, it breaks binary files. Actually, in CVS 1.12.2 they made it more intelligent for merging, so specifying -kk on a merge does not break binary files any more. (But I can't discover which version of CVS sourceforge is running.)
Moodle HEAD currently has:
10 files checked in with -kk
2595 files checked in with -kkv
819 files checked in with -kb
The situation when using CVS in Eclipse is that there is no way to specify the -k options on any of the CVS commans it runs on your behalf. There is a bug about making its merge more intelligent: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36436 but it looks like it is not going to get fixed any time soon.
CVS munging of the file contents with the -k stuff is really one of the worst problems with it... having said that, I'm amazed that the CVS developers finally fixed the merging:
> Actually, in CVS 1.12.2 they made it more intelligent for
> merging, so specifying -kk on a merge does not break binary
> files any more.
But still... getting a meaningful diff between two branches is broken Who said an SCM was allowed to mess with the contents of the file, those very same contents it should be preserving!
> Actually, in CVS 1.12.2 they made it more intelligent for
> merging, so specifying -kk on a merge does not break binary
> files any more.
But still... getting a meaningful diff between two branches is broken
> Pretty often we get people reporting bugs in daily packages
> and when they mention that file version it makes understanding
> the problem a lot easier.
That's useful indeed. I'm thinking of teaching gitweb how to identify a given file to a revision so we don't lose that (if we ever choose to go) with git.
So we can then tell users: upload the file _here_ and tell us what identifier the file is -- and that will tell us what commit it corresponds to.
> and when they mention that file version it makes understanding
> the problem a lot easier.
That's useful indeed. I'm thinking of teaching gitweb how to identify a given file to a revision so we don't lose that (if we ever choose to go) with git.
So we can then tell users: upload the file _here_ and tell us what identifier the file is -- and that will tell us what commit it corresponds to.