On 12/4/14, W. Martin Borgert <deba...@debian.org> wrote: > Quoting Peter Suter <petsu...@gmail.com>: >> On 03.12.2014 16:40, Christopher Nelson wrote: >>>> On 2014-06-22 12:12, Olemis Lang wrote: >>>>> I'm not very fond of git at all , TBH . It does not integrate well >>>>> with Trac , >>>> OT: This is a major problem for Trac. Nothing against hg, but Git >>>> is currently the most successful VCS. If Trac will not improve >>>> its Git support, people will move away from Trac, not from Git. >> >> Could you give more details about what you mean? Why does git not >> integrate well? How would improved git support look like? What's >> missing that hg has? > > Olemis Lang can probably compare git with hg in Trac. > > For me, there are two problems: > > 1. No nice integration. With typical/simple hooks, the same commits > get referenced (#refs) in tickets again and again when merging and > branching. Worse, if you had a commit closed by a commit > (#closes), but had to reopen later, it gets closed again just by a > merge! > > What is missing is a list of commits already processed, so that > Trac doesn't list the same commit multiple times. Or a more > flexible approach, e.g. if one maintains ticket specific branches, > link all changes in the respective branch in the ticket, but also > show merges into master or a release branch. >
It's impossible to describe this aspect better . > Good hook scripts for different workflows should be part of the > Trac distribution in the contrib directory. > In this case I'm assuming that "workflow" is about repository layouts like this one ... ? http://nvie.com/posts/a-successful-git-branching-model/ > 2. Performance for large repositories. Try to import the linux kernel > source and actually use it. It works neither with nor without > cache, it is too slow to use. Cache creation took many hours on my > notebook computer, btw. > Yes , and performance is not just about speed but also about stability . Eventually the Trac service has to be restarted due to issues *reminiscent* to dangling references or everlasting open file descriptors . There is also the fact about supporting more sophisticated features e.g. TracMercurial supports patch queues repositories and other advanced aspects whereas e.g. I'm not sure of how well git plugin will deal with sub repositories . Nevertheless I'm biased since I use hg most of the time and git only when I have no other choice . In the later case often when it comes to third-party private repositories which are not connected to Trac as issue tracker . In the near future I really hope that Trac can offer something similar to Bitbucket , for instance , when it comes to providing useful tools and uniform access that works for both hg & git ; or similar to Gitlab et al. when it comes to supporting advanced yet useful features . -- 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.
