Can I use the build id (e.g., 20080424) to find the revision id of any file in the build? Specifically, is there a CVS command I can use?
Sorry about the truncated subject line (I'm not sure how it happened).
Hi John,
something like:
cvs log [-rMOODLE_19_STABLE] -Nd YYYY-MM-DD [hh:mm] file_to_check
should return info about the revision of "file_to_check" in date specified and in the branch specified.
Notes:
* For HEAD, just omit the entire -r option.
* The hh:mm part of the date is optional
* Between the "-r" and the name of the branch spaces are forbidden.
Ciao
something like:
cvs log [-rMOODLE_19_STABLE] -Nd YYYY-MM-DD [hh:mm] file_to_check
should return info about the revision of "file_to_check" in date specified and in the branch specified.
Notes:
* For HEAD, just omit the entire -r option.
* The hh:mm part of the date is optional
* Between the "-r" and the name of the branch spaces are forbidden.
Ciao
Eloy and Tim,
Thanks for both of your replies. The Moodle version is 1.8.2 (Build: 2007021520). I ran the following cvs command (in the lib directory):
$ubu[/../www/play/lib]: cvs log -rMOODLE_18_STABLE -Nd 2007-02-15 adminlib.php
RCS file: /cvsroot/moodle/moodle/lib/adminlib.php,v
Working file: adminlib.php
head: 1.200
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 290; selected revisions: 0
description:
==============================
The revision number can't be 1.200. That's not even a branch revision number. I happen to know that the correct answer is 1.124.2.10, but we got that through a painful process, and I'm looking for a simpler way. What am I missing?
Thanks for both of your replies. The Moodle version is 1.8.2 (Build: 2007021520). I ran the following cvs command (in the lib directory):
$ubu[/../www/play/lib]: cvs log -rMOODLE_18_STABLE -Nd 2007-02-15 adminlib.php
RCS file: /cvsroot/moodle/moodle/lib/adminlib.php,v
Working file: adminlib.php
head: 1.200
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 290; selected revisions: 0
description:
==============================
The revision number can't be 1.200. That's not even a branch revision number. I happen to know that the correct answer is 1.124.2.10, but we got that through a painful process, and I'm looking for a simpler way. What am I missing?
Hi Isner,
that's to "hit the nail on the head"!!
The reason for the command above returning nothing is that, in that date requested (2007-02-17 00:00) there wasn't any revision of lib/adminlib.php in the MOODLE_18_STABLE branch yet. So then, you should ask without the -r option, to get the latest HEAD revision that was available such date, because that's exactly the same revision where the branch was created. That's your file (in your example: revision 1.124).
But if you execute, for example:
cvs log -rMOODLE_18_STABLE -Nd 2007-02-16 adminlib.php
(one day later)
you should get:
RCS file: /cvsroot/moodle/moodle/lib/adminlib.php,v
Working file: adminlib.php
head: 1.200
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 290; selected revisions: 1
description:
----------------------------
revision 1.124.2.1
date: 2007/02/15 09:45:37; author: skodak; state: Exp; lines: +4 -6
MDL-7722 fixed wrong cleaning in backup paths; backported from HEAD
That means that, with date 2007/02/15 09:35, skodak added one new revision (1.124.2.1) with the commit message showed.
You can confirm all this looking at:
http://cvs.moodle.org/moodle/lib/adminlib.php?view=log
and looking for "Branch point for: MOODLE_18_STABLE" and then check the results above.
They key here is that build dates used to be "sticky" along the live of the release (only changing when a new .x version appeared). Anyway since some weeks ago, we are upgrading those build dates daily, so it will be safe to ask for them with the cvs log command above.
Apart of all this, and knowing that build dates weren't really accurate, also you can search in log page above for the tag "MOODLE_182". That will show you the exact revision used to build the 1.8.2 release (1.124.2.7).
Ciao
that's to "hit the nail on the head"!!
The reason for the command above returning nothing is that, in that date requested (2007-02-17 00:00) there wasn't any revision of lib/adminlib.php in the MOODLE_18_STABLE branch yet. So then, you should ask without the -r option, to get the latest HEAD revision that was available such date, because that's exactly the same revision where the branch was created. That's your file (in your example: revision 1.124).
But if you execute, for example:
cvs log -rMOODLE_18_STABLE -Nd 2007-02-16 adminlib.php
(one day later)
you should get:
RCS file: /cvsroot/moodle/moodle/lib/adminlib.php,v
Working file: adminlib.php
head: 1.200
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 290; selected revisions: 1
description:
----------------------------
revision 1.124.2.1
date: 2007/02/15 09:45:37; author: skodak; state: Exp; lines: +4 -6
MDL-7722 fixed wrong cleaning in backup paths; backported from HEAD
That means that, with date 2007/02/15 09:35, skodak added one new revision (1.124.2.1) with the commit message showed.
You can confirm all this looking at:
http://cvs.moodle.org/moodle/lib/adminlib.php?view=log
and looking for "Branch point for: MOODLE_18_STABLE" and then check the results above.
They key here is that build dates used to be "sticky" along the live of the release (only changing when a new .x version appeared). Anyway since some weeks ago, we are upgrading those build dates daily, so it will be safe to ask for them with the cvs log command above.
Apart of all this, and knowing that build dates weren't really accurate, also you can search in log page above for the tag "MOODLE_182". That will show you the exact revision used to build the 1.8.2 release (1.124.2.7).
Ciao
Eloy,
Brilliant, thanks a lot!
Brilliant, thanks a lot!
Thanks all!
My question, based on Eloy's bit of history and solution, is whether there should be a way for someone without this much savvy and effort to identify the manifest in the package (I am calling it a package simply in order to avoid confusion using other nouns) they have installed, package referencing the zip that they have downloaded (say, 1.9.1). I wonder whether anyone else sees a benefit to the new admin to offer zips that parse all the files and fill a manifest.php file with a listing of all the included files and their version (i.e. even if the CVS is autocreating new zips on a regular basis, the process could include creating the manifest easily enough I should think. I see this as having some potential benefits down the line as far as dependency checking and the like. And while using CVS may be the best way to manage an installation, I am wondering how many people install via CVS as opposed to installing via zip...
have for example maybe version.php or some other file
My question, based on Eloy's bit of history and solution, is whether there should be a way for someone without this much savvy and effort to identify the manifest in the package (I am calling it a package simply in order to avoid confusion using other nouns) they have installed, package referencing the zip that they have downloaded (say, 1.9.1). I wonder whether anyone else sees a benefit to the new admin to offer zips that parse all the files and fill a manifest.php file with a listing of all the included files and their version (i.e. even if the CVS is autocreating new zips on a regular basis, the process could include creating the manifest easily enough I should think. I see this as having some potential benefits down the line as far as dependency checking and the like. And while using CVS may be the best way to manage an installation, I am wondering how many people install via CVS as opposed to installing via zip...
have for example maybe version.php or some other file
Hi Marc,
I'm afraid I got lost in your post. Are you suggesting that zip files downloaded from download.moodle.org should contain a manifest indicating the cvs revision number of each file? If so, I think it's a good idea.
I'm afraid I got lost in your post. Are you suggesting that zip files downloaded from download.moodle.org should contain a manifest indicating the cvs revision number of each file? If so, I think it's a good idea.
My apologies again.... I am afraid when I write directly to the forum I am thinking while writing and tend to ramble...
I see the following related but arguably different issues:
I started another thread regarding the "latest download" question here as well: http://moodle.org/mod/forum/discuss.php?d=95888
NB: Moodle could in fact provide a utility to actually do a runtime creation of any package based on appropriate CVS and manifest data, but each such package would have to have a unique identifier, perhaps based on the actual date built but managed so that the current version ID was not confused with the package ID. Let's see if I can make this simpler.... let's say that moodle zips a package March 4, 2007 for 1.8.2; arguably, based on the version and package date a set of files could be packaged based on the manifest and cvs info and made available in real time..... if the requested package was not on file, so as to cut down on unnecessary packaging....
I see the following related but arguably different issues:
- Moodle offers at present different versions (1.8.2, 1.8.4, 1.9.0, etc.) and "latest" code for each version, and that at present the available downloads for any version may be different than the download for the SAME version available the week before
- Versioning is at best confusing (even for CVS users) and unfathomable for non-CVS users as our little investigation in part suggests
- Whether to differentiate between what I am calling a "package" and "build", package being a static collection of files and build being a dynamic set of files, with a build being what is currently offered by Moodle and a package as something that is not offered by Moodle
- Whether in either of the two cases above a manifest of the files included (in the case of the build, by have the system generated a manifest.php prior to zipping the file weekly, and in the former by creating the manifest when "packaging" the file.
I started another thread regarding the "latest download" question here as well: http://moodle.org/mod/forum/discuss.php?d=95888
NB: Moodle could in fact provide a utility to actually do a runtime creation of any package based on appropriate CVS and manifest data, but each such package would have to have a unique identifier, perhaps based on the actual date built but managed so that the current version ID was not confused with the package ID. Let's see if I can make this simpler.... let's say that moodle zips a package March 4, 2007 for 1.8.2; arguably, based on the version and package date a set of files could be packaged based on the manifest and cvs info and made available in real time..... if the requested package was not on file, so as to cut down on unnecessary packaging....
Not easily.
Most moodle files have a $Id: $ tag in them, which CVS will expand to include the file version number. That is probably the easiest way to find file version numbers.
CVS will allow you to check out a file by date, and then you can look to see what version you got. However, some files change more than once per day.
Most moodle files have a $Id: $ tag in them, which CVS will expand to include the file version number. That is probably the easiest way to find file version numbers.
CVS will allow you to check out a file by date, and then you can look to see what version you got. However, some files change more than once per day.
Tim,
Here is the scenario:
The user accidentally overwrote the original version of lib/adminlib.php. The file had not been checked out using cvs. He wants to replace the file by restoring it from cvs, but he wants to make sure he gets the correct revision number. His only clue is the information about the build: "Moodle 1.8.2 (Build: 2007021520)".
We have already fixed the problem, but it took a long time to figure out which file to extract from cvs. We want a quicker method in case this happens again.
Here is the scenario:
The user accidentally overwrote the original version of lib/adminlib.php. The file had not been checked out using cvs. He wants to replace the file by restoring it from cvs, but he wants to make sure he gets the correct revision number. His only clue is the information about the build: "Moodle 1.8.2 (Build: 2007021520)".
We have already fixed the problem, but it took a long time to figure out which file to extract from cvs. We want a quicker method in case this happens again.
Here is an example of why my suggestion for a manifest and potentially static distributions may be appropriate: http://moodle.org/mod/forum/discuss.php?d=95846
If one goes to location recommended one will find a version that has been recently built, and the person looking for the distro will be between a rock and a hard place trying to determine if zip currentl offered has the files he needs.
I have to suggest that this may be a place to offer a Latest Build of a specific version, while offering a number package separately. That way, anyone downloading , Let's call it "package 1.7.1.1" with Build 20060424 will always get the same files, while someone wishing to get the latest build for this version can download what moodle currently offers.
If one goes to location recommended one will find a version that has been recently built, and the person looking for the distro will be between a rock and a hard place trying to determine if zip currentl offered has the files he needs.
I have to suggest that this may be a place to offer a Latest Build of a specific version, while offering a number package separately. That way, anyone downloading , Let's call it "package 1.7.1.1" with Build 20060424 will always get the same files, while someone wishing to get the latest build for this version can download what moodle currently offers.