On 12/7/14, osimons <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
