On Thu, 27 Jan 2011, tiddlygrp wrote:
I think with git it could be different. But also svn allows partial checkouts!
Yes, of course, but because the system is organized and operated in a way that says, "it's all here" you thus have to operate as if it is all there, so doing a partial checkout is often not particularly useful. It will be better when the expectation is "it's all spread around" because then people will create their tools for that mode of work, which in the long run is better: more flexible for code owners and code users. [recipe and content from all over the web]
This is in principle true. In practice this implies that versioned repositories of the plugins exist, which can be accessed by cook. Just pointing to a tw with the plugin is not sufficient, as you may need a specific version.
Why, in any common case, would you want a specific version which isn't otherwise represented by a tag or branch (both of which are more visible and accessible (over the web) in git than in svn)? Being dependent on specific version ought to be a very rare case[1] in a suitably healthy ecosystem.
However that requires plugin writers to make their own repo, which may be too much.
I reckon it is far easier for a plugin writer to make a repo on github than it is for them to sign up for, get and then use the svn.tiddlywiki repo?
Maybe, even if you ditch stale tickets, etc, the whole trac wiki can be imported into git read only in a subdirectory called old (or something like this). Then it is searchable in github. I think the important thing is easy access to old knowledge, not necessarily keeping the old ticket system running.
I'm hoping that the people who have expressed a big commitment to the older tickets will devise a strategy for managing them that they are all happy with. Whether that means ditching them, doing what you are suggesting, or doing some kind of import (as Eric seems to want?) I'm happy to help orchestrate. --don't read past here if you'd like to stay on topic-- [1] That said, I think TiddlyWiki would gain a lot by allowing plugins to declare a specific version of tiddlywiki beyond which they don't work. I think this will make it possible for TiddlyWiki to move forward without the crippling onus of being backwards compatible with all plugins out there. Because of the unique style of plugging that TiddlyWiki plugis use (monkey patching, hooking, overriding, etc) it is very challenging to refactor the APIs (which do not reflect modern javascript style preferences). -- Chris Dent http://burningchrome.com/ [...] -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
