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
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
