Re: [Trac] Re: Trac + Git performance issue
On 6/4/13, W. Martin Borgert deba...@debian.org wrote: On 2013-06-04 15:58, Grzegorz Sobański wrote: [...] From what I remember reading the code some time ago - it won't. Performance problems (and wrong data with cache) are a result of Trac version control system being tightly dependant on the SVN model. GitCachedRepository is using an SVN cache, and its representation assumes linear (:D) order of commits. IMO without huge rewrite of GitCachedRepository and probably some parts of the not-cached version no gains can be achieved. I see. So there are three options: - bribe Trac developers to solve the problem (my boss will kill me for the spendings) - avoid Git for now (my colleagues will kill me for having to stay with SVN) - find an alternative to Trac (I will kill myself for not being able to work with it) That's the situation now , yes ... [...] Anyway, from my perspective, Git has a huge momentum and - if I like it or not - most developers I know, are already using it or have plans to migrate. If Tracs support for Git does not improve significantly in the short term, I fear, that people will move to Gitorious or Gitlab. Both are based on Ruby - no hacking fun for me :~( fwiw +1 I do not know whether this suggestion will be a good idea but maybe you could try to create a mercurial mirror (mercurial-git debian package afaicr) and plug it into your Trac instance ... ? -- Regards, Olemis. Apache™ Bloodhound contributor http://issues.apache.org/bloodhound 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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Trac] Re: Trac + Git performance issue
On 01.06.2013 19:05, W. Martin Borgert wrote: I'm trying to integrate a Git repository into Trac. For testing I chose the Linux kernel (~375000 commits, ~1.3 GB). I first tried without any special settings in trac.conf. Unfortunately the Browse Source view was unusable slow. Than I tried the setting with: Is your real repository the same size? Have you tried testing it with a repository size more similar to your real needs? If your repository is of a more typical size it will work okish. [git] cached_repository = true persistent_cache = true It will display wrong results (unless it was fixed, but I don't think so). On 2013-06-01 09:29, RjOllos wrote: I just started working with the Git connector component as well, and noticed on the Git documentation page [1]: Please note that we're still considering the level of performance to be sub-optimal, so it might not work for you. Small to medium sized repositories should be handled reasonably well, however. OK. I see, that there are some open tickets and ideas on improvements, e.g. #10606. Is there any reason (not) to use libgit2/pygit2? Would this improve performance anyway? From what I remember reading the code some time ago - it won't. Performance problems (and wrong data with cache) are a result of Trac version control system being tightly dependant on the SVN model. GitCachedRepository is using an SVN cache, and its representation assumes linear (:D) order of commits. IMO without huge rewrite of GitCachedRepository and probably some parts of the not-cached version no gains can be achieved. -- silk -- You received this message because you are subscribed to the Google Groups Trac Users group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Trac] Re: Trac + Git performance issue
On 2013-06-04 15:58, Grzegorz Sobański wrote: Is your real repository the same size? Have you tried testing it with a repository size more similar to your real needs? If your repository is of a more typical size it will work okish. In fact, one of the repositories I have to support, will be the Linux kernel (for working on some special drivers). For my setup it would be possible to work in a different way, i.e. use the Linux kernel as a tar.gz and the drivers as patches in git, while other smaller software components could live naturally in git. Not elegant, but possible. From what I remember reading the code some time ago - it won't. Performance problems (and wrong data with cache) are a result of Trac version control system being tightly dependant on the SVN model. GitCachedRepository is using an SVN cache, and its representation assumes linear (:D) order of commits. IMO without huge rewrite of GitCachedRepository and probably some parts of the not-cached version no gains can be achieved. I see. So there are three options: - bribe Trac developers to solve the problem (my boss will kill me for the spendings) - avoid Git for now (my colleagues will kill me for having to stay with SVN) - find an alternative to Trac (I will kill myself for not being able to work with it) Yesterday, I tried option 3 with Redmine, but at least in my adhoc setup Git performance was much worse than Tracs. I have no experience with Redmine, so maybe it was all my fault. Anyway, from my perspective, Git has a huge momentum and - if I like it or not - most developers I know, are already using it or have plans to migrate. If Tracs support for Git does not improve significantly in the short term, I fear, that people will move to Gitorious or Gitlab. Both are based on Ruby - no hacking fun for me :~( Cheers -- You received this message because you are subscribed to the Google Groups Trac Users group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Trac] Re: Trac + Git performance issue
On Saturday, June 1, 2013 3:39:10 AM UTC-7, W. Martin Borgert wrote: Hi, I'm trying to integrate a Git repository into Trac. For testing I chose the Linux kernel (~375000 commits, ~1.3 GB). I first tried without any special settings in trac.conf. Unfortunately the Browse Source view was unusable slow. Than I tried the setting with: [git] cached_repository = true persistent_cache = true This time the synchronisation took ~36 hours until all revisions were in the database, and everything seems to be faster, but still so slow, that I cannot foist this on my colleagues. I wonder, whether I have to tune something to make it work? Some more Trac parameters? Or PostgreSQL? The repository itself is OK: A quick test with the Gitk showed that the access can be very fast. My setup: Debian wheezy+jessie mix Trac 1.0.1 Git (and Gitk) 1.7.10.4 PostgreSQL 9.1 Apache 2.2 Mod-WSGI 3.3 Python 2.7.5 Thanks in advance! Cheers I just started working with the Git connector component as well, and noticed on the Git documentation page [1]: Please note that we're still considering the level of performance to be sub-optimal, so it might not work for you. Small to medium sized repositories should be handled reasonably well, however. I imagine you already have this, but did you repository_sync_per_request to an empty value and instead setup a post-receive hook to sync changes?: [trac] repository_sync_per_request = [1] http://trac.edgewall.org/wiki/TracGit -- You received this message because you are subscribed to the Google Groups Trac Users group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Trac] Re: Trac + Git performance issue
On 2013-06-01 09:29, RjOllos wrote: I just started working with the Git connector component as well, and noticed on the Git documentation page [1]: Please note that we're still considering the level of performance to be sub-optimal, so it might not work for you. Small to medium sized repositories should be handled reasonably well, however. OK. I see, that there are some open tickets and ideas on improvements, e.g. #10606. Is there any reason (not) to use libgit2/pygit2? Would this improve performance anyway? [trac] repository_sync_per_request = It was (default), but changing seems to make no difference in my case. Thanks anyway! -- You received this message because you are subscribed to the Google Groups Trac Users group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
