Versioning system for modules
Hi, esp. Mojca, what are the requirements for version controlled systems? What are the usecases? It is hard to decide which versioning system to use without knowing who needs it and when. Thanks! Patr... (can't type the rest of my name right now, too complicated)
On Do, 11 Mär 2010, Patrick Gundlach wrote:
what are the requirements for version controlled systems? What are the usecases? It is hard to decide which versioning system to use without knowing who needs it and when.
Is that a question coming out of thin air? I would suggest git. In fact, I was thinking playing around to move texlive to git. If then luatex/context/pdftex/whatever switches to git pulling and pushin would be soo much easier. If there wouldn't be the difficulty to have increasing revisions numbers easy to be done ...
Patr... (can't type the rest of my name right now, too complicated)
Too much Sake? Too much wine? ;-) Even after some glasses of Sake おやすみなさい ノルベルト ------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TU Wien, Austria Debian TeX Task Force DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ SHIFNAL (n.,vb.) An awkward shuffling walk caused by two or more people in a hurry accidentally getting into the same segment of revolving door. A similar effect is achieved by people entering three-legged races unwisely joined at the neck instead of the ankles. --- Douglas Adams, The Meaning of Liff
Am 11.03.2010 um 14:20 schrieb Norbert Preining:
On Do, 11 Mär 2010, Patrick Gundlach wrote:
what are the requirements for version controlled systems? What are the usecases? It is hard to decide which versioning system to use without knowing who needs it and when.
Is that a question coming out of thin air?
No, there is a discussion on the main context mailing list and I don't want to discuss this with a broad audience. I don't want to answer the question before knowing the exact question.
I would suggest git.
Me, too. I use git for almost everything, but it could be that an automatic svn repository via webdav could suffice. That way the users don't have to do anything at all, no installation of a SCM, no commands to learn, etc. As far as I understand the "problem": we need version controlled modules. Why? Who would go back in time? The module authors? Other users? The minimals-distribution-Mojca? What interface do these people need? How often do they need access to the SCM? Should we get rid of the files on the modules section? Lot's of questions, and I don't know the answer.
Patr... (can't type the rest of my name right now, too complicated)
Too much Sake? Too much wine? ;-)
No, just a bit upset. But I'll calm down.
Even after some glasses of Sake
おやすみなさい
ノルベルト
That looks all greek to me :-) Patrick (<- better now)
On Thu, 11 Mar 2010, Patrick Gundlach wrote:
Am 11.03.2010 um 14:20 schrieb Norbert Preining:
I don't want to answer the question before knowing the exact question.
As far as I understand the "problem": we need version controlled modules. Why? Who would go back in time? The module authors? Other users? The minimals-distribution-Mojca?
Actaully, I am not sure. For example, I personally store all (OK, most) of my modules on github. Whenever I want to upload something to garden, it is usually as easy as ctxtools --tpmmake module and upload the zip to contextgarden. As a module writer, I do not want to do the last step each time. For me, it will be easier to just create a branch "garden" (or something) on my github repo, fill in some details on contextgarden, and let something at the server take care of syncing from my git repo. Other authors use mercurial, svn, bazaar, you name it. I do not expect garden to support all of these VCs. Actually, there is not too big a difference between them, and there are easy ways of going from one VC -> svn -> another VC. So, I will be happy if contextgarden just pulls data from the appropriate branch of my VC stored at a public hosting site.
What interface do these people need? How often do they need access to the SCM?
As a context user, I do not care about VC. For installing/uninstalling, both minimals and TL work perfectly fine. As a power user, when something goes wrong, I like to look at the diffs to see what changed. There is alreay a git repo for the context files, but, IMO, it is horribly broken. The branches are, well not branches but shoots grafted on top of each other with frequent pruing and regrafting. But that is a discussion for another thread.
Should we get rid of the files on the modules section?
Personally, I only use the file section for browsing. So, even if the files section redirects me to github/bitbucket/whatever, I do not really care. Aditya
Am 11.03.10 19:24, schrieb Aditya Mahajan:
Actaully, I am not sure. For example, I personally store all (OK, most) of my modules on github. Whenever I want to upload something to garden, it is usually as easy as
ctxtools --tpmmake module
and upload the zip to contextgarden. As a module writer, I do not want to do the last step each time. For me, it will be easier to just create a branch "garden" (or something) on my github repo, fill in some details on contextgarden, and let something at the server take care of syncing from my git repo. I have a few modules on bitbucket but they are not always up to date and i prefer to keep a few modules (e.g. letter) on my system only.
Another point is the module strcuture, you use tpmtools to create a zip but this force one to store the files in tex, doc etc. folders while i use a flat structure (only two folders files and manual) and create a zip with context itself (ctx plus xml file). I have also no interest to go back to the tpmtools method.
What interface do these people need? How often do they need access to the SCM? As a context user, I do not care about VC. For installing/uninstalling, both minimals and TL work perfectly fine. Although i use mecurial i don't mind to switch to another system.
Wolfgang
participants (4)
-
Aditya Mahajan -
Norbert Preining -
Patrick Gundlach -
Wolfgang Schuster