On 12/7/14, osimons <oddsim...@gmail.com> wrote: > Hi devs, > Hi ! :)
> With reference to the recent discussions about git, trac and git, git > performance, features and more, I've decided that perhaps now is a good > time to release a new plugin: TracGitServe plugin > right time indeed ! :) [...] > > What I will not do is go back to using the Trac-bundled git support that > essentially calls out to the git executable in subprocesses. The > performance was not good for a big site as CodeResort.com, but the main > problem was instabilities - frequently the server just hung from exhausted > resources. Retrieving a large changeset with many files and changes would > hang the webserver forcing process restarts. With pygit2/libgit2 it has > been running flawlessly since day one. Fast, stable, low memory, and low > general resource usage. > [...] > > The performance is really good even without caching in Trac (which is not > part of the pygit2 code that I use). Not that I'm keen on adding caching in > I tried Jun's plugin recently and it seems to be performing much better than previous solution . At least I did not notice the issues you mention above . [...] > > information into the git repository itself to make it easier to build new > features and pursue interesting new ways of working. For instance, why > can't ticket references be added in git instead with custom references to > changesets? Storing objects and references is what git is very good at, and > > this is for instance how I believe GitHub does the logic behind pull > requests where changeset objects from remote repositories are copied back > to origin repository and referenced with custom pull request IDs (stored > internally as +refs/pull/...). > These are the kinds of integrations that I mentioned before that I would like to see in Trac as well ... > Git is an efficient object and reference store. The future of GitServe > plugin with adding to the git repositories is therefore much more > interesting, and with efficient retrieval and modification of repository > information the core data would follow the repository code and we would not > have to struggle to keep everything in sync - adding trac-admin commands, > scripts and hooks to keep track of the changes we want to follow. For many > uses, the repository can provide a new and better option for storage. > ... preferably if there is some kind of high/intermediate level API that could be implemented to perform similar operations upon different VCS backend (if possible , of course) hence been able to write a plugin once and make things work for different deployments . [...] -- Regards, Olemis - @olemislc Apache(tm) Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
