Hi! Pardon me for requesting more support from pragma-ade prior to ever using the mailing list for general support questions. Maybe I should post this one directly to Hans but others might be interested in this issue as well. Despite my little but growing knowledge of Context I am currently evaluating its suitability for document building in our company (our workflow is currently Latex-based). A prime aspect of our company's work is to follow well-defined processes, and as part of that, we have to be able to refer to specific versions of applications that are used in the development of our projects. When used, this would apply to Context as well. Obviously, downloading from pragma-ade gives version numbers only on the entry pages like http://www.pragma-ade.nl/download-1.htm next to the links to the files, but the package files themselves like http://www.pragma-ade.nl/context/current/cont-tmf.zip don't have versioned names (not mentioning that Context and its modules actually _do_ report version numbers as dates upon use). Is there a strong motivation against having versioned package file names, possibly with some months/years of history? Has this support feature ever been considered by pragma-ade or asked for by their (non-)paying customers? Or is this archive available but I am unable to find it? ;) Just an example: Instead of http://www.pragma-ade.nl/context/current/cont-tmf.zip use a browseable directory like http://www.pragma-ade.nl/context/archive/ containint files like http://www.pragma-ade.nl/context/archive/cont-tmf-20060518.zip http://www.pragma-ade.nl/context/archive/cont-tmf-20060601.zip http://www.pragma-ade.nl/context/archive/cont-tmf-20060629.zip and possibly set /context/current/cont-tmf.zip as an internal file system link to the latest file in /context/archive/ for those interested only in the latest version. The proposed method could be applied to all other download files as well. That way and as long as the archive files are available, a precise version of Context could be fetched from pragma-ade's server without maintaining a local versioned archive of cont.tmf.zip etc. Referral to a specific version of Context would be a lot easier, and documenting the tools used for a project would be a lot simpler. A common understanding of a Context version, reflected in its package file name, would reduce the effort of those responsible for local version control and install package maintenance. Thanks, - Matthias
Matthias Wächter wrote:
Is there a strong motivation against having versioned package file names, possibly with some months/years of history? Or is this archive available but I am unable to find it? ;)
There is an archive of old releases and file versions on-line, but at a different location. Check this page as a starting point: http://wiki.contextgarden.net/Revisions It is not mentioned on the pragma-ade site (yet -- perhaps it should). Greetings, Taco
Taco Hoekwater schrieb:
Matthias Wächter wrote:
Is there a strong motivation against having versioned package file names, possibly with some months/years of history? Or is this archive available but I am unable to find it? ;) There is an archive of old releases and file versions on-line, but at a different location. Check this page as a starting point: http://wiki.contextgarden.net/Revisions
Taco, thanks for pointing me there and indirectly to the releases and SVN repository at supelec.fr. Stupid /me didn't search the garden for it. Two comments nevertheless. https://foundry.supelec.fr/frs/?group_id=14 gives me quite some versions of Context, but the download paths for each precise version is not related to the release date or the SVN revision, for example, the 20060609 release can be downloaded as https://foundry.supelec.fr/frs/download.php/305/cont-tmf.zip. Can't it be something like https://foundry.supelec.fr/frs/download.php/cont-tmf-20060609.zip, or in case of true SVN snapshots maybe https://foundry.supelec.fr/frs/download.php/cont-tmf-164.zip having '164' as the associated SVN repository revision number? That would be easy to maintain in subsequent application packages for Context. Certainly, supelec.fr and gforge.org have the last word on this issue. Anyway, thanks for the link, it is a big step towards a solution. Second: I tried to checkout the repository anonymously as mentioned on https://foundry.supelec.fr/scm/?group_id=14 without success (it asks me for username/password). Either anonymous read-only access should be enabled as documented, or the documentation on this page should change (but why should the repository be publicly browseable as well as versioned snapshots be publicly available without proper public Subversion access?). In case cont-tmf.zip is a simple consistent snapshot of the (then) publicly available SVN repository, the problem of versioning would vanish in a second, I'd just have to refer to the associated SVN revision of the tree. Thanks, - Matthias
Matthias Wächter wrote:
Two comments nevertheless.
https://foundry.supelec.fr/frs/?group_id=14 gives me quite some versions of Context, but the download paths for each precise version is not related to the release date or the SVN revision,
Correct. SVN release ids have numbers, not dates, and it was a bitch getting all this stuff into subversion as it was, so I did not want to fiddle too much with extra tag ids. The SVN log entry is always the release date number. For the 'Files' section, it could actually be retrofitted, by rearranging the uploaded files (and uploading a few hundred extra zip files that are now skipped). I will happily give anybody who wants to do such a project enough gforge permissions to do so ;-)
Second: I tried to checkout the repository anonymously as mentioned on https://foundry.supelec.fr/scm/?group_id=14 without success
That is odd, because it should have worked. I will investigate Greetings, Taco
Taco Hoekwater wrote:
Matthias Wächter wrote:
https://foundry.supelec.fr/frs/?group_id=14 gives me quite some versions of Context, but the download paths for each precise version is not related to the release date or the SVN revision, Correct. SVN release ids have numbers, not dates, and it was a bitch getting all this stuff into subversion as it was, so I did not want to fiddle too much with extra tag ids. The SVN log entry is always the release date number.
So you take the official, newly released .zip file, unpack it to the checked out Subversion copy, and commit the changes using your name and the release date as commit text (no change tracking using information from the Release Notes or the prime version control system),? It's not that Context development is actually performed on supelec.fr, is it? Looks like a lot of effort (riding the horse backwards). So: Why is Context development not performed on a public SVN repository? The whole release procedure would be a lot simpler then ... Am I too progressive asking this? ;)
For the 'Files' section, it could actually be retrofitted, by rearranging the uploaded files (and uploading a few hundred extra zip files that are now skipped). I will happily give anybody who wants to do such a project enough gforge permissions to do so ;-)
I don't understand precisely what actions you mean. Maybe together we can work out a better 'Files' section.
Second: I tried to checkout the repository anonymously as mentioned on https://foundry.supelec.fr/scm/?group_id=14 without success That is odd, because it should have worked. I will investigate
Thank you very much!
Just a configuration hint (actually I don't know how much access you have to the various SVN config files on supelec.fr):
1) Put a "* = r" for the part (or whole) of the repository in the file referred to by the AuthZSVNAccessFile directive in the apache config. Usually, the file looks like the following enabling write access for users "taco" and "hans" while only read access for anybody including anonymous:
<snip>
[groups]
committers = taco, hans
[/]
* = r
@committers = rw
</snip>
2) Assure that "Require valid-user" is accompanied by "Satisfy Any" inside the <Location>...</Location> section of the apache config file. An example config section is
<snip>
Matthias Wächter wrote:
So you take the official, newly released .zip file, unpack it to the checked out Subversion copy, and commit the changes using your name and the release date as commit text (no change tracking using information from the Release Notes or the prime version control system),?
Almost correct, you missed a step: Take the official, newly released .zip file, unpack it, *generate Release Notes*, copy to checked out Subversion .. etc
It's not that Context development is actually performed on supelec.fr, is it?
Correct, "ConTeXt Revisions" is a museum, development takes place at Pragma-ADE, on Hans' internal file server.
Looks like a lot of effort (riding the horse backwards).
It is a lot of effort, although quite a bit is automated by now. But almost everything else would mean extra work for Hans (who does development almost single-handedly) and it would not help me overmuch either because, in general, you cannot trust ChangeLog/ CommitLog entries :-/ Generating Release Notes and publishing to CTAN are by far the biggest of my tasks as far as manual labour goes.
So: Why is Context development not performed on a public SVN repository?
Hans' convenience (as indicated above). Hans has an infrastructure set up already, and that structure predates public SVN by quite a few years. Switching would result in a temporary loss of productivity that is hard to justify. Especially so, since Hans is not only the lead also almost the only developer.
The whole release procedure would be a lot simpler then ... Am I too progressive asking this? ;)
Perhaps you are ;-)
For the 'Files' section, it could actually be retrofitted, by rearranging the uploaded files (and uploading a few hundred extra zip files that are now skipped). I will happily give anybody who wants to do such a project enough gforge permissions to do so ;-)
I don't understand precisely what actions you mean. Maybe together we can work out a better 'Files' section.
Mostly renaming a few hunderd uploaded files using the web interface. Not very hard in itself, but tedious and error-prone (and I simply do not have time for it right now).
Second: I tried to checkout the repository anonymously as mentioned on https://foundry.supelec.fr/scm/?group_id=14 without success
That is odd, because it should have worked. I will investigate
Thank you very much!
Just a configuration hint (actually I don't know how much access you have to the various SVN config files on supelec.fr):
(Will forward this to Fabrice Popineau, thank you very much) Cheers, Taco
Taco Hoekwater wrote:
Correct, "ConTeXt Revisions" is a museum, development takes place at Pragma-ADE, on Hans' internal file server.
right, also my local dev structure is not the same as the distributed one (also predated); if i'd move to some svn thing it would cost me much time, since i'd had to make sure that i sync local things properly; i also would have to rewrite zip making scripts etc; maybe some day ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Taco Hoekwater wrote:
Matthias W�chter wrote:
Is there a strong motivation against having versioned package file names, possibly with some months/years of history?
Or is this archive available but I am unable to find it? ;)
There is an archive of old releases and file versions on-line, but at a different location. Check this page as a starting point:
http://wiki.contextgarden.net/Revisions
It is not mentioned on the pragma-ade site (yet -- perhaps it should).
ok, will be under downloads Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Matthias Wächter wrote:
Is there a strong motivation against having versioned package file names, possibly with some months/years of history? Has this support feature ever been considered by pragma-ade or asked for by their (non-)paying customers? Or is this archive available but I am unable to find it? ;)
here we seldom use specific version; we do have project specific minimal trees because different projects demand different commercial fonts, and there are situations where experimental features are used that are not yet stable. on a local ox one can do things like: /distributions/context-20050518/.... which we initialize with setuptex (see minimal distribution) and or by using texmfstart --tree (see manual) taco has a complete archive
Just an example:
Instead of http://www.pragma-ade.nl/context/current/cont-tmf.zip
use a browseable directory like http://www.pragma-ade.nl/context/archive/ containint files like http://www.pragma-ade.nl/context/archive/cont-tmf-20060518.zip http://www.pragma-ade.nl/context/archive/cont-tmf-20060601.zip http://www.pragma-ade.nl/context/archive/cont-tmf-20060629.zip
and possibly set /context/current/cont-tmf.zip as an internal file system link to the latest file in /context/archive/ for those interested only in the latest version. The proposed method could be applied to all other download files as well.
That way and as long as the archive files are available, a precise version of Context could be fetched from pragma-ade's server without maintaining a local versioned archive of cont.tmf.zip etc. Referral to a specific version of Context would be a lot easier, and documenting the tools used for a project would be a lot simpler. A common understanding of a Context version,
although windows (on which we develop context) provides different link systems i seldom use them; also, the server has just a copy of my local stuff and not more; the toolkit is upward compatible as much as possible (at least in functional terms); the most sensitive parts of tex setups are the fonts (but that will simplify in the near future with new versions of pdftex and open type)
reflected in its package file name, would reduce the effort of those responsible for local version control and install package maintenance.
taco maintains a svn repository on the gforce server at superlec ; in principle one can rebuild older versions from there however, the best way to archive is to use the minimal distributions (or your own ones built of them) because context files are just part of the story: fonts, patterne etc also play a role; in a year or so, you we hope to be able to run dirtectly from zip files, which makes live even more simple Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Matthias Wächter -
Taco Hoekwater